SC-31(2): Maximum Bandwidth

SC-31(2): Maximum Bandwidth requires you to identify covert channels in your system and reduce their maximum bandwidth to an organization-defined limit, so those channels cannot reliably exfiltrate meaningful data. To operationalize it, you need a repeatable method to find candidate covert channels, set explicit bandwidth caps, implement technical throttles, and retain evidence that the caps are enforced and monitored. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Key takeaways:

• You must name the covert channels you’re addressing and set a measurable bandwidth maximum for each. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• “Reduce bandwidth” must translate into enforceable technical controls (rate limits, scheduling, queue caps), not just documentation. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Audit success depends on artifacts: channel inventory, rationale for thresholds, configurations, and test/monitoring results. (NIST SP 800-53 Rev. 5)

The sc-31(2): maximum bandwidth requirement is a practical containment control for covert channels. A covert channel is any unintended path that can transfer information in a way your normal access controls and monitoring may miss, such as timing signals, shared resource contention, or repurposed protocol fields. SC-31(2) assumes you have already identified covert channels (or at least plausible ones) and now must limit how much information they can carry by reducing their bandwidth to an explicit threshold. (NIST SP 800-53 Rev. 5 OSCAL JSON)

For a CCO or GRC lead, the fastest path is to treat this like an engineering requirement with clear acceptance criteria: (1) a defined list of in-scope covert channels (or channel classes), (2) an organization-defined maximum bandwidth value for each, and (3) implemented throttles plus proof they work. Your greatest risk is not technical impossibility; it’s ambiguous scope (“we don’t have covert channels”), missing thresholds (“we reduce it”), and missing operational evidence.

This page gives requirement-level guidance you can hand to security engineering and then use to drive assessment readiness, including step-by-step implementation, evidence to retain, and common audit traps. Primary sources are NIST SP 800-53 Rev. 5 and the OSCAL catalog text for SC-31(2). (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON)

Regulatory text

Control requirement (SC-31(2)): “Reduce the maximum bandwidth for identified covert [assignment: organization-defined] channels to [assignment: organization-defined].” (NIST SP 800-53 Rev. 5 OSCAL JSON)

What the operator must do

1. Identify covert channels you consider credible in your environment (specific channels or a class such as “timing channels across multi-tenant compute”). (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. Define maximum bandwidth values (your thresholds) for those channels. These thresholds must be measurable, even if you measure indirectly (rate of events, queue depth, scheduling frequency, packet rate). (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. Implement controls that enforce those maxima, then verify the maxima are actually reduced compared to a baseline or prior state. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Plain-English interpretation (what SC-31(2) means in practice)

If a covert channel exists, you may not be able to eliminate it quickly. SC-31(2) tells you to make it “low capacity” so it’s impractical for meaningful data transfer. Your job is to pick the covert channels you care about, set a cap for each, and prove the cap is in place.

A useful way to phrase the requirement for engineering is:

“For each identified covert channel, implement a technical mechanism that limits its information transfer rate to the defined maximum, and maintain test and monitoring evidence that the limit remains effective.” (NIST SP 800-53 Rev. 5 OSCAL JSON)

Who it applies to (entity and operational context)

SC-31(2) commonly applies where NIST SP 800-53 is a contractual, programmatic, or authorization baseline requirement, including:

• Federal information systems (internal agency systems). (NIST SP 800-53 Rev. 5)
• Contractor systems handling federal data (for example, systems supporting federal programs where 800-53 controls are flowed down). (NIST SP 800-53 Rev. 5)

Operationally, it matters most in environments that increase covert-channel risk:

• Multi-tenant compute or shared clusters (shared CPU cache, memory bus, storage backends).
• High-assurance enclaves with strict data separation goals.
• Systems with constrained monitoring visibility (encrypted traffic, limited host telemetry).
• Segmented networks where cross-zone signaling is the concern.

What you actually need to do (step-by-step)

1) Assign ownership and define scope

• Control owner: typically Security Architecture or Platform Security; GRC owns governance and evidence.
• Scope statement: list in-scope systems, environments, and boundaries (prod only vs prod+nonprod, corporate vs regulated enclave).
• Dependency check: confirm SC-31 base control implementation is not blocked; SC-31(2) presumes you can identify covert channels worth addressing. (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON)

Deliverable: “SC-31(2) Implementation Procedure” with owners, systems, and evidence cadence.

2) Build a covert channel inventory (practical, not theoretical)

Create a register with one row per channel or channel class. Keep it short, opinionated, and defensible.

Minimum fields:

• Channel name/class (e.g., “Network timing via packet inter-arrival”).
• Affected components (hosts, hypervisors, load balancers, message brokers).
• Threat scenario (what could be signaled, across what trust boundary).
• Current controls (if any).
• Proposed bandwidth maximum (next step).

How to find candidates quickly:

• Review prior pen test findings and red-team notes for “timing,” “side channel,” “covert channel,” “shared resource,” “metadata leakage.”
• Review architecture for shared resources across trust zones (shared caches, shared queues, shared storage).
• Ask engineering: “Where do you rely on ‘no one would notice’ signaling?” You’ll hear about health checks, retries, backoff, and queue behavior.

3) Define “maximum bandwidth” thresholds that you can enforce

SC-31(2) requires organization-defined values. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Set thresholds in operational units you can control:

• Network: packets per second, connections per minute, DNS queries per interval, request rate per client/service.
• Compute/shared resources: scheduling frequency, jitter injection parameters, resource quotas, contention limits.
• Messaging/queues: max message rate, queue depth caps, consumer concurrency caps.
• Logging/telemetry: rate limits on event emission that could become a channel (rare but real in restricted environments).

Decision rule (document it): choose thresholds based on the data classification and separation objective for the boundary where the covert channel exists. Tie the threshold to risk acceptance language and system categorization artifacts where available under your program.

4) Implement enforceable technical controls to reduce bandwidth

Pick controls that are hard to bypass and easy to evidence:

Network-level controls

• Ingress/egress rate limiting at load balancers, API gateways, WAFs, or host firewalls.
• DNS rate limiting and response policy zones where DNS signaling is plausible.
• Connection limits and retry/backoff enforcement at the edge.

Application/platform controls

• Queue throttles and worker concurrency limits.
• Token buckets per identity, service account, or workload.
• Fixed scheduling slices or minimum intervals between sensitive operations.

Side-channel mitigations (where applicable)

• Strong tenant isolation patterns, dedicated hosts for high-sensitivity workloads, and resource partitioning controls that reduce shared-state signaling. Keep claims modest and focus on what you can prove with configuration and design documentation.

Implementation acceptance criteria:

• Each identified channel has a mapped control mechanism and a configuration location.
• The configuration explicitly encodes the bandwidth maximum (or parameters that imply it).
• There is a test that demonstrates the cap, plus monitoring that detects drift.

5) Verify effectiveness with tests you can rerun

Auditors will ask how you know the bandwidth was reduced.

Testing patterns:

• Controlled signaling test: attempt to transmit a known pattern through the suspected channel; show observed transfer rate is at or below the defined maximum.
• Stress and throttling test: generate high-rate events and prove rate limits clamp traffic.
• Regression test: rerun after platform upgrades or policy changes.

Keep tests lightweight and automatable. If you cannot safely test in production, do it in a representative pre-prod environment and document equivalence assumptions.

6) Operationalize: monitoring, change control, and evidence production

• Add bandwidth-limit configs to configuration management and change control.
• Monitor for rate-limit disabled, policy deleted, quota raised, or throttle errors that indicate bypass attempts or misconfiguration.
• Define an evidence schedule aligned to your assessment cadence ¹. This is a policy choice; SC-31(2) does not prescribe a frequency. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Daydream tip (earned mention): teams struggle to keep channel inventories, thresholds, and recurring artifacts synchronized. Daydream can act as the control system of record by mapping SC-31(2) to a named owner, a written procedure, and a standing evidence checklist so assessment requests don’t become a scavenger hunt. (NIST SP 800-53 Rev. 5)

Required evidence and artifacts to retain

Use an “evidence packet” format so you can hand it to assessors in one export.

Artifact	What it proves	Good enough looks like
Covert Channel Register	You identified covert channels in scope	Dated register, scoped to systems, with channel descriptions and owners
Bandwidth Threshold Standard	Your organization-defined maxima exist	A table of channels/classes and maximum bandwidth values with rationale
Configuration Evidence	The limits are enforced	Screenshots/exports of rate-limit/quota configs; IaC snippets; policy IDs
Test Results	The limits work	Test plan + dated results showing observed rate ≤ maximum
Monitoring/Alert Rules	Ongoing control operation	Alert definitions for config drift and rate-limit changes, plus sample alerts
Change Records	Governance	Tickets/approvals for threshold changes and exceptions

Common exam/audit questions and hangups

1. “What covert channels did you identify, and how?” Bring the register and your identification method. (NIST SP 800-53 Rev. 5 OSCAL JSON)
2. “Where are the organization-defined thresholds documented?” Show the standard with explicit values. (NIST SP 800-53 Rev. 5 OSCAL JSON)
3. “How do you know the bandwidth is reduced?” Show the test results and monitoring.
4. “What happens when engineering needs to raise a limit?” Show change control and risk acceptance workflow.
5. “Does this apply across third parties and managed services?” If a third party operates part of the boundary (CDN, managed Kubernetes, SaaS integration), show how your contract/architecture enforces equivalent throttles or compensating controls.

Frequent implementation mistakes (and how to avoid them)

• Mistake: No defined thresholds. “We limit it” fails SC-31(2). Put numeric or otherwise measurable maxima in writing, per channel/class. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Mistake: Treating covert channels as purely theoretical. Pick a short list of plausible channels tied to your architecture. A small, defensible scope beats a sprawling, unmaintainable taxonomy.
• Mistake: Limits exist but are bypassable. Edge throttles that can be avoided via internal paths will not hold up. Document enforcement points and ensure they sit at the right trust boundary.
• Mistake: No verification. Configuration screenshots without a test invite the question: “Does it actually cap throughput?” Keep a repeatable test.
• Mistake: Evidence scattered across teams. Centralize ownership and evidence production. A GRC tool like Daydream helps by turning SC-31(2) into a named procedure with recurring artifact requests.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this guidance focuses on assessment and authorization risk rather than citing enforcement outcomes. (NIST SP 800-53 Rev. 5; NIST SP 800-53 Rev. 5 OSCAL JSON)

Risk-wise, SC-31(2) gaps show up as:

• Confidentiality failures across separation boundaries (data exfiltration in low-and-slow form).
• Assessment findings for incomplete organization-defined parameters and missing operational evidence. (NIST SP 800-53 Rev. 5 OSCAL JSON)
• Authorization friction when system owners cannot explain how bandwidth limits were selected and verified. (NIST SP 800-53 Rev. 5)

Practical 30/60/90-day execution plan

First 30 days (Immediate)

• Assign control owner and publish the SC-31(2) procedure and evidence checklist.
• Build the initial covert channel register for the highest-sensitivity systems.
• Define initial bandwidth maxima for each channel/class and get risk sign-off.

Days 31–60 (Near-term)

• Implement throttles at the primary enforcement points (edge, gateway, queue, scheduler).
• Create and run verification tests; store results in the evidence packet.
• Stand up monitoring for configuration drift and limit changes.

Days 61–90 (Operationalize)

• Expand scope to additional systems and third-party touchpoints.
• Integrate checks into CI/CD (policy-as-code where possible) and change management.
• Run a tabletop: “Engineer requests higher bandwidth; what approvals and re-testing happen?” Update procedure based on findings.

Frequently Asked Questions

What counts as a “covert channel” for SC-31(2)?

Treat it as any unintended path that can carry information across a boundary outside your normal authorized flows, including timing and shared-resource behavior. Your register should document which channels you consider credible in your architecture. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Do we have to eliminate covert channels completely?

SC-31(2) is about reducing maximum bandwidth for identified covert channels to an organization-defined limit. You can meet this enhancement by implementing enforceable caps and proving the reduced capacity through tests and monitoring. (NIST SP 800-53 Rev. 5 OSCAL JSON)

How do we pick the “organization-defined” maximum bandwidth value?

Pick a measurable threshold you can enforce at a control point and justify it based on the boundary’s confidentiality needs and threat model. Document the rationale and require change control for any increases. (NIST SP 800-53 Rev. 5 OSCAL JSON)

What evidence do assessors ask for most often?

Expect requests for the covert channel inventory, the documented maxima, device/service configurations that enforce the maxima, and verification results that show the cap is effective. Keep these artifacts packaged per system boundary. (NIST SP 800-53 Rev. 5)

How does this work in cloud and managed services where we can’t control the hypervisor?

Focus on the control points you do control: network egress throttles, API gateway limits, queue and concurrency limits, and tenant isolation design choices you can evidence. Where a third party controls the layer, document compensating controls and shared responsibility assumptions.

Can we document this once and call it done?

No. SC-31(2) expects the maxima to remain reduced in operation, which means configuration management, drift detection, and re-testing after meaningful changes. Keep a standing evidence routine tied to releases and infrastructure changes. (NIST SP 800-53 Rev. 5 OSCAL JSON)

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON