SC-37: Out-of-band Channels

Quick-reference card

What SC-37 requires

SC-37 requires your organization to use communication channels that are physically or logically separate from your primary operational network to deliver sensitive information, system components, or devices. These separate paths, known as out-of-band channels, reduce the chance that an attacker who compromises your production network can also intercept the secondary delivery.

Out-of-band channels can take several forms. They include local, non-network access to systems, network paths that are physically distinct from the paths carrying day-to-day traffic, and non-electronic methods such as postal delivery. The control applies to a range of sensitive materials: authentication credentials, cryptographic key management data, system and data backups, configuration management changes, security updates, maintenance information, and malicious code protection updates. You’d use a separate channel, for example, to deliver encryption keys for files that were transmitted over your standard network.

The requirement sits within the broader System and Communications Protection family of NIST SP 800-53. It isn’t assigned to any baseline, which means organizations adopt it selectively based on risk assessment rather than by default. That selective adoption makes it especially important to document your rationale clearly when you do implement it.

Why SC-37 matters

Most organizations focus their communication security on encrypting traffic within the primary network and overlook the value of maintaining entirely separate delivery paths. That gap creates a single point of failure. If an adversary gains access to the in-band channel, they can intercept both the protected asset and the material needed to access it.

SC-37 addresses this weakness by forcing a deliberate architectural separation between operational traffic and sensitive deliveries. Because the control isn’t part of any baseline, auditors pay close attention to whether organizations that claim to implement it have actually built and documented the supporting processes. A gap between stated and actual practice is exactly the kind of finding that shows up in NIST SP 800-53 audit reports.

Failure to maintain this control introduces audit risk and may result in certification withdrawal or regulatory findings. Organizations pursuing FedRAMP authorization or DoD compliance that reference SC-37 in their system security plan face particular scrutiny because they’ve voluntarily accepted the obligation.

The practical risk extends to third-party relationships as well. If your vendors handle cryptographic material, credentials, or configuration data on your behalf, their channel separation practices directly affect your risk posture. A vendor that delivers encryption keys over the same network as the encrypted payload defeats the purpose of the control entirely.

What attackers exploit

• Compromised network channels where both encrypted data and the corresponding decryption keys travel the same path
• Credential delivery mechanisms that rely solely on email or messaging platforms already under attacker control
• Configuration and patch distribution pipelines that share infrastructure with production traffic
• Backup transmission channels that an attacker can intercept alongside the primary data store
• Key management processes that lack physical or logical separation from routine operations

How to implement SC-37

For your organization

The core challenge with SC-37 is building and sustaining channel separation in environments where consolidating infrastructure onto fewer systems feels more efficient. Convenience pushes organizations toward single-channel delivery, but the control demands deliberate separation.

Identify what requires out-of-band delivery. Start by cataloging the sensitive materials that SC-37 covers. Review your cryptographic key management processes, credential distribution workflows, backup transmission paths, security update pipelines, and configuration change delivery mechanisms. Document each one and note the current delivery channel.

Establish separate delivery paths. For each category, define a channel that doesn’t share infrastructure with your primary operational network. Physical delivery (courier, registered mail) works for cryptographic tokens and hardware security modules. Dedicated management networks, separate from production VLANs, work for configuration pushes and security updates. Out-of-band management interfaces on network devices provide a separate path for maintenance access.

Document the channel inventory. Create and maintain a formal list of your out-of-band channels. For each entry, record the channel type, the information category it carries, the authorized senders and recipients, and the security controls protecting that channel. This inventory becomes a primary evidence artifact during audits.

Integrate with related processes. SC-37 doesn’t operate in isolation. Connect your out-of-band channel procedures to your configuration change control processes, your key management program, and your maintenance procedures. Each of these areas should reference the specific out-of-band channel designated for its sensitive material.

Common mistakes to avoid. Organizations frequently document out-of-band channels in policy but default to in-band delivery in practice, especially under time pressure. Regular process audits and spot checks can catch this drift. Another common mistake is treating a VPN tunnel on the same physical network as a genuine out-of-band channel. The channel must be physically or logically distinct, not just encrypted.

For your vendors

When your vendors handle sensitive materials covered by SC-37, their channel separation practices become your risk. Assessing and monitoring vendor compliance with out-of-band requirements is essential to a complete third-party risk management framework.

Questionnaire questions to include:

• Do you maintain out-of-band channels for delivering cryptographic keys, credentials, or security updates? Describe the channels used.
• How do you ensure that sensitive authentication material is transmitted separately from the systems or data it protects?
• What physical or logical separation exists between your operational network and channels used for sensitive deliveries?
• How often do you audit your out-of-band channel procedures for compliance?
• Can you provide documentation of your out-of-band channel inventory?

Evidence to request:

• The vendor’s system and communications protection policy referencing out-of-band channels
• A documented list of out-of-band channels and their designated use cases
• Procedures for credential and key delivery that specify the separate channel used
• Audit records showing periodic review of channel separation practices
• Physical delivery logs or electronic transmission records for sensitive material

Red flags to watch for:

• Vendors who deliver encryption keys and encrypted data over the same email system or file-sharing platform
• Inability to produce a documented out-of-band channel inventory
• Policies that reference out-of-band delivery but lack implementing procedures
• No evidence of periodic testing or auditing of channel separation

Verification approach. Request a walkthrough of one end-to-end delivery of a sensitive artifact, such as a credential rotation or key exchange. Verify that the delivery path is genuinely separate from the channel carrying the protected material. Cross-reference the vendor’s documentation against their actual practice by reviewing information spillage response procedures and transmission records.

Evidence examples

Cross-framework mapping

No cross-framework mappings are currently configured for SC-37.

Related controls

• AC-02 — Account Management: governs the lifecycle of system accounts, including how credentials for those accounts are delivered through out-of-band channels
• CM-03 — Configuration Change Control: manages the process for approving and implementing configuration changes, which SC-37 requires to be delivered through separate channels
• CM-05 — Access Restrictions for Change: restricts who can make changes to system configurations, complementing SC-37’s requirement for secure delivery of change-related material
• CM-07 — Least Functionality: limits system functions to the minimum necessary, reducing the attack surface that out-of-band channels help protect
• IA-02 — Identification and Authentication (Organizational Users): establishes authentication requirements for users, with SC-37 addressing how authentication material reaches those users securely
• IA-04 — Identifier Management: manages the creation, issuance, and revocation of identifiers, which may require out-of-band delivery to maintain security
• IA-05 — Authenticator Management: covers the lifecycle of authenticators such as passwords and tokens, directly connecting to SC-37’s requirement for separate delivery channels
• MA-04 — Nonlocal Maintenance: addresses maintenance performed remotely, where out-of-band channels provide a secure alternative path for maintenance-related communication
• SC-12 — Cryptographic Key Establishment and Management: governs key generation, distribution, and storage, with SC-37 specifying that key delivery should use channels separate from encrypted data transmission
• SI-03 — Malicious Code Protection: manages malware detection and prevention updates, which SC-37 requires to be delivered through out-of-band channels to prevent tampering

Frequently asked questions

What is NIST SP 800-53 SC-37?

SC-37 is a NIST SP 800-53 control that requires organizations to use communication channels physically or logically separate from their primary network to deliver sensitive information, system components, or devices. These out-of-band channels protect materials such as cryptographic keys, authentication credentials, security updates, and system backups from interception on compromised networks. The control applies at the organizational level and affects both first-party operations and third-party relationships.

What happens if SC-37 is not implemented?

Organizations that reference SC-37 in their system security plan but fail to implement it face audit findings and potential certification complications. Auditors look for documented out-of-band channel inventories, implementing procedures, and delivery records. Without these evidence artifacts, your organization may receive a plan of action and milestones (POA&M) item or, in severe cases, risk authorization withdrawal.

How do you audit SC-37?

Auditing SC-37 starts with reviewing the organization’s out-of-band channel inventory and verifying that each listed channel is physically or logically separate from the operational network. Auditors then examine delivery records, including physical delivery receipts and electronic transmission logs, to confirm that sensitive materials such as credentials and cryptographic keys actually travel through the designated channels. They also compare documented procedures against actual practice, often by requesting a walkthrough of a specific delivery workflow like a credential rotation or key exchange.

What is the difference between in-band and out-of-band channels?

In-band channels are the standard network paths your organization uses for day-to-day operational traffic, such as your corporate network, email systems, and file-sharing platforms. Out-of-band channels are delivery paths that don’t share infrastructure with those operational channels. They include physically separate networks, local non-network access, dedicated management interfaces, and non-electronic methods like postal delivery or courier services. The separation ensures that compromising one channel doesn’t automatically expose material sent through the other.