SC-37 Out-of-band Channels asks you to use a separate channel to deliver or transmit chosen items to chosen recipients. The guidance describes local non network access, physically separate network paths, or non electronic paths such as postal mail. Because the channel differs from normal traffic, a compromise of the normal channel does not compromise it.
NIST SP 800-53 binds US federal systems, and reaches contractors and cloud providers through contract terms such as FedRAMP. For everyone else it is a reference catalog.
What it means in practice
Think of the items that would be dangerous if intercepted: initial credentials, recovery codes, encryption keys, hardware tokens. You send the account in one channel and the secret in another. SC-37.1, Ensure Delivery and Transmission, adds that you verify the right party actually received it.
Out of band does not have to mean expensive. A short phone call to a number you already have on file is a legitimate second channel for confirming a one time code. A hardware token delivered by courier is another. The test is whether an attacker who owns the first channel, say a mailbox, still cannot get the secret.
The guidance notes the contrast with in band channels, which carry routine operational traffic. Out of band paths do not share their exposure, so a compromise of one does not spread to the other.
Evidence to collect
- The list of items and recipients that use an out of band path.
- Procedure for each, such as a call back to a known number.
- Logs or receipts showing delivery was confirmed.
Common gaps
The "second channel" is the same email thread. Or recovery codes get sent in a chat message beside the username.
How to implement it
Write down the three most sensitive handoffs you do. Move the secret half to a different channel, and require the receiver to confirm.
Quick check
Is a second email an out of band channel?
Not really. It shares exposure with the first one. Use a phone call, a hardware token or a separate system.
