Notifications
Clear all
Topic starter
24/06/2026 8:03 pm
TL;DR: About 85% of observed DDoS attacks lasted less than twenty minutes, and nearly 73% of detected attacks stayed between 0.0 and 0.5 Gbps, which makes early identification central to reducing downtime, according to DigiCert. Fast detection changes DDoS from a black swan outage into a containable availability incident.
NHIMG editorial — based on content published by DigiCert: Early DDoS Detection: Your First Line of Defense
By the numbers:
- Approximately 85% of observed DDoS attacks lasted less than twenty minutes.
Questions worth separating out
Q: How should security teams detect DDoS attacks before users notice an outage?
A: Use layered monitoring that combines traffic telemetry with service performance data.
Q: Why do short DDoS attacks still create serious operational risk?
A: Short attacks are often probes, not the full campaign.
Q: What signals indicate a DDoS event is moving from probe to escalation?
A: Watch for rising traffic from unfamiliar IP ranges, repeated handshake failures, new geographic clusters, increasing application errors, and growing latency.
Practitioner guidance
- Baseline traffic against service health together Correlate NetFlow or sFlow with SNMP, synthetic transactions, RUM, and APM so unusual traffic and user-facing degradation are visible in the same monitoring view.
- Tune alerts for low-volume reconnaissance Lower the threshold for investigating short bursts, incomplete handshakes, unusual geography, and off-hours spikes because many attacks remain below obvious bandwidth alarms.
- Pre-authorise mitigation paths Document when to trigger rate limiting, selective IP blocking, traffic shaping, DNS diversion, or BGP-based scrubbing so responders do not improvise under pressure.
What's in the full article
DigiCert's full blog covers the operational detail this post intentionally leaves for the source:
- Specific telemetry combinations used for detection, including how NetFlow, sFlow, and SNMP are applied in practice
- Concrete examples of DDoS indicators such as incomplete TCP handshakes, geography anomalies, and application error patterns
- Response differences between always-on and on-demand mitigation workflows, including activation behaviour and notifications
- Implementation detail on how DigiCert UltraDDoS Protect applies detection and alerting in real time
👉 Read DigiCert's analysis of early DDoS detection and response →
DDoS detection gaps: are your controls catching attacks early?
Explore further
25/06/2026 4:56 am
Early DDoS detection is an availability governance control, not just an operations metric. The article correctly treats speed of detection as the main determinant of outcome, because the first minutes decide whether defenders can scope, filter, and preserve service. For identity programmes, that matters because authentication, API trust, and admin workflows all fail when availability is lost. Teams should treat detection latency as a resilience risk indicator, not a reporting detail.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
A question worth separating out:
Q: Who is accountable for DDoS resilience when identity and access services are affected?
A: Accountability should sit across network operations, application owners, and identity platform teams because DDoS can break login flows, token services, and machine APIs at the same time. NIST Cybersecurity Framework 2.0 is useful here because it makes resilience, detection, response, and recovery a shared governance obligation rather than a single-team problem.
👉 Read our full editorial: Early DDoS detection is the difference between probe and outage
