Traffic baselining

The practice of learning what normal traffic, device load, and application behaviour look like so anomalies stand out. In DDoS defence, baselining helps teams distinguish real attack patterns from ordinary spikes and gives them a reference point for earlier, more precise mitigation decisions.

Expanded Definition

Traffic baselining is the disciplined process of measuring normal volume, rate, protocol mix, device behaviour, and timing so security teams can detect meaningful deviation. In NHI and DDoS operations, it is less about “average traffic” and more about establishing a usable pattern of expected behaviour across users, service accounts, APIs, and infrastructure dependencies.

Definitions vary across vendors, because some tools treat baselining as static thresholding while others use adaptive anomaly detection. For NHI security, the distinction matters: a baseline must reflect how a workload normally authenticates, retries, refreshes tokens, and calls downstream services, not just how many requests it sends. That is why baselining aligns closely with NIST Cybersecurity Framework 2.0 detection and monitoring outcomes, while also supporting the identity visibility and governance priorities described in the Ultimate Guide to NHIs.

The most common misapplication is treating a short observation window as a stable baseline, which occurs when teams ignore seasonality, deploy cycles, batch jobs, and third-party traffic dependencies.

Examples and Use Cases

Implementing traffic baselining rigorously often introduces tuning overhead, requiring organisations to balance early anomaly detection against the risk of false positives during legitimate spikes.

• A DDoS defence team learns that an API normally peaks during the first ten minutes of each hour, so a sudden sustained rise outside that pattern becomes actionable sooner.
• An NHI governance team compares token refresh frequency against the Ultimate Guide to NHIs visibility guidance to spot service accounts that begin making unusual outbound calls.
• A cloud platform sets baselines for internal service-to-service requests and flags a workload that starts querying new regions, ports, or endpoints without a deployment change.
• A SOC uses baselined traffic to distinguish a legitimate product launch surge from an attack pattern that amplifies errors, retries, and malformed requests.
• An IAM team correlates baseline shifts with changes in authentication behaviour, using the monitoring principles in NIST Cybersecurity Framework 2.0 to trigger review when machine identities drift from expected use.

Why It Matters in NHI Security

Traffic baselining matters because NHI compromise often appears first as “normal” automation activity until it is not. Stolen API keys, abused service accounts, and compromised agents can generate traffic that looks routine at the packet level while quietly changing destination, frequency, or privilege use. Without a baseline, defenders lose the reference point needed to separate business growth from abuse.

That gap is especially dangerous given that NHI exposure is widespread: NHI Mgmt Group reports that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. Baselining helps shorten dwell time by turning volume shifts, retry storms, and abnormal east-west movement into evidence that can be investigated before damage spreads. It also supports more disciplined incident triage, because teams can compare current behaviour with an established operational reference instead of relying on intuition alone.

Organisations typically encounter the need for traffic baselining only after a sudden spike, noisy outage, or credential misuse forces them to explain why “expected” automation was actually the attack path.

Related resources from NHI Mgmt Group

• When should organisations block anonymous network traffic at login?
• How should teams rotate JWT signing keys without breaking production traffic?
• What is the difference between securing V2X traffic and securing automotive identities?
• What is the difference between routing traffic and governing identity at the edge?