By NHI Mgmt Group Editorial TeamPublished 2025-11-04Domain: Breaches & IncidentsSource: DigiCert

TL;DR: Two DDoS events peaking at 2.4 Tbps and 3.7 Tbps, an estimated 3,000 hours of prevented downtime, and malicious web activity rising from 51% to 73% show that scale and automation are now core attack variables, according to DigiCert. The security implication is that resilience planning must account for identity, DNS, and infrastructure interdependence, not just traffic volume.


At a glance

What this is: DigiCert’s latest RADAR brief says DDoS has reached multi-terabit scale, with automation now driving most large attacks.

Why it matters: For IAM and security teams, the finding matters because resilience now depends on controlling identity-adjacent infrastructure and service access, not just absorbing traffic spikes.

By the numbers:

👉 Read DigiCert's RADAR brief on record-scale DDoS and automation


Context

DDoS at this scale is no longer only a network availability problem. When attacks reach multi-terabit volumes and automation drives the majority of malicious web activity, the security question becomes how well identity, DNS, application, and edge controls behave under sustained pressure.

For identity programmes, the relevance is indirect but real. Access paths, administrative portals, certificate services, DNS dependencies, and privileged control planes all sit inside the blast radius when large-scale disruption or bot activity is used to mask broader compromise or to exhaust defensive capacity.


Key questions

Q: How should security teams protect identity services during large DDoS events?

A: Treat identity services as control-plane assets, not ordinary web workloads. Protect DNS, certificates, admin portals, and privileged-access paths with separate resilience controls, then test whether they still function when bandwidth is constrained or routing is unstable. If those dependencies fail together, access control and availability will both collapse under load.

Q: Why do large DDoS attacks matter to IAM and access governance?

A: Because identity depends on services that attackers can indirectly destabilise. If DNS, certificate validation, or admin access becomes unavailable, authentication, approval, and remediation workflows stall. IAM teams should therefore include service resilience in access governance, especially where privilege changes or emergency access rely on online trust infrastructure.

Q: What do teams get wrong about automation-driven attack traffic?

A: They often treat automation as a pure volume problem. In practice, automated abuse also changes detection quality, because bot traffic can hide credential attacks, API misuse, and reconnaissance inside the same telemetry stream. Teams need governance that separates these signals and preserves visibility into privileged activity.

Q: How do organisations know whether their DDoS resilience is actually working?

A: Look beyond uptime alone. A resilient programme preserves access to identity, DNS, and administrative control paths while absorbing or filtering abusive traffic. If the business stays online but admins cannot verify, rotate, or recover trust services, resilience is only partial.


Technical breakdown

Multi-terabit DDoS and the edge control plane

Multi-terabit DDoS attacks overwhelm the bandwidth and packet-processing limits of internet-facing services, but the deeper issue is that the edge is part of the control plane for trust. DNS, WAFs, load balancers, certificate services, and admin endpoints all depend on being reachable, verifiable, and responsive. When those layers degrade together, availability becomes an identity and control problem as much as a transport problem. The operational challenge is not simply absorbing traffic, but preserving trustworthy access paths while attack volume, routing shifts, and service degradation occur at the same time.

Practical implication: map which identity and trust services fail first under edge saturation and protect them separately from ordinary web traffic.

Automation as the multiplier for modern attack traffic

When malicious web activity rises sharply, the relevant change is not only scale. Automation turns probing, bot violations, credential stuffing, and reconnaissance into continuous background pressure that can hide in the same telemetry as volumetric attacks. That means defenders face two problems at once: filtering obviously abusive traffic and detecting machine-paced activity that looks legitimate in isolation. In practice, the boundary between DDoS, bot abuse, and access pressure is thinner than many teams assume, especially when the same infrastructure supports customer access, APIs, and privileged operations.

Practical implication: separate bot, API, and privileged-access telemetry so automated abuse does not drown out identity signals.

DNS errors and infrastructure interdependence

A spike in DNS-related errors shows how quickly one weak dependency can ripple across an environment. DNS is often treated as background plumbing, but in practice it is a trust anchor for service discovery, certificate validation, routing, and user access. Misconfiguration or outage in that layer can look like application failure, authentication failure, or external attack depending on where the symptom surfaces first. The deeper lesson is that resilience depends on understanding chained dependencies, not just hardening isolated systems.

Practical implication: test DNS and certificate dependencies as part of incident exercises, not as separate infrastructure checks.


Threat narrative

Attacker objective: The attacker aims to overwhelm availability, create operational noise, and force defenders to spend capacity on traffic suppression rather than incident response.

  1. Entry occurs through automated bot traffic, distributed nodes, or reflection infrastructure that pushes attack volume toward internet-facing services.
  2. Escalation happens when repeated requests, DNS failures, and multi-terabit floods exhaust edge capacity and obscure other malicious activity.
  3. Impact is service disruption, degraded trust infrastructure, and delayed detection of concurrent abuse patterns across the environment.
  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
  • DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Internet-scale abuse is no longer separable from identity resilience: once DDoS reaches multi-terabit scale, the control question shifts from bandwidth alone to which trust services remain reachable under pressure. DNS, certificate validation, admin portals, and privileged access paths all become part of the attack surface. Practitioners should treat edge resilience as a prerequisite for identity continuity, not as a separate network concern.

Automation has become the default operating model for large-scale abuse: the rise in malicious web activity means defenders must assume constant machine-paced probing, not intermittent bursts. That changes how telemetry is interpreted, how rate limits are tuned, and how false positives are balanced against abuse detection. The implication for security programmes is that identity and bot signals need shared governance, not separate ownership.

Identity blast radius: large attack volumes expose how dependent enterprise trust services are on a small set of reachable control points. When those control points are stressed, the failure is not just service downtime but loss of confidence in access, validation, and administrative control. This is the operating model that resilient identity programmes now have to design around.

Visibility across infrastructure, applications, and identity is the real resilience threshold: the briefing’s core signal is that attackers increasingly combine precision and scale. That forces practitioners to re-evaluate incident playbooks so they can distinguish denial-of-service conditions from broader abuse and preserve privileged access oversight while the environment is under load.

Multi-layer dependency mapping is now a governance issue, not a reliability nicety: the more a service depends on DNS, certificates, APIs, and control-plane access, the more a single fault or attack can cascade. Security teams should treat dependency mapping as part of identity and access governance because the trust chain is only as strong as the least visible upstream service.

From our research:

  • 91.6% of secrets remain valid five days after the targeted organisation is notified, showing a critical gap in remediation procedures, according to the Ultimate Guide to NHIs.
  • From our research: Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
  • For teams facing automation-driven disruption, the next step is to align trust service resilience with identity governance using The 52 NHI breaches Report.

What this signals

Identity resilience now depends on protecting trust services as a distinct control plane. When the same attack conditions can suppress DNS, admin access, and verification workflows, service continuity and identity assurance become inseparable. Teams that still separate network resilience from identity governance will miss the failure mode that matters most: losing the ability to validate and recover trust during an attack.

Automation has moved from a detection nuisance to an operating assumption. With 5.7% of organisations having full visibility into their service accounts, per the Ultimate Guide to NHIs, the challenge is not only scale but attribution. Security programmes need to know which traffic patterns, service credentials, and privileged actions belong to people, workloads, or bots before a real incident compresses decision time.

DNS and identity governance should be exercised together. If one failure in naming, validation, or edge routing can take down privileged access paths, then resilience tests need to include trust recovery, not just service restart. Practitioners should build playbooks that keep control-plane visibility intact while the attack is still active.


For practitioners

  • Map identity-critical dependencies Identify which DNS, certificate, admin, and privileged-access services must remain reachable during attack conditions, then classify them as protected control-plane assets rather than ordinary infrastructure.
  • Separate bot and privileged-access telemetry Ensure automated abuse signals, API traffic, and privileged login events are monitored in different pipelines so machine-paced attacks do not obscure access anomalies.
  • Exercise degraded-mode access Test whether administrators can still verify identity, issue changes, and rotate trust services when edge capacity is constrained or DNS is impaired.
  • Review rate limits against automation patterns Tune detection and throttling based on repeated low-and-slow machine activity, not only obvious flood thresholds, so abuse is caught before it becomes a service event.

Key takeaways

  • Multi-terabit DDoS turns identity resilience into a control-plane problem, because DNS, certificates, and admin access can fail alongside the service.
  • Automation is now a persistent attack multiplier, so teams need telemetry that separates bot abuse, API pressure, and privileged-access signals.
  • The practical response is to test trust recovery under degraded conditions, not just measure whether traffic was absorbed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.PT-5Protective technology must preserve trust services under attack.
NIST Zero Trust (SP 800-207)PR.AC-4Zero trust depends on continuous access verification, even during service degradation.
OWASP Non-Human Identity Top 10NHI-01Service accounts and trust services need visibility and governance during attack conditions.

Verify that identity validation and privileged access still function when edge services are stressed.


Key terms

  • Control Plane: The set of services that govern how systems are validated, configured, and operated. In identity and resilience contexts, it includes DNS, certificates, admin portals, and privileged access paths, because if those services fail, organisations can lose both availability and trustworthy control.
  • Internet Tsunami Attack: A very large distributed denial-of-service event that pushes attack volume beyond ordinary mitigation thresholds. The term describes floods intense enough to stress edge capacity, obscure other malicious activity, and threaten the services that support verification and recovery.
  • Identity Blast Radius: The range of identity services and trust dependencies affected when one part of the environment fails. It helps explain why an attack on DNS, edge routing, or admin access can interrupt authentication, recovery, and privileged operations at the same time.
  • Automation-Driven Abuse: Attack activity that uses machines to generate continuous, repeated, or adaptive pressure against internet-facing services. It matters because automated traffic can blend into normal telemetry, making it harder to spot credential abuse, bot violations, or other access-related threats.

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 governance maturity in your organisation, it is worth exploring.

This post draws on content published by DigiCert: its inaugural RADAR brief on Q3 2025 threat trends. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-11-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org