Access Control 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 access control 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 #

In this policy, the CISO sets how the Organization controls who can reach its systems and information, and what each person may do once inside. The Inspector General, the assessors, and the adversaries who probe the Organization all test the same thing: whether the Organization controls who can touch what. The Office of Personnel Management (OPM) breach and the SolarWinds intrusions that led to Executive Order (EO) 14028 both began with an account that could reach more than its owner needed. The account kept that access longer than anyone intended, and no one monitored it.

Federal direction defines what that control must look like. OMB M-22-09 requires the Organization to authenticate, authorize, and encrypt every access request, every session, and every application programming interface (API) call based on dynamic risk, not on network location. It also requires phishing-resistant credentials for privileged access. NIST SP 800-207 supplies the architecture: a per-session authorization decision that weighs device posture and behavioral signals and never grants standing trust. Cybersecurity and Infrastructure Security Agency (CISA) Binding Operational Directive (BOD) 23-02 closes the most common shortcut by ordering management interfaces off the public internet. OMB M-19-03 sets a higher standard for the Organization’s High Value Assets. The CISA High Value Asset (HVA) overlay isolates those systems behind least-privilege access and tiered boundary controls, because an adversary would choose them first.

The Organization meets these mandates with a layered set of identity systems, and every reader of this policy uses part of it. The single sign-on (SSO) service authenticates the workforce, federates single sign-on across the Organization’s software as a service (SaaS) applications, and enforces adaptive multi-factor authentication. Cloud directory conditional access makes the risk-based, device-aware session decisions that M-22-09 requires. Privileged identity management grants elevated rights just in time and removes them on schedule. On-premises, the on-premises directory and its group policy objects apply the same rules to Windows infrastructure through password and lockout policy and hardening scoped to organizational units. Personal Identity Verification (PIV) cards and Fast Identity Online 2 (FIDO2) keys give every privileged user a phishing-resistant factor, as Federal Information Processing Standards (FIPS) 201-3 requires. The joiner-mover-leaver pipeline ties accounts to the personnel lifecycle: a human resources (HR) action leads to SSO deprovisioning in under 24 hours, because an account that outlives its owner’s employment leaves the Organization exposed.

Each audience uses this policy differently. Executives use it to accept or refuse standing access to the Organization’s information. System Owners and Information System Security Officers (ISSOs) use the requirements, roles, and measures in this policy as their build specification and evidence checklist. Each requirement names its SP 800-53 control, its parameter values, and the measure the CISO trends. Every user is responsible for the accounts, sessions, and sharing decisions this policy governs, and the rules of behavior each user acknowledged put this policy into daily practice. The CISO removes access that no one can justify and verifies continuously the access that someone can.

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.AA — Identity Management, Authentication, and Access Control (Protect function)
• PR.DS — Data Security (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 access control in the moderate baseline of FIPS 200 and NIST SP 800-53B:

• AC-01 — Policy and Procedures
• AC-02 — Account Management
• AC-02(1) — Automated System Account Management
• AC-02(12) — Account Monitoring for Atypical Usage
• AC-02(13) — Disable Accounts for High-risk Individuals
• AC-02(2) — Automated Temporary and Emergency Account Management
• AC-02(3) — Disable Accounts
• AC-02(4) — Automated Audit Actions
• AC-02(5) — Inactivity Logout
• AC-02(7) — Privileged User Accounts
• AC-02(9) — Restrictions on Use of Shared and Group Accounts
• AC-03 — Access Enforcement
• AC-03(14) — Individual Access
• AC-04 — Information Flow Enforcement
• AC-04(21) — Physical or Logical Separation of Information Flows
• AC-05 — Separation of Duties
• AC-06 — Least Privilege
• AC-06(1) — Authorize Access to Security Functions
• AC-06(10) — Prohibit Non-privileged Users from Executing Privileged Functions
• AC-06(2) — Non-privileged Access for Nonsecurity Functions
• AC-06(5) — Privileged Accounts
• AC-06(7) — Review of User Privileges
• AC-06(9) — Log Use of Privileged Functions
• AC-07 — Unsuccessful Logon Attempts
• AC-08 — System Use Notification
• AC-11 — Device Lock
• AC-11(1) — Pattern-hiding Displays
• AC-12 — Session Termination
• AC-14 — Permitted Actions Without Identification or Authentication
• AC-17 — Remote Access
• AC-17(1) — Monitoring and Control
• AC-17(2) — Protection of Confidentiality and Integrity Using Encryption
• AC-17(3) — Managed Access Control Points
• AC-17(4) — Privileged Commands and Access
• AC-18 — Wireless Access
• AC-18(1) — Authentication and Encryption
• AC-18(3) — Disable Wireless Networking
• AC-19 — Access Control for Mobile Devices
• AC-19(5) — Full Device or Container-based Encryption
• AC-20 — Use of External Systems
• AC-20(1) — Limits on Authorized Use
• AC-20(2) — Portable Storage Devices — Restricted Use
• AC-21 — Information Sharing
• AC-22 — Publicly Accessible Content

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-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM), May 21, 2019.
• Executive Order 14028: Improving the Nation’s Cybersecurity, May 12, 2021.
• FIPS 201-3: Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the AC 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 implement a zero trust architecture where every access request is fully authenticated, authorized, and encrypted before granting access. Access decisions must be based on dynamic risk assessment, not static network location. Deadline: FY 2024. (OMB M-22-09, §2)
• The organization must employ multi-factor authentication (MFA) for all users, with phishing-resistant MFA for all privileged accounts and all remote access. Password-based authentication alone is insufficient. Deadline: FY 2024. (OMB M-22-09, §3(a)(i))
• The organization must implement continuous authorization for access sessions, periodically re-evaluating user identity, device posture, and behavioral context throughout the session, not just at initial login. Deadline: FY 2024. (OMB M-22-09, §3)
• The organization must designate a zero trust strategy implementation lead within 30 days of the memorandum’s publication. This lead is responsible for Government-wide coordination and OMB engagement on planning and implementation. Deadline: 30 days from issuance. (OMB M-22-09, §2)

NIST SP 800-207: Zero Trust Architecture

• The organization must ensure all access to resources is authenticated and authorized on a per-session basis, regardless of network location. Trust must never be granted implicitly based on network proximity. (NIST SP 800-207, §3.1)
• The organization must make access policies dynamic, using device security posture, user behavior analytics, and threat intelligence to make real-time authorization decisions. (NIST SP 800-207, §3.2)

CISA BOD 25-01: Implementing Secure Practices for Cloud Services

• The organization must ensure cloud service provider (CSP) access to agency environments is monitored, logged, and restricted to authorized personnel only. CSP management plane access must follow least-privilege principles. (CISA BOD 25-01, §3)

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

• The organization must identify and remove internet-exposed management interfaces from public-facing networks. Management interfaces must be accessible only through internal networks or via VPN with MFA. (CISA BOD 23-02, §1)

NIST SP 800-63-4: Digital Identity Guidelines

• The organization must require multi-factor authentication at AAL2 and AAL3, and at AAL3 require a phishing-resistant authenticator with a non-exportable private key. (NIST SP 800-63B-4, §2)
• The organization must set each system’s session limits from its authentication assurance level: no more than 30 days at AAL1; 24 hours, or 1 hour of inactivity, at AAL2; and 12 hours, or 15 minutes of inactivity, at AAL3. (NIST SP 800-63B-4, §2 (reauthentication at each AAL))

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

• The organization must apply enhanced access safeguards to High Value Assets, including privileged access management and network segmentation commensurate with the asset’s value and the threats it faces, informed by the CISA HVA control overlay. (OMB M-19-03, §B)

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

• The organization must control and limit access for HVA users through the overlay’s least-privilege selections (AC-6 and enhancements), ensuring privileged access to HVAs receives elevated scrutiny and restriction. (CISA HVA Control Overlay v1.0, AC-6)

OMB M-23-22: Delivering a Digital-First Public Experience

• The organization must link every page of each public website to the privacy policy and the other notices OMB M-23-22 requires. (OMB M-23-22, §III)

CISA Zero Trust Maturity Model v2.0

• The organization should progress through the maturity levels (Traditional, Initial, Advanced, Optimal) for the identity, device, network, application, and data pillars, moving access control from static roles to dynamic, risk-based decisions. (CISA ZTMM v2.0, §5)

NIST SP 800-124 Rev 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise

• The organization should manage organization-issued mobile devices with enterprise mobility management, and use mobile threat defense to detect device, app, and network threats. (NIST SP 800-124 Rev 2, §§3-4)

NIST SP 800-163 Rev 1: Vetting the Security of Mobile Applications

• The organization should vet each mobile app against the Organization’s security requirements before approving it for organization devices, and vet it again when it is updated. (NIST SP 800-163 Rev 1, §§2-3)

NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs)

• The organization should monitor for rogue wireless access points and other unauthorized wireless devices, and remove or block any that are found. (NIST SP 800-153, §3)

CISA: Mobile Communications Best Practice Guidance

• The organization should give highly targeted staff, such as senior officials, approved end-to-end encrypted messaging, and do not let them use text messages as a sign-in factor. (CISA Mobile Communications Best Practice Guidance)

3. Policy #

The Organization must implement and maintain its access control controls to meet the following requirements:

The twenty-three base controls and their enhancements in this section work as one system. AC-1 sets the governance. AC-2 through AC-6 form the account and privilege core: the Organization creates every account deliberately, limits it by least privilege and separation of duties, and re-verifies it on schedule. AC-7 through AC-12 govern the session itself, from lockout after failed logons through device lock and session termination. AC-17 through AC-20 apply the same rules to remote access, wireless, mobile devices, and external systems, where the boundary is weakest. AC-21 through AC-25 govern what authorized users may share and publish once inside. Read each requirement as part of that chain. Weakening one control reopens the path that the other controls close.

AC-01 — Policy and Procedures #

Baselines: Low / Moderate / High / Privacy CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

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] access control 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 access control policy and the associated access controls;

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

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

Implementation guidance:

The CISO owns this policy and the procedures that put it into practice. The CISO must issue the access control policy for the whole Organization and distribute it through the policy library to the Authorizing Official, System Owners, ISSOs, and key stakeholders. The CISO must review the policy every 3 years, and sooner after a major change to a law, a directive, or the Organization’s operating environment. The CISO must review the procedures on the same cycle. Every requirement in this policy takes its authority from this control. Anyone who needs to deviate from a requirement must use the exception process in this policy. Supervisors must make sure the personnel they manage know which parts of this policy apply to their daily work. The CISO sets the Organization’s zero trust targets for access decisions in the Zero Trust and ICAM Implementation Plan (PLAN-ZT-001).

AC-02 — Account Management #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Define and document the types of accounts allowed and specifically prohibited for use within the system;
2. Assign account managers;
3. Require [Assignment: organization-defined prerequisites and criteria — to be defined] for group and role membership;
4. Specify:

1. Authorized users of the system;
2. Group and role membership; and
3. Access authorizations (i.e., privileges) and [Assignment: organization-defined attributes (as required) — to be defined] for each account;

5. Require approvals by [Assignment: organization-defined personnel or roles — to be defined] for requests to create accounts;
6. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria — to be defined];
7. Monitor the use of accounts;
8. Notify account managers and [Assignment: organization-defined personnel or roles — to be defined] within:

1. twenty-four (24) hours when accounts are no longer required;
2. eight (8) hours when users are terminated or transferred; and
3. eight (8) hours when system usage or need-to-know changes for an individual;

1. Authorize access to the system based on:

1. A valid access authorization;
2. Intended system usage; and
3. [Assignment: organization-defined attributes (as required) — to be defined];

10. Review accounts for compliance with account management requirements quarterly for privileged access, annually for non-privileged access;
11. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and
12. Align account management processes with personnel termination and transfer processes.

Implementation guidance:

Every account must have a current, recorded justification. System Owners, or the designees they name, must approve a new account only when it has an approved access request, completed training, and a recorded expiration date where one applies. Group and role membership must match the holder’s clearance, need for access, and job responsibilities. Account managers and the System Owner must receive notice within 24 hours when an account is no longer needed, when the holder leaves or transfers, or when the holder’s need to know changes. The ISSO and System Owners must review all non-privileged accounts at least every quarter and all privileged accounts every quarter. In each review, the Information Owner must confirm that each user’s role and privileges still fit the information the user may reach. Each System Owner must keep an inventory of service, system, and other non-person accounts. The inventory must record each account’s purpose, the systems it reaches, its privileges, and the named person accountable for the account and its credentials. Account managers must disable any account that fails review.

AC-02(1) — Automated System Account Management #

Baselines: Moderate / High

Requirement:

Support the management of system accounts using [Assignment: organization-defined automated mechanisms — to be defined].

Implementation guidance:

Identity administrators must manage accounts through the automated lifecycle workflows in the SSO service and the cloud directory. The workflows provision an account on approval, update it on a role change, and disable it on separation. Administrators must not create or change accounts outside these workflows, except under a documented emergency procedure. After the emergency ends, the administrator must reconcile every such exception with the automated system of record.

AC-02(2) — Automated Temporary and Emergency Account Management #

Baselines: Moderate / High

Requirement:

Automatically Selection: disables temporary and emergency accounts after no more than 96 hours from last use.

Implementation guidance:

Every temporary or emergency account must have an expiration date that the account manager records when creating the account. The identity platform must remove or disable the account automatically when that period ends. The System Owner must approve each temporary or emergency account, and how long it will last, before anyone provisions it. Account managers must not let a temporary account become a standing one. A user who needs access after the expiration must submit a new request through the normal AC-02 process.

AC-02(3) — Disable Accounts #

Baselines: Moderate / High

Requirement:

Disable accounts within 24 hours for user accounts when the accounts: (a) Have expired; (b) Are no longer associated with a user or individual; (c) Are in violation of organizational policy; or (d) Have been inactive for ninety (90) days (See additional requirements and guidance.).

Implementation guidance:

Account managers must disable an account within 24 hours after it expires, after it no longer belongs to an active user, or after it supports a policy violation. They must also disable any user account that has been inactive for 90 days. Account managers must act when the trigger occurs and must not wait for the next review cycle. Service, system, and other non-person accounts are not disabled automatically for inactivity. Instead, the System Owner must confirm the need for each one in every account review and must have the account manager disable any account without a confirmed need.

AC-02(4) — Automated Audit Actions #

Baselines: Moderate / High

Requirement:

Automatically audit account creation, modification, enabling, disabling, and removal actions.

Implementation guidance:

The platform that creates, changes, enables, disables, or removes an account must log the action automatically. Each log entry must record who acted, what changed, and when. System Owners must not allow any administrative path that changes accounts outside these logged mechanisms. The ISSO must include the account records in audit review and must treat any account action with no explanation as a security concern.

AC-02(5) — Inactivity Logout #

Baselines: Moderate / High

Requirement:

Require that users log out when for privileged users, it is the end of a user’s standard work period.

Implementation guidance:

Locking the screen is not enough. All personnel must log out before an absence longer than the time period of expected inactivity or description of when to log out listed for AC-02(5) parameter 1 in the parameter table. They must also log out when they leave the area and cannot watch the system for physical tampering, and when they cannot keep unauthorized people from seeing the display. Supervisors must hold their teams to this rule. The rules of behavior that every user signs include this obligation. The automatic device lock under AC-11 protects a user who forgets, but it does not replace the user’s duty to end the session.

AC-02(7) — Privileged User Accounts #

Baselines: Moderate / High

Requirement:

1. Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme; an attribute-based access scheme — to be defined];
2. Monitor privileged role or attribute assignments;
3. Monitor changes to roles or attributes; and
4. Revoke access when privileged role or attribute assignments are no longer appropriate.

Implementation guidance:

Account managers must create and administer privileged user accounts only through the role-based access scheme. The System Owner must define what each privileged role may do, and a user gains those permissions only by holding the role. The ISSO must monitor privileged role assignments and every change to them. Account managers must revoke an assignment as soon as it no longer matches the holder’s duties, without waiting for the next review.

AC-02(9) — Restrictions on Use of Shared and Group Accounts #

Baselines: Moderate / High

Requirement:

Only permit the use of shared and group accounts that meet organization-defined need with justification statement that explains why such accounts are necessary.

Implementation guidance:

Account managers must not create a shared or group account unless the System Owner has explicitly authorized it for a validated mission or business need. Convenience is not a valid need. Each authorized shared account must have an account manager who always knows who holds the credential. The account manager must remove a holder as soon as that person’s need ends. Account managers must disable any shared account that cannot show a current authorization.

AC-02(12) — Account Monitoring for Atypical Usage #

Baselines: Moderate / High

Requirement:

1. Monitor system accounts for [Assignment: organization-defined atypical usage — to be defined]; and
2. Report atypical usage of system accounts to at a minimum, the ISSO and/or similar role within the organization.

Implementation guidance:

The ISSO must monitor system accounts for unauthorized access attempts, connections to prohibited materials or sites, unusually large data transfers, and activity outside normal business hours. The ISSO must report atypical usage to the CISO, and to Physical Security when the activity involves a facility or a physical presence. The ISSO must keep the monitoring configuration matched to these indicators as platforms and work patterns change.

AC-02(13) — Disable Accounts for High-risk Individuals #

Baselines: Moderate / High

Requirement:

Disable accounts of individuals within one (1) hour of discovery of [Assignment: organization-defined significant risks — to be defined].

Implementation guidance:

Account managers must disable a user’s accounts within 1 hour after the Organization discovers a risk from that user. At minimum, the triggering risks are a burst of incorrect login attempts in a short period, geo-blocked login attempts, and login attempts at unusual hours. A violation of the rules of behavior or Organization policy is also a trigger. The CISO must direct the disablement, and account managers must carry it out. The account must stay disabled until the CISO approves reinstatement.

AC-03 — Access Enforcement #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Requirement:

Enforce approved authorizations for logical access to information and system resources in accordance with applicable access control policies.

Implementation guidance:

System Owners must enforce approved authorizations at every point where their systems decide whether to grant access. Cloud directory conditional access checks each session against user, device, and risk signals before it grants access, as OMB M-22-09 requires. The on-premises directory access control lists and security groups enforce authorizations on domain resources. The cloud platform identity policies limit what administrators and workloads can reach in the cloud. No component may grant access based on network location alone. System Owners must make sure the technical enforcement in their systems matches the authorizations approved under AC-02. System Owners must treat any difference between the two as a defect and correct it.

AC-03(14) — Individual Access #

Baselines: Privacy

Requirement:

Provide [Assignment: organization-defined mechanisms — to be defined] to enable individuals to have access to the following elements of their personally identifiable information: [Assignment: organization-defined elements — to be defined].

Implementation guidance:

The Organization must give each individual a way to see the personally identifiable information (PII) it holds about them. System Owners of systems that retrieve records by a person’s name or identifier must offer [AC-03(14) parameter 1 — to be defined] for this purpose. Through these mechanisms, an individual must be able to obtain [AC-03(14) parameter 2 — to be defined]. The Senior Agency Official for Privacy (SAOP) must approve each access mechanism before it goes into use. The Privacy Officer must confirm a requester’s identity before any record is released. The SAOP must consult General Counsel before the Organization withholds a record under a legal exemption. The Privacy Officer must describe how to request access in each system of records notice and on the Organization’s public website.

AC-04 — Information Flow Enforcement #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Requirement:

Enforce approved authorizations for controlling the flow of information within the system and between connected systems based on [Assignment: organization-defined information flow control policies — to be defined].

Implementation guidance:

System Owners must enforce information flow authorizations under the Organization Access Control Policy within each system and between connected systems. Export-controlled information must leave Organization-controlled networks only under approved encryption. Boundary devices must drop inbound traffic that presents an internal source address. Web requests bound for the Internet must leave only through the internal web proxy path that the secure web gateway provides. Any further flow enforcement policy takes effect only with the Configuration Control Board (CCB)/the Change Advisory Board (CAB) approval, and the network team enforces it through firewall rulesets. A firewall rule that appears without that approval is a configuration incident, and the CISO must treat it as one. System Owners must keep the approved flows for their systems documented so an assessor can trace every ruleset line to a decision.

AC-04(21) — Physical or Logical Separation of Information Flows #

Baselines: Moderate / High

Requirement:

Separate information flows logically or physically using [Assignment: organization-defined mechanisms and/or techniques — to be defined] to accomplish [Assignment: organization-defined required separations — to be defined].

Implementation guidance:

System Owners must keep distinct information flows separated, logically or physically, so one flow cannot observe, redirect, or join another. The System Owner must document which separations the architecture must achieve and the mechanisms that achieve them. The System Owner must put both the separations and the mechanisms through configuration change control before the network team implements them. The ISSO must verify that the implemented configuration matches the documented design.

AC-05 — Separation of Duties #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Requirement:

1. Identify and document [Assignment: organization-defined duties of individuals — to be defined]; and
2. Define system access authorizations to support separation of duties.

Implementation guidance:

System Owners must identify and document the duties that require separation. Four separations always apply. Personnel who administer access control must not perform audit functions. Administrators must remain a limited group whose access follows their role and responsibility. Critical mission functions and system support functions must belong to different individuals. The ISSO must run security testing of the system; the operators of the system must not. System Owners must define access authorizations that build these separations into the systems themselves, so each separation exists in the permissions and not only on paper.

AC-06 — Least Privilege #

Baselines: Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control), PR.DS (Data Security)

Requirement:

Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks.

Implementation guidance:

System Owners must grant each user and each process only the access its function requires, and nothing more. System Owners must define role-based permission sets so that access follows the job, not the individual. Privileged functions must stay separate from standard duties. An administrator gains elevated rights through cloud directory privileged identity management just in time, with approval, and the elevation expires on schedule. Under OMB M-22-09, privileged access must use phishing-resistant PIV or hardware security key credentials. Supervisors must request a reduction in access when a user’s duties change. The Organization treats over-provisioning found in a review as a failure to follow this policy.

AC-06(1) — Authorize Access to Security Functions #

Baselines: Moderate / High

Requirement:

Authorize access for [Assignment: organization-defined individuals and roles — to be defined] to: (a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware) — to be defined]; and (b) [Assignment: organization-defined security-relevant information — to be defined].

Implementation guidance:

Only the ISSO, Security Administrators, System Administrators, and Network Administrators may operate security functions or handle security-relevant information. Security functions include creating and configuring accounts, granting permissions, selecting the events to audit, and adjusting intrusion detection parameters. Security-relevant information includes firewall and router filtering rules, security service settings, cryptographic key material, and access control lists. The System Owner must authorize each individual grant explicitly. No one gains membership in the administrator group because of a job title.

AC-06(2) — Non-privileged Access for Nonsecurity Functions #

Baselines: Moderate / High

Requirement:

Require that users of system accounts (or roles) with access to all security functions use non-privileged accounts or roles, when accessing nonsecurity functions.

Implementation guidance:

Users who hold access to security functions or security-relevant information under AC-06(1) must do all nonsecurity work from a non-privileged account or role. Nonsecurity work includes mail, documents, browsing, and routine collaboration. The privileged identity exists for privileged tasks and nothing else. System Owners must make sure every administrator holds a separate standard account. The ISSO must treat routine work done under a privileged identity as a reportable violation, because every unnecessary privileged session adds exposure.

AC-06(5) — Privileged Accounts #

Baselines: Moderate / High

Requirement:

Restrict privileged accounts on the system to [Assignment: organization-defined personnel or roles — to be defined].

Implementation guidance:

Only individuals whom the System Owner has vetted and validated as needing privileged access may hold a privileged account. The System Owner must authorize each person individually and document the authorization, and the System Owner can revoke it at any time. The Organization does not allow shared privileged accounts, and no one gains privilege by custom or by inheriting another person’s role. The CISO must maintain the roster of privileged account holders. The identity team must disable any privileged account that is not on the roster as soon as anyone discovers it.

AC-06(7) — Review of User Privileges #

Baselines: Moderate / High

Requirement:

1. Review at a minimum, annually the privileges assigned to all users with privileges to validate the need for such privileges; and
2. Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

Implementation guidance:

The ISSO must review the privileges assigned to all users at least every year and whenever a user’s duties change. The review must confirm that each privilege still serves a current mission or business need. Privileged roles receive a deeper review every quarter as part of the privileged account review cycle. When a privilege fails validation, the System Owner must have it reassigned or removed through the standard workflow.

AC-06(9) — Log Use of Privileged Functions #

Baselines: Moderate / High

Requirement:

Log the execution of privileged functions.

Implementation guidance:

The platform where a privileged function runs must record every execution of that function in its audit log. The record must identify the function, the identity, and the time. System Owners must not allow any approved path to privileged work that bypasses logging. A change that disables or reduces this logging is itself a privileged action, and it must appear in the audit record. The ISSO must confirm that logging coverage continues as systems change.

AC-06(10) — Prohibit Non-privileged Users from Executing Privileged Functions #

Baselines: Moderate / High

Requirement:

Prevent non-privileged users from executing privileged functions.

Implementation guidance:

Systems must prevent non-privileged users from executing privileged functions. The attempt must fail at the access decision; policy alone is not enough. System Owners must make sure that administrative interfaces, security configuration, and integrity mechanisms are reachable only by identities that hold the authorized roles. The ISSO must treat any privileged action that succeeds from a non-privileged identity as a security incident, because it shows that the enforcement has failed.

AC-07 — Unsuccessful Logon Attempts #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Enforce a limit of [Assignment: organization-defined number — to be defined] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period — to be defined]; and
2. Automatically [Selection (one or more): lock the account or node for [organization-defined]; lock the account or node until released by an administrator; delay next logon prompt per [organization-defined]; notify system administrator; take other [organization-defined] — to be defined] when the maximum number of unsuccessful attempts is exceeded.

Implementation guidance:

Every system must limit a user to [AC-07 parameter 1 — to be defined] consecutive invalid logon attempts within a [AC-07 parameter 2 — to be defined] window. When a user exceeds the limit, the system must lock the account until an administrator releases it, or delay the next logon prompt by at least [AC-07 parameter 3 — to be defined]. Group policy enforces the threshold on domain-joined systems, and the SSO service applies the same lockout for federated application access. Lockout events are security signals that the ISSO must review. The ISSO must treat repeated lockouts on one account, or lockouts across many accounts, as a possible credential attack.

AC-08 — System Use Notification #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Display see additional Requirements and Guidance to users before granting access to the system that provides privacy and security notices consistent with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines and state that:

1. Users are accessing a U.S. Government system;
2. System usage may be monitored, recorded, and subject to audit;
3. Unauthorized use of the system is prohibited and subject to criminal and civil penalties; and
4. Use of the system indicates consent to monitoring and recording;

2. Retain the notification message or banner on the screen until users acknowledge the usage conditions and take explicit actions to log on to or further access the system; and
3. For publicly accessible systems:

1. Display system use information see additional Requirements and Guidance, before granting further access to the publicly accessible system;
2. Display references, if any, to monitoring, recording, or auditing that are consistent with privacy accommodations for such systems that generally prohibit those activities; and
3. Include a description of the authorized uses of the system.

Implementation guidance:

Every system must display the CISO-approved system use banner before it grants access. The banner must make four statements. The user is accessing a U.S. Government information system. The Organization may monitor, record, and audit system use. Use without authorization is prohibited and may lead to criminal and civil penalties. Use of the system means the user consents to monitoring and recording. The CISO must publish the approved banner text in the document management system, with a short form for devices with small screens. System Owners must not remove or reword any part of the banner, and the CISO must approve any system-specific wording. The banner must stay on screen until the user acknowledges it and acts to log on. A public website may meet this requirement for visitors by linking from every page to the Organization’s privacy policy and website security notice, as OMB M-23-22 directs. Where members of the public register for an account, the System Owner must show the terms of use at registration.

AC-11 — Device Lock #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Prevent further access to the system by [Selection (one or more): initiating a device lock after [organization-defined] of inactivity; requiring the user to initiate a device lock before leaving the system unattended — to be defined]; and
2. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Implementation guidance:

Systems must start a device lock after 15 minutes of inactivity on desktop systems and after [AC-11 parameter 1 — to be defined] of inactivity for web applications, remote access, and portable devices. Every user must be able to lock the device on demand before stepping away. Once the lock engages, it must hold until the user re-authenticates through the established identification and authentication path. There is no other way back into the session. The timers are enterprise configuration, and users must not be able to lengthen or disable them. System Owners must apply equivalent locks to components that are outside enterprise management.

AC-11(1) — Pattern-hiding Displays #

Baselines: Moderate / High

Requirement:

Conceal, via the device lock, information previously visible on the display with a publicly viewable image.

Implementation guidance:

When the device lock engages, it must hide everything that was visible on the screen behind a publicly viewable image, such as a neutral screen, a picture, or a clock. No information, including controlled unclassified information, may remain readable while the lock holds. The concealment must deploy as enterprise configuration together with the lock timers. System Owners must hold components outside the enterprise baseline to the same standard.

AC-12 — Session Termination #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

Automatically terminate a user session after [Assignment: organization-defined conditions or trigger events — to be defined].

Implementation guidance:

Every system must end a user session automatically at the reauthentication limits that NIST SP 800-63B-4 sets for the system’s authentication assurance level (AAL). At level 1 (AAL1), the session ends after 30 days in total. At level 2 (AAL2), it ends after 24 hours in total or after 1 hour of inactivity. At level 3 (AAL3), it ends after 12 hours in total or after 15 minutes of inactivity. A System Owner may set shorter limits. Ending the session means the session closes, its processes stop, and the user regains access only through full re-authentication. A screen lock is not enough. The System Owner must record the system’s AAL and its session limits in the System Security and Privacy Plan (SSPP). System Owners must make sure their applications treat an ended session as closed and do not resume it silently. The CISO must approve any longer limit through the exception process in this policy.

AC-14 — Permitted Actions Without Identification or Authentication #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Identify [Assignment: organization-defined user actions — to be defined] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and
2. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

Implementation guidance:

System Owners must identify the specific user actions their system allows without identification or authentication. System Owners must keep that list as short as the mission allows and document every entry, with its rationale, in the System Security and Privacy Plan (SSPP). Any action not on the list requires authentication. System Owners must re-justify the list whenever the system’s function changes. The ISSO must confirm that what the system allows matches what the SSPP says it allows. The permitted set is narrow: reading content the Organization has already cleared for public release, and little else.

AC-17 — Remote Access #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and
2. Authorize each type of remote access to the system prior to allowing such connections.

Implementation guidance:

The Organization must authorize each type of remote access before anyone uses it and must document its usage restrictions and permitted configurations. All remote sessions must route through zero trust network access. The zero trust network access (ZTNA) service authenticates the user through the SSO service, verifies device compliance through the mobile device management (MDM) tool, and encrypts every session. This design follows OMB M-22-09, which requires access decisions based on identity and device posture, not network location. The Organization does not grant broad network tunnels; the ZTNA service brokers access to one application at a time. An administrator who performs privileged functions remotely must authenticate with phishing-resistant PIV or hardware security key credentials, and the system must log the session.

AC-17(1) — Monitoring and Control #

Baselines: Moderate / High

Requirement:

Employ automated mechanisms to monitor and control remote access methods.

Implementation guidance:

Every remote access method must run under automated monitoring and control. The monitoring tools must observe sessions as they run, enforce policy in line, and end a session that violates policy without waiting for someone to read a log. The CISO must make sure no remote access method exists outside the monitored path. The ISSO must review remote session activity for violations and anomalies and escalate what the review finds.

AC-17(2) — Protection of Confidentiality and Integrity Using Encryption #

Baselines: Moderate / High

Requirement:

Implement cryptographic mechanisms to protect the confidentiality and integrity of remote access sessions.

Implementation guidance:

Every remote access session must use approved cryptography that protects both confidentiality and integrity. No part of the path between the user and the application may carry remote traffic in plaintext. System Owners must make sure that applications reached remotely do not downgrade or remove the session’s protection. The ISSO must verify the cryptographic configuration whenever the remote access stack changes.

AC-17(3) — Managed Access Control Points #

Baselines: Moderate / High

Requirement:

Route remote accesses through authorized and managed network access control points.

Implementation guidance:

All remote access must route through the managed access control points that the Organization operates, which means the ZTNA service. No system may accept a remote connection that arrives any other way. Management interfaces must not face the Internet, as CISA BOD 23-02 directs; they stay reachable only through the managed path. The CISO must approve any addition to the set of access control points. The ISSO must treat a remote path found outside that set as an incident.

AC-17(4) — Privileged Commands and Access #

Baselines: Moderate / High

Requirement:

1. Authorize the execution of privileged commands and access to security-relevant information via remote access only in a format that provides assessable evidence and for the following needs: [Assignment: organization-defined needs — to be defined]; and
2. Document the rationale for remote access in the security plan for the system.

Implementation guidance:

The Organization must allow privileged commands and access to security-relevant information over a remote connection only for emergency needs, or for ongoing operational support or security monitoring that the Chief Information Officer (CIO) has approved. Each such session must run through a mechanism that leaves assessable evidence of who did what and when. System Owners must record the rationale for each remote privileged allowance in the System Security and Privacy Plan (SSPP). An allowance with no documented rationale has no authorization.

AC-18 — Wireless Access #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and
2. Authorize each type of wireless access to the system prior to allowing such connections.

Implementation guidance:

For every type of wireless access, the Organization must set the configuration standards, the connection conditions, and the implementation guidance before it allows the first connection. The System Owner must authorize each wireless access type before any device uses it. Endpoints must receive their wireless settings through managed configuration, not manual setup, so devices join approved networks on approved terms. The Organization prohibits wireless connections to Organization systems outside an authorized type. Network Administrators must scan each Organization facility for unauthorized wireless access points at least once a quarter. Continuous monitoring with wireless intrusion detection may replace the quarterly scan, as NIST SP 800-153 recommends. The ISSO must treat the discovery of an unauthorized access point or connection as an incident.

AC-18(1) — Authentication and Encryption #

Baselines: Moderate / High

Requirement:

Protect wireless access to the system using authentication of [Selection (one or more): users; devices — to be defined] and encryption.

Implementation guidance:

Wireless access to Organization systems must authenticate both the user and the device before any traffic passes. Every wireless link must encrypt the traffic it carries. System Owners must not allow a wireless path that verifies the person but not the device, or one that carries traffic unencrypted. The credentials and settings that meet these requirements reach devices only through managed configuration.

AC-18(3) — Disable Wireless Networking #

Baselines: Moderate / High

Requirement:

Disable, when not intended for use, wireless networking capabilities embedded within system components prior to issuance and deployment.

Implementation guidance:

The Organization must disable the wireless capabilities built into a system component before it issues or deploys the component, unless the use of that capability is intended, documented, and authorized. Disablement happens during provisioning, not afterward. Build and configuration baselines must deliver components with unneeded wireless interfaces turned off. Turning an interface back on requires an authorized configuration change; a user must not be able to switch it on.

AC-19 — Access Control for Mobile Devices #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and
2. Authorize the connection of mobile devices to organizational systems.

Implementation guidance:

The Organization must set the configuration standards, connection conditions, and implementation guidance for the mobile devices it controls, including their use outside controlled areas. These rules must follow NIST SP 800-124 Rev. 2. No mobile device may connect to Organization systems without authorization. Enrollment in the MDM tool is how a device receives and keeps that authorization. A device that is not enrolled, or is enrolled but out of compliance, must not reach Organization resources. The MDM tool must block jailbroken or rooted devices and devices that run an out-of-date operating system. Every managed device must run mobile threat defense. Only apps on the approved mobile app list may handle Organization information. The CISO must approve an app for the list only after a security review under NIST SP 800-163 Rev. 1. An app that handles PII also needs a privacy threshold analysis first. Users must keep their devices under personal control outside controlled areas and must report a lost or stolen device without delay. The Mobile Device Policy (POL-MOB-001) sets the program rules for issuing, using, and recovering devices.

AC-19(5) — Full Device or Container-based Encryption #

Baselines: Moderate / High

Requirement:

Employ [Selection: full-device encryption; container-based encryption — to be defined] to protect the confidentiality and integrity of information on [Assignment: organization-defined mobile devices — to be defined].

Implementation guidance:

All Organization mobile devices must protect stored information with full-device encryption, container-based encryption, or both. The Organization enforces this requirement through the MDM tool compliance policy, not through user preference. A device that cannot show its encryption state must not hold Organization information and must not reach it. System Owners must not grant exceptions to this requirement.

AC-20 — Use of External Systems #

Baselines: Low / Moderate / High / HVA overlay CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. [Selection (one or more): establish [organization-defined]; identify [organization-defined] — to be defined], consistent with the trust relationships established with other organizations owning, operating, and/or maintaining external systems, allowing authorized individuals to:

1. Access the system from external systems; and
2. Process, store, or transmit organization-controlled information using external systems; or

2. Prohibit the use of [Assignment: organization-defined prohibited types of external systems — to be defined].

Implementation guidance:

The Organization must establish an interconnection security agreement (ISA), memorandum of understanding (MOU), or service level agreement (SLA) with an external party before an authorized individual uses the party’s system to access Organization systems. The same applies before anyone processes, stores, or transmits Organization-controlled information on that system. The agreement must identify, at minimum, the external party’s access controls, security and privacy protections, and incident response capabilities. If the Organization cannot establish those terms, no one may use the external system for Organization purposes. A user must not connect a device to any other network remotely while it is connected to an Organization information system. A personally owned device may reach Organization information only when the CISO has approved its device type and the user has enrolled it in app-level management. On such a device, Organization data must stay in a managed, encrypted work container that the Organization can wipe remotely. NIST SP 800-46 Rev. 2 and NIST SP 800-124 Rev. 2 describe this approach. The user must agree in the rules of behavior to report a lost device at once and to provide the device for incident response.

AC-20(1) — Limits on Authorized Use #

Baselines: Moderate / High

Requirement:

Permit authorized individuals to use an external system to access the system or to process, store, or transmit organization-controlled information only after: (a) Verification of the implementation of controls on the external system as specified in the organization’s security and privacy policies and security and privacy plans; or (b) Retention of approved system connection or processing agreements with the organizational entity hosting the external system.

Implementation guidance:

Authorized individuals may use an external system to reach Organization systems, or to handle Organization-controlled information, only in two cases. Either the Organization has verified that the required controls are in place on that system, or the Organization holds an approved agreement that governs the connection. The System Owner must decide this before first use. The System Owner must decide again whenever the external system changes materially.

AC-20(2) — Portable Storage Devices — Restricted Use #

Baselines: Moderate / High

Requirement:

Restrict the use of organization-controlled portable storage devices by authorized individuals on external systems using [Assignment: organization-defined restrictions — to be defined].

Implementation guidance:

Authorized individuals must not use Organization-controlled portable storage devices on external systems. This prohibition has no exception for convenience. All personnel must acknowledge the prohibition, and supervisors must enforce it in their teams. On Organization systems, the matching rule applies. The Organization must limit removable storage connections to explicitly authorized devices and must audit those connections, so an Organization device that appears where it should not leaves a record.

AC-21 — Information Sharing #

Baselines: Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Enable authorized users to determine whether access authorizations assigned to a sharing partner match the information’s access and use restrictions for [Assignment: organization-defined information-sharing circumstances — to be defined]; and
2. Employ [Assignment: organization-defined automated mechanisms — to be defined] to assist users in making information sharing and collaboration decisions.

Implementation guidance:

Some information requires a sharing check before release: controlled unclassified information, contract-sensitive or proprietary information, classified information in special access programs or compartments, privileged information, and personally identifiable information. Before sharing any of it, an authorized user must confirm that the receiving partner’s access authorizations match the information’s access and use restrictions. The Organization supports these decisions through the manual processes documented in the System Security and Privacy Plan (SSPP). System Owners must keep those processes current as the information types change. A user who is unsure whether a partner qualifies must withhold the information and ask the ISSO. The default answer is no.

AC-22 — Publicly Accessible Content #

Baselines: Low / Moderate / High CSF 2.0: PR.AA (Identity Management, Authentication, and Access Control)

Requirement:

1. Designate individuals authorized to make information publicly accessible;
2. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;
3. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and
4. Review the content on the publicly accessible system for nonpublic information at least quarterly and remove such information, if discovered.

Implementation guidance:

Only individuals the System Owner designates may make information publicly accessible. Each designated individual must complete training on recognizing nonpublic information before the designation takes effect. A designated reviewer must review every piece of proposed content before posting to confirm that it contains no nonpublic information. Designated reviewers must review the existing public content at least every quarter and must remove any nonpublic information they find at once. The System Owner must withdraw the designation of anyone who publishes content without the review.

Related Required Processes #

• Staff use of an internet-based service that keeps no Organization information, such as a search engine or a public social media account, follows “Reviewing External Services” in the System and Services Acquisition policy and procedures. A system that exchanges Organization information needs the agreement this policy requires.

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 plan of action and milestones (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 access control 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 access control 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. Automate joiner-mover-leaver access changes end-to-end from the authoritative HR source, eliminating manual deprovisioning steps.
6. Expand risk-based conditional access signals (device health, behavior analytics) toward continuous, per-session authorization decisions.

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 23-02: Mitigating the Risk from Internet-Exposed Management Interfaces, June 13, 2023.
• CISA BOD 25-01: Implementing Secure Practices for Cloud Services, December 17, 2024.
• CISA High Value Asset (HVA) Control Overlay v1.0, November 1, 2017.
• CISA Zero Trust Maturity Model, April 11, 2023.
• 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.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FIPS 200: Minimum Security Requirements for Federal Information and Information Systems, March 2006.
• FIPS 201-3: Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022.
• Mobile Communications Best Practice Guidance, December 18, 2024.
• 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-46 Rev. 2: Guide to Enterprise Telework, Remote Access, and Bring Your Own Device (BYOD) Security, July 29, 2016.
• 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-63-4: Digital Identity Guidelines, July 31, 2025.
• NIST SP 800-124 Rev. 2: Guidelines for Managing the Security of Mobile Devices in the Enterprise, May 2023.
• NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs), February 2012.
• NIST SP 800-163 Rev. 1: Vetting the Security of Mobile Applications, April 2019.
• 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-19-03: Strengthening the Cybersecurity of Federal Agencies by Enhancing the High Value Asset Program, December 26, 2018.
• OMB M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM), May 21, 2019.
• OMB M-22-09: Moving the U.S. Government Toward Zero Trust Cybersecurity Principles, January 26, 2022.
• OMB M-23-22: Delivering a Digital-First Public Experience, September 22, 2023.