Internet tsunami DDoS attacks expose the limits of resilience models

At a glance

What this is: DigiCert’s RADAR brief says DDoS attacks reached multi-terabit scale while malicious web automation climbed sharply, exposing the limits of traffic-only resilience models.

Why it matters: For IAM, NHI, and platform teams, the lesson is that availability now depends on identity, DNS, and infrastructure controls working together under automated attack pressure.

By the numbers:

• DigiCert’s network prevented an estimated 3,000 hours of potential website downtime for customers.
• Malicious web activity rose from 51% in July to 73% in September.
• September recorded 32 million bot violations.

Context

DDoS resilience is no longer just a bandwidth problem. When attacks reach multi-terabit scale, the real question is whether supporting controls such as DNS, identity, application protection, and upstream routing can absorb failure without cascading into customer-facing outage.

DigiCert’s Q3 2025 RADAR brief frames the issue as a shift from isolated traffic spikes to blended pressure across infrastructure and automation. That matters because availability control is now inseparable from the identity and trust systems that route, authenticate, and protect service delivery.

Key questions

Q: What breaks when DDoS resilience is planned only around traffic volume?

A: Traffic-only planning misses the control-plane dependencies that decide whether an organisation stays reachable. DNS, application delivery, and identity systems can fail before raw bandwidth is exhausted. The result is that resilience looks adequate on paper but still collapses when the attack hits shared trust and routing layers.

Q: Why does automation make modern DDoS attacks harder to contain?

A: Automation raises request volume, increases concurrency, and removes the delay defenders usually rely on for manual review. That means malicious activity can dominate traffic patterns faster than operators can respond, so mitigation has to rely on continuous detection, not just human-in-the-loop escalation.

Q: How do you know if your DDoS controls are actually working?

A: Look for whether the business stays reachable when upstream services are stressed, not just whether a mitigation platform reports blocked packets. If DNS, identity, or application controls still degrade user access during attack surges, the resilience model is only partially working.

Q: What is the difference between DDoS protection and resilience governance?

A: DDoS protection is the technical mitigation layer that absorbs or filters attack traffic. Resilience governance is the broader discipline that maps which dependencies, including DNS and identity services, must keep functioning for the organisation to remain available under stress.

Technical breakdown

Why multi-terabit DDoS breaks traffic-only resilience models

Multi-terabit DDoS attacks overwhelm assumptions that resilience can be modelled as simple throughput headroom. At this scale, availability depends on how quickly mitigation can absorb packets, how cleanly traffic can be filtered, and whether upstream dependencies stay intact under sustained load. The article’s point is not just that attacks are larger, but that the attack surface is now distributed across network, DNS, and application entry points. For identity teams, that matters because access paths, trust anchors, and service availability are coupled in ways classic perimeter thinking does not capture.

Practical implication: Treat availability as a multi-control outcome, not a network-only problem.

How automation changes DDoS attribution and response

The brief shows malicious web activity rising from 51% to 73%, with 32 million bot violations in September alone. That indicates automated traffic is now a core operating layer of large-scale attack campaigns, not a side effect. In practice, bots compress attacker cost, increase concurrency, and make simplistic allowlist or volume-based response less effective. For identity and access programmes, automation also means that trust signals need to be evaluated continuously because the attack does not pause for manual review cycles.

Practical implication: Build detection and response logic that assumes machine-speed attack orchestration.

Why DNS errors expose the hidden dependency chain behind resilience

The 22,000% jump in DNS errors from misconfigurations is a reminder that resilience failures often begin in the control plane, not the packet flood. DNS sits upstream of many identity, routing, and application decisions, so a misconfiguration can amplify or misroute traffic long before DDoS mitigation engages. That makes DNS a governance issue as much as a technical one. The practical question is whether teams know which service identities, routing policies, and trust dependencies are exposed when DNS integrity slips.

Practical implication: Map DNS as part of the resilience boundary, not as an isolated utility.

Threat narrative

Attacker objective: The objective is to degrade availability at scale and force operational disruption across internet-facing services.

1. Entry begins through large-scale bot activity and distributed traffic sourced from multiple regions, allowing the attacker to flood services without relying on a single compromised host.
2. Escalation comes from automation that increases request volume and concurrency, pushing mitigation systems and upstream dependencies toward saturation.
3. Impact is service degradation or outage pressure across websites, DNS, and related digital trust services, with customer downtime avoided only where mitigation holds.

Breaches seen in the wild

• CISA Private-CISA GitHub leak 2026: A CISA contractor's public GitHub repo exposed AWS GovCloud admin keys, Artifactory credentials and plaintext passwords for six months.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Multi-terabit DDoS is now a resilience-governance problem, not a traffic-management problem. Once attacks reach 2.4 Tbps and 3.7 Tbps, the issue is whether the organisation has designed for dependency failure across DNS, application delivery, and identity-aware control planes. Traffic volume is only the symptom; the deeper issue is which services collapse first when the attack saturates shared trust and routing layers. Practitioners should model availability as a chain of identity and infrastructure decisions, not a single mitigation device.

Automation has become the attacker’s force multiplier, and that changes how defenders should think about trust. A rise from 51% to 73% malicious web activity means the defender is no longer dealing mainly with episodic human-driven abuse. Automated campaigns compress attacker dwell time and outpace manual approval loops, so governance models built around operator review are too slow for the condition being attacked. The implication is that identity and access control must be evaluated as runtime systems, not static approval workflows.

DNS misconfiguration is a resilience failure mode because it breaks the control plane before the outage is visible. A 22,000% spike in DNS errors shows that the weakest point in a resilience architecture may be upstream of the systems that teams normally monitor. When DNS integrity fails, service reachability, routing consistency, and trust resolution all degrade together. Practitioners should treat DNS as part of the same governance surface as access and infrastructure, because availability cannot be separated from name resolution.

Identity now sits inside the resilience blast radius, which means availability teams and IAM teams can no longer operate as separate disciplines. The article’s own framing about visibility across infrastructure, applications, and identity reflects a broader market shift: resilience is increasingly an identity-dependent property. When trust, routing, and access are interlocked, a weakness in one layer changes the outcome in the others. The practical conclusion is that identity governance has become part of business continuity design, not an adjacent security concern.

Internet tsunami attacks expose an identity blast radius that classic resilience models do not measure. That concept is useful because it captures how a surge in traffic can cascade into certificate validation, DNS reachability, application control, and user access at the same time. The point for practitioners is not to overfit to DDoS as a single threat type, but to assess which identity and trust dependencies become unavailable when the internet itself becomes the battlefield.

What this signals

Identity and availability are converging into one governance problem. The article’s strongest signal is that resilience can no longer be measured only by traffic absorption or uptime percentages. When access, DNS, and application delivery share the same failure path, identity leaders need to participate in continuity planning rather than wait for an incident review.

Bot-heavy attack patterns should change how teams assess control-plane risk. Malicious automation now drives the scale of the attack, which means the defender’s challenge is not just volume suppression but maintaining trustworthy routing and access decisions under machine-speed pressure. The practical signal is to test whether your identity and DNS controls still behave predictably when automation surges.

For practitioners

• Model availability as a dependency chain Map DNS, application delivery, and identity services as linked failure domains so you can see where a DDoS event creates cascading outage rather than isolated saturation.
• Separate bot-driven traffic from human activity Tune detection and mitigation workflows for automated request patterns, because malicious web activity now dominates large-scale attack campaigns and can distort manual triage.
• Review DNS as a resilience control Validate DNS configuration governance, failover behaviour, and change control alongside uptime targets, because control-plane errors can intensify the impact of volumetric attacks.
• Align IAM and continuity teams on shared dependencies Use one resilience map for access, trust, and service delivery so IAM does not operate on assumptions that continuity planning never sees.

Key takeaways

• DDoS resilience now depends on more than packet filtering because identity, DNS, and application delivery can fail together under sustained attack.
• The article’s evidence points to a shift from isolated incidents to automated, high-volume campaigns that stress control planes as much as networks.
• Practitioners should treat continuity, access, and trust services as one dependency map, because that is where modern outage risk is concentrated.

Key terms

• DDoS Resilience: DDoS resilience is the ability to keep services available while absorbing or degrading large volumes of malicious traffic. In practice it depends on upstream controls such as DNS, routing, application protection, and identity services continuing to operate when pressure spikes.
• Control Plane: The control plane is the set of actions that create, configure, or manage a service. For AI workloads, it covers deployment and administration of the model platform, while data-plane permissions govern what the service and its identities can read or process.
• Malicious Automation: Malicious automation is the use of bot-driven or scripted activity to generate attacks at machine speed and scale. It matters because it compresses the attacker’s timeline and reduces the effectiveness of manual response loops across identity, network, and application controls.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.