System and Communications Protection Policy

Approval #

Revision History #

Review cycle: Every year, under the Policy and Procedure Management Policy.

1. Purpose and Scope #

In this policy, the CISO sets the Organization’s requirements for system and communications protection in every information system that the Organization operates or that others operate for it. The CISO issues the policy under these authorities:

• The Federal Information Security Modernization Act (FISMA) of 2014.
• National Institute of Standards and Technology (NIST) Special Publication 800-53 Revision 5.
• Office of Management and Budget (OMB) Circular A-130, Managing Information as a Strategic Resource.
• The OMB memoranda and Executive Orders that apply.

The Organization also uses this policy to carry out the NIST Cybersecurity Framework (CSF) 2.0, which Executive Order 13800 and OMB Circular A-130 require.

1.1 Program Objectives #

This policy covers system and communications protection. The Organization relies on its network architecture to protect systems, because it cannot trust the network itself. The Organization must implement defense in depth and zero trust segmentation. It must manage boundary protection that denies traffic by default and use Federal Information Processing Standards (FIPS) 140-3 validated cryptography for data in transit. It must also keep Domain Name System (DNS) integrity under Binding Operational Directive (BOD) 18-01 and separate user and management functions. It must design systems to withstand denial-of-service attacks. It must isolate High Value Assets behind tiered boundary protections under the Cybersecurity and Infrastructure Security Agency (CISA) High Value Asset (HVA) overlay.

This policy applies to everyone in the program: executives who accept risk, System Owners who fund the controls, security officers who run them, and every user. By following it, the Organization meets its FISMA obligations for this control family and shows its maturity in the annual Inspector General (IG) FISMA evaluation. The Organization’s target is Level 4 (Managed and Measurable). The CISO tracks progress with the performance measures and the improvement commitments later in this policy.

1.2 CSF 2.0 Alignment #

The controls in this policy support these CSF 2.0 categories:

• PR.DS — Data Security (Protect function)
• PR.PS — Platform Security (Protect function)
• PR.IR — Technology Infrastructure Resilience (Protect function)

These categories fall under the Protect function(s) of CSF 2.0. The Organization’s CSF 2.0 Profile maps each category to the NIST SP 800-53 controls in this policy.

This policy covers every system and communications protection control in the high baseline of FIPS 200 and NIST SP 800-53B:

• SC-01 — Policy and Procedures
• SC-02 — Separation of System and User Functionality
• SC-03 — Security Function Isolation
• SC-04 — Information in Shared System Resources
• SC-05 — Denial-of-service Protection
• SC-07 — Boundary Protection
• SC-07(10) — Prevent Exfiltration
• SC-07(12) — Host-based Protection
• SC-07(18) — Fail Secure
• SC-07(20) — Dynamic Isolation and Segregation
• SC-07(21) — Isolation of System Components
• SC-07(24) — Personally Identifiable Information
• SC-07(3) — Access Points
• SC-07(4) — External Telecommunications Services
• SC-07(5) — Deny by Default — Allow by Exception
• SC-07(7) — Split Tunneling for Remote Devices
• SC-07(8) — Route Traffic to Authenticated Proxy Servers
• SC-08 — Transmission Confidentiality and Integrity
• SC-08(1) — Cryptographic Protection
• SC-10 — Network Disconnect
• SC-12 — Cryptographic Key Establishment and Management
• SC-12(1) — Availability
• SC-13 — Cryptographic Protection
• SC-15 — Collaborative Computing Devices and Applications
• SC-17 — Public Key Infrastructure Certificates
• SC-18 — Mobile Code
• SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
• SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver)
• SC-22 — Architecture and Provisioning for Name/Address Resolution Service
• SC-23 — Session Authenticity
• SC-24 — Fail in Known State
• SC-28 — Protection of Information at Rest
• SC-28(1) — Cryptographic Protection
• SC-39 — Process Isolation
• SC-45 — System Time Synchronization
• SC-45(1) — Synchronization with Authoritative Time Source

2. Authority and References #

The CISO issues this policy under the authority of:

• FISMA 2014 (44 U.S.C. § 3551 et seq.) — Statutory mandate for federal information security programs
• NIST SP 800-53 Rev 5 — Security and Privacy Controls for Information Systems and Organizations
• OMB Circular A-130 — Managing Information as a Strategic Resource
• OMB Circular A-123 — Management’s Responsibility for Internal Control (revised March 10, 2026)
• NIST CSF 2.0 — Cybersecurity Framework (mandated by EO 13800 and OMB Circular A-130)
• EO 13800 — Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the SC control family. They add to the NIST SP 800-53 control requirements in the Policy section.

OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles

• The organization must encrypt all data in transit and at rest using FIPS-validated cryptographic modules. DNS traffic must be encrypted (DoH or DoT) and all internal network traffic must be authenticated and encrypted. Deadline: FY 2024. (OMB M-22-09, §3(c)(i))
• The organization must segment networks by application and environment instead of relying on a flat network, with access controls and monitoring enforced in each segment. Deadline: FY 2024. (OMB M-22-09, §3(c)(ii))

NIST SP 800-207: Zero Trust Architecture

• The organization must encrypt all communication between resources end to end, even on internal networks presumed trusted, so that its security does not depend on network location. (NIST SP 800-207, §3.3)

CISA BOD 23-02: Mitigating the Risk of Internet-Exposed Management Interfaces

• The organization must implement network segmentation to isolate management interfaces from production traffic. Management plane access must be separated from data plane access. (CISA BOD 23-02, §2)

OMB M-23-02: Migrating to Post-Quantum Cryptography

• The organization must plan for migration to quantum-resistant cryptography, with the goal of mitigating quantum risk by 2035. The inventory must include cryptographic algorithm types, data lifecycle characteristics, and system ownership. Deadline: 2035. (OMB M-23-02, §II.B)

OMB M-19-03: Strengthening Cybersecurity through the High Value Asset Program

• The organization must isolate and segment High Value Assets from broader agency networks using boundary protections and architecture reviews so that compromise of general-purpose environments does not directly expose HVAs. (OMB M-19-03, §B)

CISA High Value Asset (HVA) Control Overlay v1.0

• The organization must protect HVA authorization boundaries with boundary protection devices (gateways, routers, guards, encrypted tunnels, firewalls, application proxies) at the boundary and at tiered points within it, per the overlay’s SC-7 selection rationale. (CISA HVA Control Overlay v1.0, SC-7)

OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography

• The organization must execute a prioritized migration of cryptographic systems in every information system the organization owns or operates, with the objective of mitigating as much quantum risk as feasible by December 31, 2030. Prioritize high-impact systems, High Value Assets, and any other system holding highly sensitive data or judged particularly vulnerable to attack by a cryptanalytically relevant quantum computer. Deadline: 2030-12-31. (OMB M-26-15, Action One)
• The organization must support TLS 1.3 with post-quantum or hybrid key exchange, adopt crypto-agility (algorithm choices in external configuration rather than compiled in; agile key management infrastructure), fold PQC upgrades into planned cloud migrations, development lifecycles, and hardware refreshes, and identify systems that cannot support PQC or hybrid cryptography for priority replacement or decommissioning. (OMB M-26-15, Action One and Appendix)

Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks

• The organization must review the inventory of High Value Assets and high-impact systems, then move every one of them to PQC for key establishment by December 31, 2030, and to PQC for digital signatures by December 31, 2031. Deadline: 2030-12-31 (key establishment); 2031-12-31 (digital signatures). (EO 14412, §4(b)(i)-(iii); OMB M-26-15)

OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services

• The organization must serve every publicly accessible website and web service only over a secure HTTPS connection, with HTTP Strict Transport Security (HSTS) enabled. Deadline: 2016-12-31. (OMB M-15-13)

OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative

• The organization must keep an accurate inventory of network connections, keep network and system boundary policies current with Trusted Internet Connections (TIC) 3.0, and name the TIC use cases the Organization allows. (OMB M-19-26)

CISA BOD 18-01: Enhance Email and Web Security

• The organization must serve all public websites and web services over HTTPS only with HTTP Strict Transport Security (HSTS), and identify domains that can be HSTS preloaded. (CISA BOD 18-01, Required Actions)
• The organization must disable SSLv2 and SSLv3, and the 3DES and RC4 ciphers, on all internet-facing web and mail servers. (CISA BOD 18-01, Required Actions)
• The organization must configure all internet-facing mail servers to offer STARTTLS. (CISA BOD 18-01, Required Actions)
• The organization must publish valid Sender Policy Framework (SPF) and DMARC records for every second-level domain, with CISA’s address among the DMARC aggregate report recipients. (CISA BOD 18-01, Required Actions)
• The organization must set a DMARC policy of reject (p=reject) for all second-level domains and mail-sending hosts. (CISA BOD 18-01, Required Actions)

NIST CMVP: FIPS 140-3 Transition Effort

• The organization must buy only cryptographic modules that hold an active FIPS 140-3 validation, because FIPS 140-2 certificates moved to the CMVP Historical list in September 2026. Deadline: September 2026. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition; 40 U.S.C. § 11331)
• The organization must track each system that still uses a FIPS 140-2 module after September 2026 as a plan of action and milestones item until the module is replaced. (FIPS 140-3; NIST CMVP FIPS 140-3 Transition)

OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6)

• The organization must keep an IPv6 implementation plan that moves at least 80 percent of IP-enabled assets on federal networks to IPv6-only. Deadline: End of FY 2025 (80 percent IPv6-only). (OMB M-21-07)
• The organization must list each system that cannot move to IPv6-only, with a schedule to replace or retire it. (OMB M-21-07)
• The organization must enable IPv6 on every new networked federal information system when it is deployed. Deadline: Starting in FY 2023. (OMB M-21-07)
• The organization must make sure every system that supports network operations or enterprise security, such as firewalls, intrusion detection, and logging, can operate in an IPv6-only environment. (OMB M-21-07)

NIST SP 800-52 Rev 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations

• The organization should configure servers for government-only applications to use TLS 1.2 or later, and never to use TLS 1.0, SSL 3.0, or SSL 2.0. (NIST SP 800-52 Rev 2, §3.1)
• The organization should support TLS 1.3 on servers and clients that use TLS. Deadline: January 1, 2024. (NIST SP 800-52 Rev 2, §3.1)

NIST SP 800-57 Part 1 Rev 5: Recommendation for Key Management: Part 1 - General

• The organization should document key management for each system, including a cryptoperiod for each key type and how keys are generated, distributed, stored, backed up, archived, and destroyed. (NIST SP 800-57 Part 1 Rev 5, §§5-8)
• The organization should keep a key compromise recovery plan that covers revoking and replacing affected keys and notifying the parties that rely on them. (NIST SP 800-57 Part 1 Rev 5, §6)

NIST SP 800-119: Guidelines for the Secure Deployment of IPv6

• The organization should detect and examine IPv6 traffic on every network, including networks meant to carry only IPv4, so that no device uses IPv6 unseen. (NIST SP 800-119)

3. Policy #

The Organization must implement and maintain its system and communications protection controls to meet the following requirements:

SC-01 — Policy and Procedures #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security)

Requirement:

1. Develop, document, and disseminate to [Assignment: organization-defined personnel or roles — to be defined]:

1. [Selection (one or more): organization-level; mission/business-process-level; system-level — to be defined] system and communications protection policy that:

1. Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and
2. Is consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines; and

2. Procedures to facilitate the implementation of the system and communications protection policy and the associated system and communications protection controls;

2. Designate an [Assignment: organization-defined official — to be defined] to manage the development, documentation, and dissemination of the system and communications protection policy and procedures; and
3. Review and update the current system and communications protection:

1. Policy at least annually and following significant changes; and
2. Procedures at least annually and following [Assignment: organization-defined events — to be defined].

Implementation guidance:

The Organization must keep a system and communications protection policy at the organization level and at the system level, with procedures that put each requirement into practice. The CISO must manage the development, documentation, and distribution of both documents. The CISO delivers them to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and key stakeholders when they are issued and after every revision. The policy and the procedures must stay consistent with the laws, executive orders, directives, and standards that apply to the Organization. That includes the encryption and segmentation requirements in OMB M-22-09 that shape this control family. The CISO must review and update the policy and the procedures every year. The CISO must also review them sooner whenever the components or technologies that carry communications functions change. A policy that no longer matches the architecture will produce an assessment finding.

SC-02 — Separation of System and User Functionality #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Separate user functionality, including user interface services, from system management functionality.

Implementation guidance:

System Owners must separate user functions, including user-facing interfaces, from the functions that administer the system. System Owners must keep administrative interfaces off the network paths that serve end users. Management plane access must stay separate from data plane access, as CISA BOD 23-02 directs. In the cloud platform, System Owners must place administrative interfaces in their own network segments. Administrators reach those segments only through the zero trust network access (ZTNA) service access policies limited to the administrator group, and never from public endpoints. The ISSO must verify the separation whenever a system’s architecture changes. A design that mixes administrative and user traffic on one path requires a documented risk decision before the system enters service.

SC-03 — Security Function Isolation #

Baselines: High

Requirement:

Isolate security functions from nonsecurity functions.

Implementation guidance:

System Owners must keep security functions separate from functions that do not enforce security. Security functions include access control, audit logging, cryptographic key handling, and security monitoring. These functions must run in separate processes, accounts, or environments that general application code cannot change. Only privileged administrators must be able to change security function settings or code. In the cloud platform, management interfaces must stay separate from production traffic, as CISA BOD 23-02 directs. Where a product cannot separate a security function, the System Owner must document the gap and the compensating safeguards in the system security and privacy plan. The Chief Information Security Officer (CISO) must approve each documented gap.

SC-04 — Information in Shared System Resources #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Prevent unauthorized and unintended information transfer via shared system resources.

Implementation guidance:

System Owners must make sure that memory, storage, and other resources returned to a shared environment expose nothing of their prior contents to the next user, including encrypted remnants. For workloads in the cloud platform, the platform provides the hypervisor and storage isolation that enforces this requirement, and the Organization inherits it under the platform’s Federal Risk and Authorization Management Program (FedRAMP) authorization. System Owners must document that inheritance in the system’s control records. Application teams must not place sensitive information in shared temporary space that outlives the session that wrote it. The ISSO must review any design that uses shared caches, queues, or scratch storage before the service enters operation.

SC-05 — Denial-of-service Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security), PR.IR (Technology Infrastructure Resilience)

Requirement:

1. Protect against the effects of the following types of denial-of-service events: at a minimum: ICMP (ping) flood, SYN flood, slowloris, buffer overflow attack, and volume attack; and
2. Employ the following controls to achieve the denial-of-service objective: [Assignment: organization-defined controls by type of denial-of-service event — to be defined].

Implementation guidance:

The Organization must protect its systems against denial-of-service attacks. At a minimum, the protections must cover SYN floods, Internet Control Message Protocol (ICMP) and ping floods, teardrop and ping-of-death malformed-packet attacks, peer-to-peer abuse, application-level floods, and distributed attacks. The safeguards must follow SANS denial-of-service guidance or an alternative that the CISO approves. System Owners must host public-facing services on the cloud platform infrastructure with the capacity and layout to absorb traffic surges. System Owners must keep internal applications unreachable from the open internet by publishing them only through the ZTNA service. Anyone who suspects a denial-of-service attack must report it to the ISSO immediately, and the ISSO must handle it as a security incident.

SC-07 — Boundary Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Monitor and control communications at the external managed interfaces to the system and at key internal managed interfaces within the system;
2. Implement subnetworks for publicly accessible system components that are [Selection: physically; logically — to be defined] separated from internal organizational networks; and
3. Connect to external networks or systems only through managed interfaces consisting of boundary protection devices arranged in accordance with an organizational security and privacy architecture.

Implementation guidance:

The Organization must monitor and control traffic at every external interface and at key internal interfaces. The Organization must place publicly accessible components in subnetworks kept physically or logically apart from internal networks. Systems must connect to outside networks only through managed interfaces that fit the approved security architecture. The network engineering team must map each external connection to a Trusted Internet Connections (TIC) 3.0 use case the CISO approves under OMB M-19-26. Under OMB M-19-03 and the CISA HVA overlay, High Value Assets must sit behind boundary protections at the perimeter and at tiered points inside it. In the cloud platform, System Owners must segment networks by application and by environment. Outbound web traffic must leave only through the secure web gateway. The CISO must approve a new external connection before it carries traffic. Before a rule opens a system to the internet, the security operations team must scan it and confirm that no critical finding and no past-due high finding remain. The perimeter must not allow cleartext administrative or file-transfer protocols, such as Telnet and File Transfer Protocol. The CISO tracks the milestones for isolated network environments and encrypted DNS in the Zero Trust and identity, credential, and access management (ICAM) Implementation Plan (PLAN-ZT-001).

SC-07(3) — Access Points #

Baselines: Moderate / High

Requirement:

Limit the number of external network connections to the system.

Implementation guidance:

System Owners must keep external network connections to the minimum the mission requires. System Owners must route general internet access through the managed secure web gateway path instead of through system-specific links. A new external connection requires a written justification and CISO approval before it is activated. When a connection no longer serves a documented need, the System Owner must remove it. Leaving the connection idle is not enough.

SC-07(4) — External Telecommunications Services #

Baselines: Moderate / High

Requirement:

1. Implement a managed interface for each external telecommunication service;
2. Establish a traffic flow policy for each managed interface;
3. Protect the confidentiality and integrity of the information being transmitted across each interface;
4. Document each exception to the traffic flow policy with a supporting mission or business need and duration of that need;
5. Review exceptions to the traffic flow policy at least every ninety (90) days or whenever there is a change in the threat environment that warrants a review of the exceptions and remove exceptions that are no longer supported by an explicit mission or business need;
6. Prevent unauthorized exchange of control plane traffic with external networks;
7. Publish information to enable remote networks to detect unauthorized control plane traffic from internal networks; and
8. Filter unauthorized control plane traffic from external networks.

Implementation guidance:

External telecommunications services must enter the environment only through managed interfaces. The network engineering team must keep a documented traffic flow policy for each managed interface and must protect the confidentiality and integrity of the traffic that crosses it. Anyone who requests an exception to a flow policy must record the mission need behind it and how long that need lasts. The ISSO must review the exception register at least quarterly and after any significant change, and must remove each exception that no longer has an explicit need. The Organization must also block unauthorized routing and network management exchanges with external networks. The Organization must publish the information that remote networks need to detect unauthorized routing traffic from inside the Organization, and must filter such traffic that arrives from outside.

SC-07(5) — Deny by Default — Allow by Exception #

Baselines: Moderate / High

Requirement:

Deny network communications traffic by default and allow network communications traffic by exception any systems.

Implementation guidance:

At managed interfaces, the Organization must deny network traffic by default and allow it only by documented exception. This rule applies to every system that faces or connects to an external network, including demilitarized zone (DMZ) systems, High Value Assets, and mission-essential services. Every allow rule must trace to an approved request with a named owner. System Owners must make sure that rule sets in the cloud platform and the secure web gateway start from deny-all. The ISSO must treat any default-permit configuration as a finding, and the System Owner must correct it.

SC-07(7) — Split Tunneling for Remote Devices #

Baselines: Moderate / High

Requirement:

Prevent split tunneling for remote devices connecting to organizational systems unless the split tunnel is securely provisioned using [Assignment: organization-defined safeguards — to be defined].

Implementation guidance:

A remote device that connects to Organization systems must not split-tunnel. All of its traffic must go through the managed ZTNA path. The only permitted exception is a securely provisioned configuration on a managed device that runs current endpoint protection. That configuration locks the tunnel to approved destinations and gives the user no control over the setting. System Owners must make sure that remote access configurations enforce this rule. Users must not change tunnel settings.

SC-07(8) — Route Traffic to Authenticated Proxy Servers #

Baselines: Moderate / High

Requirement:

Route [Assignment: organization-defined internal communications traffic — to be defined] to any network outside of organizational control and any network outside the authorization boundary through authenticated proxy servers at managed interfaces.

Implementation guidance:

All traffic toward external networks must pass through authenticated proxy servers at managed interfaces. Users and workloads authenticate to the secure web gateway, and the secure web gateway brokers, inspects, and logs every outbound web request. System Owners must block any egress path that bypasses the proxy. An exception requires CISO approval and a documented need. If anyone finds unauthenticated outbound traffic outside the proxy path, the ISSO must investigate it as a possible compromise.

SC-07(10) — Prevent Exfiltration #

Baselines: High

Requirement:

1. Prevent the exfiltration of information; and
2. Conduct exfiltration tests [Assignment: organization-defined frequency — to be defined].

Implementation guidance:

System Owners must block unauthorized transfer of information out of their systems. The secure web gateway must inspect all outbound web traffic and block transfers to destinations the Organization has not approved. Systems must not open external network connections unless the system’s documented function needs them. The Information System Security Officer (ISSO) must run exfiltration tests [SC-07(10) parameter 1 — to be defined] to confirm that these protections work. The Chief Information Security Officer (CISO) must review test results and track each failed test until the System Owner fixes it.

SC-07(12) — Host-based Protection #

Baselines: Moderate / High

Requirement:

Implement Host Intrusion Prevention System (HIPS), Host Intrusion Detection System (HIDS), or minimally a host-based firewall at [Assignment: organization-defined system components — to be defined].

Implementation guidance:

The Organization must run host-based firewalls and other host-level boundary protection on the system components it designates. Administrators must configure each host firewall to admit only the traffic that the component’s function requires. System Owners must define the set of protected components and must keep the host firewall settings in the approved baseline. Administrators must not disable a host firewall outside an approved change. Any deviation from the baseline requires a documented risk decision.

SC-07(18) — Fail Secure #

Baselines: Moderate / High

Requirement:

Prevent systems from entering unsecure states in the event of an operational failure of a boundary protection device.

Implementation guidance:

Boundary protection must fail secure. When a managed interface or its enforcement component stops working, traffic must stop with it instead of flowing uninspected. System Owners must configure boundary devices and access paths so that a failure denies communication. System Owners must treat any fail-open condition as a security incident. During restoration, administrators must restore enforcement before they restore traffic flow.

SC-07(20) — Dynamic Isolation and Segregation #

Baselines: High

Requirement:

Provide the capability to dynamically isolate [Assignment: organization-defined system components — to be defined] from other system components.

Implementation guidance:

System Owners must be able to cut off [SC-07(20) parameter 1 — to be defined] from other system components on short notice when a component is suspect or compromised. Isolation must not require rebuilding the network or physically moving the component. The System Owner must document the isolation method for each listed component in the system security and privacy plan. The Information System Security Officer (ISSO) must test each isolation method before production use and after significant changes. The Chief Information Security Officer (CISO) must direct isolation when there is doubt about a component’s trust.

SC-07(21) — Isolation of System Components #

Baselines: High

Requirement:

Employ boundary protection mechanisms to isolate [Assignment: organization-defined system components — to be defined] supporting [Assignment: organization-defined missions and/or business functions — to be defined].

Implementation guidance:

System Owners must use boundary protection to separate [SC-07(21) parameter 1 — to be defined] that support [SC-07(21) parameter 2 — to be defined]. Each separated group must sit in its own network segment with its own access rules and monitoring, as OMB M-22-09 requires. The System Owner must route traffic between segments only through approved paths and must encrypt it. High Value Assets must stay separate from the broader network, per OMB M-19-03. The Information System Security Officer (ISSO) must review segment rules after each significant change.

SC-07(24) — Personally Identifiable Information #

Baselines: Privacy

Requirement:

For systems that process personally identifiable information: (a) Apply the following processing rules to data elements of personally identifiable information: [Assignment: organization-defined processing rules — to be defined]; (b) Monitor for permitted processing at the external interfaces to the system and at key internal boundaries within the system; (c) Document each processing exception; and (d) Review and remove exceptions that are no longer supported.

Implementation guidance:

For each system that processes personally identifiable information (PII), the System Owner must enforce [SC-07(24) parameter 1 — to be defined] on PII data elements. The ISSO must monitor PII traffic at the system’s external interfaces and at the main internal boundaries between network segments. OMB M-22-09 requires each segment to enforce its own access controls and monitoring. The System Owner must document each exception to the processing rules, with its reason and the Privacy Officer’s approval. The System Owner must remove any exception that is no longer justified.

SC-08 — Transmission Confidentiality and Integrity #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security)

Requirement:

Protect the confidentiality AND integrity of transmitted information.

Implementation guidance:

The Organization must protect the confidentiality and integrity of all transmitted information, on internal paths as well as external ones. Under OMB M-22-09, systems must encrypt traffic with FIPS-validated cryptographic modules and must encrypt DNS queries. System Owners must configure every Transport Layer Security (TLS) server to NIST SP 800-52 Rev 2, with TLS 1.2 at minimum and no Secure Sockets Layer (SSL), Rivest Cipher 4 (RC4), or 3DES. Every public website and web service must use Hypertext Transfer Protocol Secure (HTTPS) only and send the Strict Transport Security (HSTS) header, as OMB M-15-13 and CISA BOD 18-01 require. User traffic to applications must use ZTNA tunnels. Staff must send sensitive PII or Controlled Unclassified Information outside the Organization only through channels the CISO approves. The Security Operations Center must run data loss prevention on outbound email and web traffic. If a legacy interface cannot yet comply, the System Owner must document the exposure, apply compensating protections, and set a remediation date that the CISO accepts.

SC-08(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Requirement:

Implement cryptographic mechanisms to prevent unauthorized disclosure of information AND detect changes to information during transmission.

Implementation guidance:

The Organization must use cryptographic mechanisms on every transmission path to prevent unauthorized disclosure and to detect any change to information in transit. The modules must be FIPS-validated, as OMB M-22-09 requires. System Owners must make sure that sessions negotiate approved algorithms with integrity protection and must prohibit fallback to unprotected transport. A path that cannot support validated cryptography requires a documented exception that the CISO accepts.

SC-10 — Network Disconnect #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Terminate the network connection associated with a communications session at the end of the session or after no longer than ten (10) minutes for privileged sessions and no longer than fifteen (15) minutes for user sessions of inactivity.

Implementation guidance:

Systems must end the network connection for a communications session when the session ends. Remote access sessions carried over zero trust network access must disconnect after 10 minutes of inactivity. System Owners must apply the timeout in the access policy, not in settings a user can adjust. Administrators must not extend the timeout without a documented and approved exception. A user who needs to resume work must authenticate again. The convenience of a longer session does not outweigh the exposure of an abandoned connection.

SC-12 — Cryptographic Key Establishment and Management #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: In accordance with Federal requirements.

Implementation guidance:

The Organization must manage cryptographic keys under NIST SP 800-57 Part 1. The CISO must set a cryptoperiod for each key type using that guideline, and administrators must replace each key before its cryptoperiod ends. Each key must have a named owner. Administrators must protect secret and private keys inside the cryptographic module against unauthorized disclosure, modification, and substitution. They must protect public keys against unauthorized modification and substitution. Administrators must store keys apart from the data they protect. They must back up keys needed to recover encrypted data, but not private signing keys. System Owners must generate and hold keys for cloud workloads in FIPS-validated modules within the cloud platform. Anyone who suspects a key compromise must report it as a security incident. Under OMB M-23-02, the ISSO must keep an inventory of cryptographic systems for the move to quantum-resistant cryptography.

SC-12(1) — Availability #

Baselines: High

Requirement:

Maintain availability of information in the event of the loss of cryptographic keys by users.

Implementation guidance:

System Owners must make sure that information stays available when a user loses a cryptographic key or forgets a passphrase. Keys that protect Organization information must be held in escrow or backed up under Organization control before use. Only the System Owner, or a person the System Owner authorizes, may recover a key. Recovery must happen only after the Information System Security Officer (ISSO) verifies the requester’s identity and need. The ISSO must test key recovery for each system that encrypts stored information.

SC-13 — Cryptographic Protection #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Determine the [Assignment: organization-defined cryptographic uses — to be defined]; and
2. Implement the following types of cryptography required for each specified cryptographic use: FIPS-validated or NSA-approved cryptography.

Implementation guidance:

Wherever cryptography protects Organization information, the Organization must use validated modules. New purchases and deployments must use modules with an active FIPS 140-3 validation under the Cryptographic Module Validation Program. A module whose FIPS 140-2 validation has moved to the program’s Historical list may stay in service only under a plan of action and milestones (POA&M) item with a replacement date. The Authorizing Official must accept that risk. The defined uses of cryptography include protecting sensitive data on mobile devices and protecting stored passwords. They also include securing connections to the Organization’s public web services. System Owners must identify each place where their system uses cryptography. They must record the module and its validation, and replace any unvalidated implementation. The CISO must approve a deviation only when it has compensating protections and a remediation date.

SC-15 — Collaborative Computing Devices and Applications #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Prohibit remote activation of collaborative computing devices and applications with the following exceptions: no exceptions for computing devices; and
2. Provide an explicit indication of use to users physically present at the devices.

Implementation guidance:

No one may activate a collaborative computing device or application remotely unless the Chief Information Officer (CIO) or a designated representative authorizes it in writing. The authorization must name the permitted mechanism, its purpose, and the specific system on which it may operate. Collaborative devices and applications must give the people physically present a clear signal when they are active, so that no one is recorded without knowing it. System Owners must configure conferencing and collaboration equipment to these settings. The ISSO must verify the settings when equipment is installed or changed.

SC-17 — Public Key Infrastructure Certificates #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Issue public key certificates under an [Assignment: organization-defined certificate policy — to be defined] or obtain public key certificates from an approved service provider; and
2. Include only approved trust anchors in trust stores or certificate stores managed by the organization.

Implementation guidance:

The Organization must obtain public key certificates from the General Services Administration (GSA) or from third-party providers the CIO approves. These certificates support the Organization’s websites and digital signatures. A self-issued certificate must not serve a public service. Trust stores and certificate stores that the Organization manages must contain only approved trust anchors, and any addition requires documented approval. System Owners must track certificate expiration dates so that a production service never runs on an expired certificate. The ISSO must review trust store contents and remove any anchor that does not belong.

SC-18 — Mobile Code #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Define acceptable and unacceptable mobile code and mobile code technologies; and
2. Authorize, monitor, and control the use of mobile code within the system.

Implementation guidance:

The Organization must define which mobile code and mobile code technologies are acceptable and which are not. The Organization must authorize, monitor, and control the mobile code that runs within its systems. System Owners must permit only the approved technologies. The secure web gateway filtering must block content in the barred categories at the web boundary. A request to use a technology outside the approved set requires CISO approval, with the justification recorded. The ISSO must watch for unauthorized mobile code in use and must open a remediation ticket for each instance.

SC-20 — Secure Name/Address Resolution Service (Authoritative Source) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

1. Provide additional data origin authentication and integrity verification artifacts along with the authoritative name resolution data the system returns in response to external name/address resolution queries; and
2. Provide the means to indicate the security status of child zones and (if the child supports secure resolution services) to enable verification of a chain of trust among parent and child domains, when operating as part of a distributed, hierarchical namespace.

Implementation guidance:

The Organization’s authoritative name service must attach origin authentication and integrity verification data to every answer it returns to an external query. DNS administrators must sign the public zones so that resolvers can validate what they receive. DNS administrators must publish the delegation records that let parent and child domains form a chain of trust that resolvers can verify. System Owners for the public zones hosted in the cloud platform must keep the zones signed and must manage signing keys under change control. DNS administrators must handle a lapsed or broken signature as an operational incident, not as routine maintenance.

SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver) #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Request and perform data origin authentication and data integrity verification on the name/address resolution responses the system receives from authoritative sources.

Implementation guidance:

Recursive and caching resolvers that serve Organization clients must request origin authentication and integrity verification data on every answer from an authoritative source. The resolver must verify that data before it uses the answer. The Organization routes client DNS through the DNS filtering service. System Owners must make sure that resolution paths validate answers and do not simply forward them. A resolver must reject an answer that fails validation; it must not use the answer with a warning. Bypassing the protected resolution path requires a documented exception that the ISSO approves.

SC-22 — Architecture and Provisioning for Name/Address Resolution Service #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Ensure the systems that collectively provide name/address resolution service for an organization are fault-tolerant and implement internal and external role separation.

Implementation guidance:

The systems that together provide name and address resolution must keep resolving when a component fails. System Owners must run redundant instances placed so that no single failure stops resolution. The service must separate internal and external roles: the servers that answer the internet must not also serve internal clients, and internal resolution must not be reachable from outside. System Owners must host the external authoritative service on redundant cloud platform infrastructure and must keep internal resolution separate behind the boundary. Any change to the resolution architecture requires ISSO review before implementation.

SC-23 — Session Authenticity #

Baselines: Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Protect the authenticity of communications sessions.

Implementation guidance:

The Organization must protect the authenticity of every communications session so that both ends can trust who they are talking to for the life of the session. This protection defeats session hijacking and man-in-the-middle attacks. All user and application sessions must run over authenticated, encrypted channels, consistent with OMB M-22-09 and NIST SP 800-207. The ZTNA service brokers the user sessions, and services in the cloud platform carry the encrypted service sessions. Applications must generate session identifiers unpredictably, carry them only on protected channels, and invalidate them at logout. System Owners must make sure that their applications meet these session-handling requirements before authorization.

SC-24 — Fail in Known State #

Baselines: High

Requirement:

Fail to a [Assignment: organization-defined known system state — to be defined] for the following failures on the indicated components while preserving [Assignment: organization-defined system state information — to be defined] in failure: [Assignment: organization-defined types of system failures on system components — to be defined].

Implementation guidance:

System Owners must design systems so that [SC-24 parameter 1 — to be defined] cause the affected component to fail to [SC-24 parameter 2 — to be defined]. During such a failure, the system must preserve [SC-24 parameter 3 — to be defined] to support recovery and investigation. A failure must not expose information, open access controls, or leave data corrupted. The System Owner must document the failure types, the known state, and the preserved information in the system security and privacy plan. The Information System Security Officer (ISSO) must verify fail-state behavior by testing before production use and after significant changes. The Chief Information Security Officer (CISO) must approve any component that cannot meet this requirement, along with its compensating safeguards.

SC-28 — Protection of Information at Rest #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Protect the confidentiality AND integrity of the following information at rest: [Assignment: organization-defined information at rest — to be defined].

Implementation guidance:

The Organization must protect the confidentiality and integrity of information at rest. At a minimum, this covers sensitive PII, sensitive business identifiable information (BII), and information categorized as moderate or high impact under FIPS 199. Under OMB M-22-09, the protection must be cryptographic and must use FIPS-validated modules. System Owners must encrypt storage in the cloud platform at rest wherever covered information lives, including volumes, object stores, databases, and backups. Security-relevant system information, such as configurations and credentials, must receive the same protection. If anyone finds storage that holds covered information without encryption, the System Owner must treat it as a security finding and correct it. Scheduling the fix as routine maintenance is not acceptable.

SC-28(1) — Cryptographic Protection #

Baselines: Low / Moderate / High

Requirement:

Implement cryptographic mechanisms to prevent unauthorized disclosure and modification of the following information at rest on all information system components storing Federal data or system data that must be protected at the High or Moderate impact levels: [Assignment: organization-defined information — to be defined].

Implementation guidance:

The Organization must encrypt sensitive data at rest on every system component so that no one can read or alter it without authorization. The cryptographic modules must be FIPS-validated, as OMB M-22-09 requires. System Owners must not exempt any class of component: server storage, databases, backups, and endpoint drives all require encryption. Any exception requires a risk decision that the CISO accepts, with compensating controls and an expiration date.

SC-39 — Process Isolation #

Baselines: Low / Moderate / High CSF 2.0: PR.DS (Data Security), PR.PS (Platform Security)

Requirement:

Maintain a separate execution domain for each executing system process.

Implementation guidance:

Systems must keep a separate execution domain for every running process. Each process runs in its own address space, and processes communicate only through controlled interfaces. Without this isolation, a single bug in one process can compromise the whole system. The platform provides this isolation: the operating systems in the standard build enforce per-process separation, and the Organization inherits workload isolation beneath the operating system from the cloud platform under its FedRAMP authorization. System Owners must not disable or weaken the isolation features. A configuration that would let processes share an execution domain requires a documented exception that the CISO approves.

SC-45 — System Time Synchronization #

Baselines: Moderate / High

Requirement:

Synchronize system clocks within and between systems and system components.

Implementation guidance:

Administrators must keep the clocks of systems and their components synchronized with each other, so that events across the environment share one consistent timeline. System Owners must make sure that workloads in the cloud platform synchronize to the platform’s time service. Other managed components must synchronize to a consistent authoritative time reference. Systems must record timestamps in a common standard. Administrators must treat unexplained clock drift as a fault and correct it promptly. The ISSO must consider time integrity when weighing audit evidence.

SC-45(1) — Synchronization with Authoritative Time Source #

Baselines: Moderate / High

Requirement:

1. Compare the internal system clocks At least hourly with http://tf.nist.gov/tf-cgi/servers.cgi; and
2. Synchronize the internal system clocks to the authoritative time source when the time difference is greater than any difference.

Implementation guidance:

Systems must compare their internal clocks with the designated authoritative time source on the schedule the Organization defines. When the difference exceeds the defined tolerance, the system must resynchronize its clock. A clock that no one rechecks drifts until its timestamps are no longer reliable evidence. System Owners must configure the comparison to run automatically. A correction beyond the tolerance must happen without waiting for an operator to notice.

4. Roles and Responsibilities #

These roles apply across this policy. Each System Owner records the system-specific assignments in the system’s System Security and Privacy Plan (SSPP).

5. Performance Measurement #

The CISO manages this policy with the measures below, which meet the IG FISMA maturity model’s Level 4 (Managed and Measurable) criteria. The CISO collects and trends the measures and reports them to the CIO and the Authorizing Officials. When a measure moves away from its target, the CISO starts corrective action through the POA&M process.

The CISO keeps the measurement data for the annual IG FISMA evaluation and for trend analysis across reporting periods.

6. Compliance and Enforcement #

Every employee, contractor, and other user with access to an information system that the Organization operates, or that others operate for it, must comply with this policy. The CISO records each case of non-compliance as a finding in the Organization’s continuous monitoring program. The ISSO tracks the finding to resolution as a POA&M item, as OMB Circular A-130 and NIST SP 800-37 Rev. 2 describe.

A violation of this policy can lead to suspension of system access, withdrawal of the system’s authorization to operate (ATO), and administrative or disciplinary action under applicable law, regulation, and human capital policy.

The Inspector General assesses the maturity of system and communications protection controls each year through the IG FISMA reporting metrics. The target maturity level for this policy area is Level 4: Managed and Measurable.

7. Continuous Improvement #

Level 4 is the minimum the Organization aims for. To meet the IG FISMA maturity model’s Level 5 (Optimized) criteria, the CISO improves system and communications protection through these commitments:

1. Review the performance measures in this document at least annually; where a measure has met its target for four consecutive periods, tighten the target or replace the measure with a more demanding indicator.
2. Conduct an annual effectiveness review of this policy area using IG FISMA audit results, assessment findings, incident data, and metric trends; document resulting changes in the revision history.
3. Feed lessons learned from incidents, assessments, and exercises into updates of this document and its procedures within 90 days of the triggering event.
4. Benchmark against the IG FISMA maturity model annually and maintain a documented plan to reach and sustain Level 4 (Managed and Measurable), with a roadmap toward Level 5 (Optimized).
5. Advance network segmentation toward identity-aware microsegmentation for high-value segments, measured by lateral-movement test results.

8. Exceptions and Waivers #

The CISO may grant an exception to this policy only when compliance is not technically feasible or would harm the mission. To request one, the System Owner sends the CISO a written request that includes:

1. A business justification and a risk assessment.
2. Compensating controls that reduce the risk the exception creates, following the NIST SP 800-53B guidance on compensating controls.
3. A proposed end date no more than one year away.

The CISO decides each request in coordination with the Authorizing Official. An exception that involves privacy risk also needs the agreement of the Senior Agency Official for Privacy (SAOP). The CISO re-evaluates each exception when it comes up for renewal. The System Owner records each approved exception in the system’s SSPP, and the ISSO tracks it as a POA&M item.

9. References #

These are the sources this document cites, with a link to each official text.

• CISA BOD 18-01: Enhance Email and Web Security, October 16, 2017.
• CISA BOD 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• Executive Order 14412: Securing the Nation Against Advanced Cryptographic Attacks, June 22, 2026.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• Superseded source, kept for its history: FIPS 140-2: Security Requirements for Cryptographic Modules, May 25, 2001. Replaced by FIPS 140-3.
• FIPS 140-3: Cryptographic Module Security Requirements, March 22, 2019.
• FIPS 140-3 Transition Effort, updated continuously.
• FIPS 199: Standards for Security Categorization, February 2004.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• NIST SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations, August 2019.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-53B: Control Baselines for Information Systems and Organizations, September 2020.
• NIST SP 800-57 Part 1 Rev. 5: Recommendation for Key Management: Part 1 - General, May 2020.
• NIST SP 800-119: Guidelines for the Secure Deployment of IPv6, December 2010.
• NIST SP 800-207: Zero Trust Architecture, August 2020.
• OMB Circular A-123: Management’s Responsibility for Internal Control, March 10, 2026.
• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• OMB M-15-13: Policy to Require Secure Connections across Federal Websites and Web Services, June 8, 2015.
• OMB M-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-19-26: Update to the Trusted Internet Connections (TIC) Initiative, September 12, 2019.
• OMB M-21-07: Completing the Transition to Internet Protocol Version 6 (IPv6), November 19, 2020.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-23-02: Migrating to Post-Quantum Cryptography, November 18, 2022.
• OMB M-26-15: Execution of the Migration to Post-Quantum Cryptography, June 24, 2026.
• Responsibilities for Federal information systems standards (40 U.S.C. § 11331).