Quick-reference card
| Field | Value |
|---|---|
| Control ID | SC-05 |
| Control Name | Denial-of-service Protection |
| Framework | NIST SP 800-53, Revision 5 |
| Control Family | System and Communications Protection |
| Baselines | LOW MODERATE HIGH |
| Relevance | System (First Party and Third Party) |
| Risk Severity | High |
What this control requires
SC-05 requires organizations to identify the denial-of-service (DoS) attack types targeting their systems and deploy specific countermeasures for each one. The control goes beyond generic network defense. It demands that you catalog the DoS vectors relevant to your environment and match each vector to a defined protective measure.
In practice, this control means your organization can’t treat DoS protection as a single checkbox. You need to assess which protocols, services, and endpoints are vulnerable to resource exhaustion, then deploy targeted safeguards for each category. Those safeguards might include boundary protection devices that filter malicious traffic, increased bandwidth capacity, or service redundancy architectures that keep critical functions available during an attack. The control belongs to the System and Communications Protection family, which focuses on ensuring the integrity and availability of information as it moves through your systems.
The requirement applies across all three NIST SP 800-53 baselines, which signals how fundamental DoS resilience is to every federal and regulated environment. Whether you’re running a small agency system or a large enterprise infrastructure, you’re expected to have documented protections in place and evidence that those protections work against the threat categories you’ve identified.
Why it matters
Most organizations think of denial-of-service protection as a network-layer problem, something you solve with a content delivery network (CDN) or an upstream scrubbing service. That framing misses the broader risk class SC-05 addresses. Any service endpoint that can be programmatically exhausted without authentication or rate limiting is a DoS vector, whether the exhaustion happens at the network layer, the application layer, or a third-party integration like SMS delivery.
SMS pumping and volumetric authentication abuse
Organizations that expose SMS-based notification or authentication endpoints without rate limiting are vulnerable to a specific form of resource exhaustion known as SMS pumping. In this attack pattern, mapped to MITRE ATT&CK technique T1496.003, adversaries programmatically trigger SMS sends using bot-generated or premium-route phone numbers. The result is thousands of messages per hour billed against the organization’s SMS provider account.
The attack surface is often a login page, account registration form, or password reset flow that sends an SMS to any phone number a user supplies. Without request rate limiting, CAPTCHA validation, or phone number verification, attackers automate submissions to generate traffic at scale. Legitimate users attempting to authenticate experience service degradation, while the organization absorbs unexpected financial costs from carrier charges.
The broader consequence extends beyond cost. When an attacker can exhaust an authentication service through network flooding, resource-intensive request patterns, or SMS pumping against a code delivery endpoint, legitimate users lose access. If that service is a critical authentication path such as multifactor authentication (MFA) delivery or password reset, the outage can trigger insecure fallback behaviors. Helpdesk bypasses forced by the outage then become an attack vector in their own right.
What attackers exploit
- Unauthenticated API endpoints that accept unlimited requests without rate limiting or input validation
- SMS and email notification services that deliver messages to any supplied address without verification
- Resource-intensive operations like search queries, report generation, or file processing that can be triggered at scale
- Authentication flows that lack CAPTCHA, progressive delays, or account lockout thresholds
- Application-layer vulnerabilities where a small number of crafted requests consume disproportionate server resources
How to implement
The most common failure mode for SC-05 implementation isn’t missing technology. It’s a mismatch between the DoS vectors an organization faces and the protections it has deployed. Teams purchase a network-layer DDoS mitigation service and consider the control satisfied, while application-layer and service-integration attack surfaces remain unprotected.
For your organization
Start by conducting a DoS threat assessment that catalogs every service endpoint, protocol, and integration point in your environment. Group these endpoints by attack category: network-layer volumetric attacks, protocol-level exploits, application-layer resource exhaustion, and third-party service abuse like SMS pumping.
For each category, define and deploy specific countermeasures. Network-layer protections should include boundary devices such as firewalls and intrusion prevention systems (IPS) that filter known malicious traffic patterns, combined with upstream DDoS mitigation services that absorb volumetric floods before they reach your infrastructure. A web application firewall adds application-layer inspection that catches request patterns designed to exhaust backend resources.
Implement rate limiting and request throttling on all public-facing endpoints, with particular attention to authentication flows. SMS and email notification endpoints should validate recipient addresses before sending, enforce per-session and per-IP rate limits, and implement CAPTCHA or progressive challenge mechanisms. These measures directly address the T1496.003 attack pattern described above.
Build service redundancy into your architecture for critical authentication and notification paths. If your primary MFA delivery channel goes down, you need a documented fallback that doesn’t degrade your security posture. Increased network capacity and bandwidth provide an additional buffer against volumetric attacks, but capacity alone isn’t a substitute for filtering and rate limiting.
Document your DoS protection architecture, including which safeguards protect against which attack categories. This documentation becomes the foundation for your audit evidence. The Breach Risk product helps you maintain continuous visibility into externally exposed endpoints that could serve as DoS targets.
For your vendors
Evaluating vendor DoS resilience requires moving beyond a yes-or-no questionnaire response. Request specific evidence that the vendor has identified its DoS threat categories and deployed matched countermeasures for each one.
Start your assessment by requesting the vendor’s system and communications protection policy, specifically the sections addressing DoS protection. The policy should name the types of DoS events the vendor has assessed and the safeguards deployed for each type. A policy that references only “DDoS protection” without distinguishing between network-layer, application-layer, and service-integration vectors is a red flag.
Ask for architecture documentation showing how boundary protection devices, rate limiting, and service redundancy are configured. Request evidence of capacity planning that accounts for DoS scenarios, including documentation of bandwidth headroom and failover architectures. If the vendor provides authentication services that use SMS or email delivery, ask specifically how those endpoints are protected against volumetric abuse.
Review the vendor’s incident response procedures for DoS events, including escalation paths, communication protocols, and recovery time objectives. Request audit records or test results from DoS simulation exercises. Vendors who have never tested their DoS protections under controlled conditions are unlikely to respond effectively to a real event.
Vendor Risk enables you to continuously monitor your vendors’ security posture and track whether their DoS protections meet your requirements. Use questionnaire responses alongside external scanning data to identify gaps between what vendors claim and what their exposed attack surface reveals.
Evidence examples
| Evidence Type | Example Artifact |
|---|---|
| Protection policy | System and communications protection policy defining DoS event categories, assigned safeguards for each category, and escalation procedures |
| DoS procedures | Documented procedures for identifying, responding to, and recovering from denial-of-service events, including roles and communication protocols |
| Threat catalog | List of assessed DoS attack types (network volumetric, protocol-level, application-layer, service-integration abuse) with mapped security safeguards for each |
| Architecture documentation | System design records showing boundary protection device placement, rate limiting configurations, bandwidth capacity plans, and redundancy architectures |
| Configuration evidence | Firewall rules, IPS signatures, WAF policies, rate limiting thresholds, and CAPTCHA configurations with associated change management records |
| Audit and test records | Logs from DoS simulation exercises, incident response drill results, and system audit records showing safeguard activation during events |
| Security plan | System security plan sections documenting the DoS protection strategy, residual risk acceptance, and continuous monitoring approach |
Cross-framework mapping
No cross-framework mappings are currently configured for SC-05.
Related controls
- CP-02 — Contingency Plan: defines the recovery procedures and alternate processing sites that activate when a DoS event degrades or disables primary systems.
- IR-04 — Incident Handling: establishes the detection, analysis, containment, and recovery processes that your team executes when a DoS event is identified.
- SC-06 — Resource Availability: complements SC-05 by requiring that systems allocate sufficient resources to priority functions, preventing a DoS event from consuming capacity needed for critical operations.
- SC-07 — Boundary Protection: provides the architectural foundation for SC-05 by requiring boundary devices that monitor and filter traffic at external and key internal network boundaries.
- SC-40 — Wireless Link Protection: addresses DoS risks specific to wireless communication channels, where jamming and interference can disrupt availability without touching wired infrastructure.
Frequently asked questions
What is NIST SP 800-53 SC-05?
SC-05 is the denial-of-service protection control in the NIST SP 800-53 framework. It requires organizations to identify the specific types of DoS events that threaten their systems and deploy targeted safeguards to protect against or limit the effects of each event type. The control applies at all three baselines (LOW, MODERATE, HIGH), and compliance requires both documented protection policies and technical evidence that safeguards are configured and operational for each assessed DoS category.
What happens if SC-05 is not implemented?
Without SC-05 protections, your systems are exposed to service disruptions that can prevent legitimate users from accessing critical functions, including authentication and notification services. Unprotected endpoints become targets for volumetric abuse, application-layer exhaustion, and service-integration attacks like SMS pumping against code delivery endpoints. The financial impact compounds through carrier charges, incident response costs, and potential regulatory penalties for failing to maintain system availability.
How do you audit SC-05?
Auditing SC-05 starts with verifying that the organization maintains a current list of assessed DoS attack types with mapped security safeguards for each category. Auditors review system configuration settings, including firewall rules, rate limiting thresholds, and WAF policies, to confirm that deployed protections match the documented threat catalog. They also examine system audit records and DoS simulation test results to verify that safeguards activate as designed under attack conditions.
What types of denial-of-service events does SC-05 cover?
SC-05 covers DoS events from both internal and external sources across multiple protocol layers. The scope includes network-layer volumetric floods, protocol-level exploits, application-layer resource exhaustion, and service-integration abuse such as SMS pumping against authentication endpoints. Organizations must assess which of these event types apply to their specific environment and deploy countermeasures matched to each identified threat category.