Network traffic classification: How applications are identified

Network traffic classification is the process of determining which applications, protocols, services, or traffic categories are represented in network communications, using ports, packet contents, device-generated application identifiers, destination characteristics, or traffic behavior. Modern networks require several of these methods together, because no single one works reliably across all traffic types.

Every network traffic report that says "Microsoft 365: 34% of WAN bandwidth" is the output of a classification decision, and the confidence behind that decision varies enormously depending on how it was made.

Understanding the methods matters for two reasons. It tells you how much weight to put on an application report when justifying a circuit upgrade. And it tells you what happens to that report when the application vendor changes CDN providers, which happens more often than most teams realize.

The five approaches below are a working framework rather than a formal industry taxonomy. Vendors group them differently, and the boundaries between the last three are genuinely blurry.

Why classification is harder than it looks

Four developments broke the assumptions classification was originally built on.

Port consolidation: Applications converged on TCP 443. Web apps, SaaS platforms, VPN tunnels, messaging clients, remote access tools, and a considerable amount of malware all use the same port, which reduced port numbers from an identifier to a hint.

Encryption: TLS conceals payload, so signature matching against application-layer content stops working. TLS 1.3 additionally encrypts the certificate exchange. Encrypted Client Hello conceals the SNI hostname, though ECH is not yet universally deployed, so SNI remains visible on a substantial share of connections today. SNI is degrading as a signal, and it has not gone away.

Cloud and CDN infrastructure: Applications no longer map to stable IP ranges. A single CDN address serves thousands of unrelated services, and the address serving an application today may serve something else next month.

The move to QUIC: A growing share of what used to be TCP 443 now runs as QUIC over UDP 443, and this changes every method on this page. Port maps that only know TCP 443 report it as unknown. DPI loses more ground, because QUIC encrypts most of the handshake including much of what TLS 1.2 left readable. Statistical classification has to be retrained, since QUIC's packet size and timing profile differs from TCP. And the flow records themselves change: no TCP flags and no session teardown, so cache expiry rather than a FIN determines where a record ends.

The result is that classification moved from deterministic identification toward weighted inference, and the honest reports say which.

One consequence is worth stating early, because it runs against the usual narrative. Port-based classification is largely finished for application reporting and remains useful for security work, since the protocols that lateral movement and reconnaissance run on mostly stayed on their assigned ports.

Port-based classification

Port-based classification maps the transport port number to a service using registered assignments.

How it works: IANA maintains the service name and port number registry: 22 for SSH, 25 for SMTP, 53 for DNS, 3389 for RDP. Registration guarantees nothing about what actually uses a port, and for a subset of protocols convention has held.

Where it still works: Infrastructure protocols that stayed on their assigned ports. DNS, NTP, SNMP, LDAP, Kerberos, SMB, and RDP are all reliably identified this way, and their expected ports are well enough defined to make them useful signals for security monitoring.

Where it fails: Anything on 443, TCP or UDP, which is most user-facing traffic. It also fails whenever an application deliberately uses a common port for evasion, which is a standard technique.

Cost: Effectively zero. Available from any flow record with no additional processing.

Verdict: Retain it for infrastructure protocols and security detection. Treat it as insufficient on its own for modern application reporting.

Deep packet inspection

Deep packet inspection classifies traffic by examining packet payload for application-layer signatures.

How it works: The engine reads protocol headers, characteristic byte sequences, and handshake structures. Open-source engines such as nDPI implement this approach and are widely used.

Strengths: Where payload is readable, DPI provides the most granular identification available. It distinguishes the application, and frequently the specific function within it.

Limits: It requires packet access, so it needs a probe, SPAN or mirror port, or an inline position. Flow records alone do not carry what it reads. It is compute-intensive at high throughput. And its core capability degrades under encryption, which now covers the majority of traffic.

Distinction: Traditional DPI operates on packets, and flow-based platforms operate on exported records. The two are frequently combined: a packet sensor deployed at selected segments performs DPI locally and feeds enriched records back into the same flow dataset. That is a deployment pattern, and it is how most estates get DPI-grade detail on the few segments where they need it.

Modern DPI engines partially compensate for encryption by reading unencrypted handshake elements, including SNI where present and certificate details on TLS 1.2 and below. That compensation shrinks as TLS 1.3, ECH, and QUIC deployment continues. See encrypted traffic analysis for what remains readable.

Verdict: Valuable at a small number of high-value inspection points. Difficult to scale estate-wide because of the packet access and processing requirements.

Device-assisted classification

Device-assisted classification means the network device performs the classification itself and exports the result inside the flow record.

How it works: Cisco NBAR2 identifies applications on the router and exports the identifier through Flexible NetFlow and AVC. Palo Alto App-ID, Fortinet application control, and equivalent firewall features do the same, exporting through IPFIX enterprise-specific information elements. RFC 7011 permits vendor-defined elements for exactly this purpose.

Strengths: The classification happens where the device already has payload access, on a device already in the path. The collector receives the answer without doing the work. Firewall-sourced exports frequently include username as well, which is the single most valuable enrichment available.

Limits: It depends on the device's own classification library, which needs updating as applications change. Coverage differs by vendor and by license tier. And it only covers traffic that traverses a classifying device, so internal east-west traffic between two hosts on one switch remains unclassified.

Evaluation point: This is where flow collectors differentiate sharply. A collector that ingests IPFIX but discards enterprise-specific elements throws away the richest field in the record. Ask any prospective vendor to show a decoded firewall template with vendor fields named rather than displayed as numeric element IDs, as covered in how to choose a network traffic analysis tool.

Verdict: A practical high-accuracy approach for many enterprises, because it reuses classification work the network is already doing.

Endpoint and metadata inference

Endpoint and metadata inference identifies the application from the destination and connection context instead of from content.

How it works: Inputs include destination IP checked against published service ranges (major SaaS providers publish theirs), ASN and hosting provider, reverse DNS, SNI where visible, and correlated DNS queries preceding the connection.

Strengths: Works from flow records alone with no packet access. Unaffected by payload encryption. Scales across the whole estate.

Limits: CDN and cloud consolidation is the core problem. A shared CDN address tells you the delivery network and not the service behind it. Published IP ranges change and require maintenance. Correlating DNS to flow requires collecting resolver logs and joining them by time and client, which is straightforward and not automatic.

Verdict: A practical foundation for estate-wide flow-based classification, strongest for services with identifiable dedicated infrastructure and weaker for anything behind shared CDN capacity.

Statistical and behavioral classification

Statistical and behavioral classification identifies traffic by its shape: what a conversation looks like, independent of content or destination.

How it works: Features include packet size distribution, inter-arrival timing, directional byte ratio, session duration, and burst structure. A video call, a file download, an interactive shell, and a beacon each produce distinguishable shapes.

Strengths: Unaffected by payload encryption, since it uses only metadata. Can identify application categories even for services it has never seen. This is the method that keeps working as everything else erodes.

Limits: It typically produces categories (video conferencing, bulk transfer, interactive session) instead of specific product names. Accuracy depends on training data resembling your environment. Applications that change their transport behavior, as anything moving from TCP to QUIC has done, degrade previously trained models.

Verdict: Increasingly important, and most useful in combination with the other methods. Machine learning in network traffic analysis covers the modeling side.

Classification methods compared

How a real classification cascade works

Production classification cascades. Tools do not pick one method and stand on it. Device-assisted results are used where available, endpoint inference fills the gaps, port mapping handles infrastructure protocols, and behavioral classification catches what the others cannot name.

Traced through a single flow:

1. A flow arrives from a branch router, internal host to 13.107.x.x, TCP 443, 240 MB outbound over 40 minutes.
2. Device-assisted check: The record carries no NBAR2 or enterprise application field, because this router exports basic NetFlow v9. No answer.
3. Port check: TCP 443. Confirms TLS and identifies nothing further.
4. Endpoint inference: The destination falls inside a published Microsoft service range. Returns "Microsoft 365," with the caveat that the range is shared across several services.
5. Behavioral check: Sustained outbound transfer with large packets and low interactivity. Consistent with a file sync rather than an interactive session, which narrows the category.
6. Final label: Microsoft 365, probable OneDrive sync, medium confidence. The service is confidently identified. The specific application within it is inferred.

A report that displays that as "Microsoft 365: 34%" is correct. A report that displays it as "OneDrive: 34%" is claiming more than the evidence supports, and that difference is important when the number is being used to justify a circuit.

Classifying internal and custom applications

This is where classification actually fails in enterprises, and where you have the most control.

No signature library knows your ERP system on port 8443, your internally developed logistics application, or the licensing server a business unit stood up four years ago. NBAR2 does not have a signature for them. Endpoint inference sees a private IP range. Behavioral classification can place them in a category and cannot name them. In practice these applications land in "unknown" or "other," which is frequently a large share of internal traffic and exactly the share a capacity conversation needs identified.

The workable approach is definition by infrastructure, since no signature will ever exist:

• Define by server plus port plus protocol: Your applications live on known hosts. A custom definition matching destination IP or subnet plus port identifies them deterministically, and deterministic is better than inferred.
• Group by server role, using a subnet or IP group: Application tiers move between hosts. A subnet or IP group definition survives a server migration; a single-address definition does not.
• Assign an owner to the definitions: They decay. An application moved to a new subnet stops being classified, silently, and the traffic reappears as unknown months later.
• Audit unknown traffic quarterly: Sort by volume, identify the top talkers, and add definitions for anything material. This is usually a short exercise with a disproportionate effect on report quality.

How accurate is network traffic classification?

Accuracy depends on three variables the headline number rarely states: the traffic mix it was measured against, the granularity it was measured at, and what the tool does with traffic it cannot identify.

Vendor claims of high classification accuracy are usually true and often answer a different question than the one you are asking.

Accuracy over which traffic mix? A tool measured against a benchmark heavy in identifiable protocols scores differently against an estate that is 80% TLS to shared CDN infrastructure.

Accuracy at what granularity? Identifying traffic as "Microsoft" is easier than identifying it as "Teams" and much easier than identifying it as "Teams screen sharing." Claims rarely state which level was measured.

What happens to unclassified traffic? A tool that classifies 70% correctly and labels 30% as unknown is more useful than one that classifies 70% correctly and guesses on the rest, because the second one hides its uncertainty inside your reports.

The practical test: Pick five applications you care about, generate known traffic from a known host, and check what the tool reports. Run the same test again after a month, since CDN changes break inference-based classification silently.

How NetFlow Analyzer identifies applications

ManageEngine NetFlow Analyzer combines several of the methods above instead of relying on one, prioritizing classification already performed by network devices where those fields are exported.

Answering the three accuracy questions from the section above, since a page that sets a test should take it:

Traffic: Accuracy depends on how much of your estate exports device-assisted application fields. An environment with NBAR2 on the WAN edge and application-aware firewalls classifies at a materially higher rate than one exporting basic NetFlow v5 only. Measure it on your own traffic during the trial.

Granularity: Application level where device-assisted fields supply it, service or provider level where endpoint inference is doing the work, and protocol level for infrastructure traffic. Custom definitions give exact naming for internal applications.

Unclassified traffic: Reported as unidentified rather than assigned a best guess, so the share you cannot see is visible in the report instead of hidden inside it. Use the custom application definitions to reduce it.

Frequently asked questions