NIST SP 800-53 SC System and Communications Protection: Key Controls, Enhancements and How to Evidence Them

System and Communications Protection (SC) is the largest technical family in NIST SP 800-53 Rev. 5, and most systems only need a small part of it done well: boundaries, encryption in transit and at rest, keys, certificates and DNS. This guide works through the SC controls that the baselines actually select: what each requires, which organisation-defined parameters you must set, and what evidence an assessor will ask for under SP 800-53A. It also points to the SC controls outside the baselines that are worth tailoring in for cloud and service-to-service architectures. It is written for control owners, network and cloud engineers, system security plan authors and assessors. For the catalogue as a whole, see the NIST SP 800-53 Guide; this page goes one level deeper on SC only.

Key takeaways

• Fifty-one controls, about twenty that matter for most systems. SC runs from SC-1 to SC-51, but only SC-1, SC-5, SC-7, SC-12, SC-13, SC-15, SC-20, SC-21, SC-22 and SC-39 are in the Low baseline. Moderate adds eight more base controls and High adds SC-3 and SC-24.
• SC-7 is where most findings sit. Boundary protection plus the Moderate enhancements (access points, managed interfaces, deny by default, no split tunnelling, authenticated proxies) define how traffic enters and leaves. Each exception needs a business reason and a review date.
• Encryption controls are selections. SC-8, SC-8(1), SC-28 and SC-28(1) at Moderate let you choose confidentiality, integrity or both. Write the choice and the information covered; "everything is encrypted" is not a parameter.
• SC-12 and SC-17 are machine identity controls. Key management requirements and approved trust anchors decide how services, devices and workloads prove who they are. Untracked certificates and keys are a common gap.
• SC-13 depends on validated modules for federal systems. FIPS 140-2 certificates move to the CMVP Historical list on 21 September 2026, so evidence for federal systems should now point to FIPS 140-3 validations where they exist.

The SC controls in the baselines

The table lists the SC controls selected in at least one baseline, taken from NIST's OSCAL Release 5.2.0 catalogue and baseline profiles (L = Low, M = Moderate, H = High). SC-9, SC-14, SC-19 and SC-33 are withdrawn.

For baseline selection and tailoring, see the NIST SP 800-53B Control Baselines and Tailoring Guide.

SC-7: boundary protection

SC-7 requires you to (a) monitor and control communications at external managed interfaces and key internal interfaces, (b) put publicly accessible components in subnetworks physically or logically separated from internal networks, and (c) connect to external networks only through managed interfaces arranged under your security and privacy architecture.

In cloud environments the "managed interface" is often a security group, network policy or private endpoint, and the traffic flow policy is infrastructure as code. SC-7(8) is the awkward one for non-human identities: workloads that call external APIs often bypass the proxy. Either route them through an egress gateway that authenticates the workload or record a dated exception. See the Network Segmentation Guide and Cloud Egress Filtering.

SC-8, SC-13 and SC-28: encryption in transit and at rest

• SC-8 and SC-8(1) (M, H): protect the confidentiality, integrity or both of transmitted information, and use cryptographic mechanisms to prevent unauthorised disclosure or detect changes during transmission. Scope it to internal service-to-service traffic as well as external connections. NIST SP 800-52 Rev. 2 requires government TLS servers and clients to support TLS 1.2 with FIPS-based cipher suites, and TLS 1.3 support from 1 January 2024.
• SC-13 Cryptographic Protection (L, M, H): determine your cryptographic uses and the type of cryptography required for each. A short table in the system security plan, listing each use (transport, storage, signing, token protection) with the algorithm and module, is the strongest evidence. For federal systems, CMVP states that FIPS 140-2 modules move to the Historical list on 21 September 2026 and may then be used only for existing systems. See the FIPS 140-3 and Cryptographic Module Validation Guide.
• SC-28 and SC-28(1) (M, H): protect the confidentiality, integrity or both of the information at rest you define, and use cryptography to prevent unauthorised disclosure and modification on defined components or media. Name the stores: databases, object storage, backups, laptops, removable media. See the Database and Storage Encryption Guide.

SC-12 and SC-17: keys and certificates

SC-12 requires you to establish and manage cryptographic keys in line with key management requirements you define; SC-12(1) at High keeps information available if users lose keys. SC-17 requires certificates to be issued under a certificate policy or obtained from an approved provider, and only approved trust anchors to be in the trust stores you manage.

The settings column is our recommendation, not NIST text. Keys and certificates are the credentials of services, devices and workloads, so SC-12 and SC-17 work with IA-3, IA-5(2) and IA-9 in the IA family. Shorter public TLS certificate lifetimes make automated renewal a practical requirement; see the Certificate Expiry Outages and 47-Day TLS Certificates Guide and the Cryptographic Key Management Guide.

SC-20, SC-21 and SC-22: DNS

• SC-20 (authoritative): return data origin authentication and integrity artefacts with authoritative responses to external queries, and support a chain of trust with child zones. In practice, sign public zones with DNSSEC.
• SC-21 (recursive or caching resolver): request and perform data origin authentication and integrity verification on responses. Turn on DNSSEC validation on resolvers.
• SC-22 (architecture): resolution services are fault tolerant and separate internal and external roles.

All three are in the Low baseline, and all three are often marked "inherited" from a cloud or DNS provider without checking whether signing and validation are switched on. NIST SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide, was finalised on 19 March 2026 and covers DNSSEC, protective DNS and encrypted DNS. See the DNSSEC Deployment Guide.

The rest of the baseline: SC-2 to SC-5, SC-10, SC-15, SC-18, SC-23, SC-24, SC-39

• SC-2 (M, H): separate user functionality from system management functionality, for example administrative interfaces on separate hosts, ports or networks.
• SC-3 (H): isolate security functions from non-security functions.
• SC-4 (M, H): prevent unauthorised and unintended information transfer through shared resources, such as memory or storage reused between tenants.
• SC-5 (L, M, H): protect against or limit the effects of the denial of service events you define, using the controls you name. See the DDoS Protection Guide.
• SC-10 (M, H): terminate network connections at session end or after a period of inactivity you define.
• SC-15 (L, M, H): prohibit remote activation of cameras, microphones and collaboration tools except where you allow it, and show users when they are in use.
• SC-18 (M, H): define acceptable and unacceptable mobile code and authorise, monitor and control its use, such as browser scripting and macros.
• SC-23 (M, H): protect the authenticity of sessions. Session token binding, secure cookie attributes and mutual TLS are typical implementations.
• SC-24 (H): fail to a known state you define while preserving defined state information.
• SC-39 (L, M, H): a separate execution domain for each process, usually inherited from the operating system.

Tailoring candidates outside the baselines

Several SC controls are not in any baseline but fit modern architectures. SC-45 System Time Synchronization supports AU-8 time stamps. SC-7(10) Prevent Exfiltration and SC-7(11) Restrict Incoming Communications Traffic suit sensitive data systems. SC-8(3) protects message externals. SC-23(1) invalidates session identifiers at logout, and SC-23(5) restricts allowed certificate authorities. SC-49 and SC-50 cover hardware and software-enforced separation and policy enforcement. Record why you add or skip each one.

How to evidence SC controls

For assessment depth, see the NIST SP 800-53A Guide.

Implementing the SC family: a phased approach

This sequence is NHI Mgmt Group's recommendation for a Moderate system.

1. Draw the boundary. Update the architecture diagram with every managed interface, access point and external service.
2. Write the parameters. SC-7(4) review frequency, SC-7(7) safeguards, SC-8 and SC-28 selections and information, SC-10 inactivity period, SC-12 requirements, SC-13 uses.
3. Move to deny by default in stages. Log-only or monitor rules first, review the hits, then enforce per segment, with the previous rule set kept for rollback.
4. Inventory keys and certificates. Discover, assign owners and automate renewal before enforcing new trust store baselines.
5. Close transit and rest gaps. Internal service traffic and backups are the usual leftovers.
6. Turn on DNSSEC validation and signing. Validate on resolvers first, then sign public zones.
7. Collect evidence continuously. Export rule sets, TLS scan results and certificate inventories on a schedule. See the Audit Evidence and Continuous Controls Monitoring Guide.

Decision guidance

• Low versus Moderate: Low covers boundaries, denial of service, keys, cryptography, DNS and process isolation. Moderate adds the SC-7 enhancements, encryption in transit and at rest, PKI, session authenticity and network disconnect.
• Perimeter or zero trust: SC-7 does not require a single perimeter. Per-workload boundaries with identity-aware policy can meet SC-7 and SC-7(21) if each managed interface and its policy are documented.
• Provider or customer keys: provider-managed keys usually meet SC-28(1); customer-managed keys give you more control over SC-12 at the cost of operating them. Record the choice per data store.

Detection and measurement

• Number of SC-7(4) exceptions past their review date.
• Share of internal and external endpoints passing a TLS configuration scan.
• Certificates without an owner, and certificates expiring within 30 days without renewal scheduled.
• Share of data stores and backups with encryption at rest confirmed against the SC-28 list.
• Workloads with direct internet egress outside the SC-7(8) proxy path.

Framework mapping

Mappings are "intersects with", not equivalence, and are our reading of the texts. Check them against NIST's published informative references before using them in an audit. See the Control Mapping Guide.

Common failure patterns

• Exceptions without end dates: SC-7(4) requires a business need and duration for each exception, but registers often have neither.
• Encryption scoped to the edge: TLS at the load balancer, plain text behind it.
• Keys and certificates with no owner: nobody can say which service a certificate belongs to until it expires and causes an outage.
• Cryptographic use table missing: SC-13 marked implemented with no list of uses and modules.
• DNS controls assumed: SC-20 and SC-21 marked inherited while validation is switched off.
• Workload egress outside the proxy: SC-7(8) met for users and ignored for services.

Practitioner checklist

• Keep an architecture diagram with every managed interface and access point.
• Run an exception register with business need, duration and review date.
• Enforce deny by default at managed interfaces, staged through monitor mode.
• Write SC-8 and SC-28 selections and the information each covers.
• Maintain an SC-13 cryptographic use table with module references.
• Inventory keys and certificates with owners and automated renewal.
• Turn on DNSSEC validation and sign public zones.
• Route workload egress through an authenticated path or record exceptions.

Standards and references

• NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
• NIST: OSCAL content, SP 800-53 Release 5.2.0 catalogue and baseline profiles
• NIST: SP 800-52 Rev. 2, Guidelines for the Selection, Configuration, and Use of TLS Implementations
• NIST: SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• NIST: SP 800-81 Rev. 3, Secure Domain Name System (DNS) Deployment Guide
• NIST: Cryptographic Module Validation Program
• NIST: SP 800-171 Rev. 3
• CIS: Controls Assessment Specification, Control 12 Network Infrastructure Management

Related NHI Mgmt Group resources: NIST SP 800-53 Guide · Encryption Guide · mTLS Guide · NIST SP 800-53 IA Identification and Authentication