Identification and Authentication 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 identification and authentication 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 how the Organization identifies and authenticates users and devices. Credential theft is the cheapest way for an adversary to gain access, so the federal zero trust strategy requires phishing-resistant multi-factor authentication (OMB M-22-09; NIST SP 800-63). All users must authenticate with Personal Identity Verification (PIV) or an equivalent phishing-resistant authenticator. Privileged access must use hardware-backed authenticators. The Organization must identify every user and device uniquely and must manage each authenticator from issuance through revocation.

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)

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 identification and authentication control in the low baseline of FIPS 200 and NIST SP 800-53B:

• IA-01 — Policy and Procedures
• IA-02 — Identification and Authentication (Organizational Users)
• IA-02(1) — Multi-factor Authentication to Privileged Accounts
• IA-02(12) — Acceptance of PIV Credentials
• IA-02(2) — Multi-factor Authentication to Non-privileged Accounts
• IA-02(8) — Access to Accounts — Replay Resistant
• IA-04 — Identifier Management
• IA-05 — Authenticator Management
• IA-05(1) — Password-based Authentication
• IA-06 — Authentication Feedback
• IA-07 — Cryptographic Module Authentication
• IA-08 — Identification and Authentication (Non-organizational Users)
• IA-08(1) — Acceptance of PIV Credentials from Other Agencies
• IA-08(2) — Acceptance of External Authenticators
• IA-08(4) — Use of Defined Profiles
• IA-11 — Re-authentication

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.
• OMB M-26-18: Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services, August 31, 2026.
• Executive Order 14432: Streamlining Access to Government Services Through America.gov, September 29, 2026.
• FIPS 201-3: Personal Identity Verification (PIV) of Federal Employees and Contractors, January 2022.
• NIST SP 800-63-4: Digital Identity Guidelines, July 31, 2025.

2.1 Derived Governance Requirements #

The requirements below come from federal governance sources and apply to the IA 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 adopt enterprise-wide identity management where every user, service account, and device has a unique identity that is centrally managed and continuously verified. Deadline: FY 2024. (OMB M-22-09, §3(a))

NIST SP 800-63-4: Digital Identity Guidelines

• The organization must implement risk-based identity proofing, authentication, and federation, choosing each assurance level from the system’s digital identity risk assessment. (NIST SP 800-63-4, §3)
• 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))
• The organization should conduct a digital identity risk assessment for each system that authenticates users, and select its identity, authentication, and federation assurance levels from that assessment. (NIST SP 800-63-4, §3)
• The organization should document each system’s selected assurance levels, any tailoring, and the reasons in a Digital Identity Acceptance Statement. (NIST SP 800-63-4, §3.4)

FIPS 201: Personal Identity Verification of Federal Employees and Contractors

• The organization must issue PIV credentials to all employees and contractors requiring physical or logical access to federally controlled facilities and information systems. PIV credentials must be used for authentication to federal systems. (FIPS 201-3, §2)

FedRAMP CR26: FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators)

• The organization must set account and authentication settings in each FedRAMP authorized cloud service as the provider’s Secure Configuration Guide directs. (FedRAMP Consolidated Rules for 2026, AGU-USE-RSG)

OMB M-26-18: Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services

• The organization must report to OMB an inventory of all existing public-facing websites that require users to sign in. Deadline: 2026-10-30 (60 days after 2026-08-31). (OMB M-26-18)
• The organization must conduct a digital identity risk assessment for each public-facing service that signs users in or verifies their identity, and select its assurance levels, using the process in NIST SP 800-63-4. Deadline: 2027-04-28 (240 days after 2026-08-31). (OMB M-26-18; NIST SP 800-63-4)
• The organization must use Login.gov to sign in members of the public on every in-scope public-facing website, or send OMB the notice the memo describes, and use Login.gov’s identity verification service unless it does not meet the service’s needs. Deadline: 2027-08-31 for High Impact Service Provider websites; 2028-08-31 for all in-scope websites. (OMB M-26-18)

OMB M-19-17: Enabling Mission Delivery through Improved Identity, Credential, and Access Management (ICAM)

• The organization must designate an integrated agency-wide identity, credential, and access management (ICAM) office, team, or other governance structure to govern and enforce ICAM efforts. (OMB M-19-17, §IV Governance 1)
• The organization must require PIV credentials as the primary means for employees and contractors to authenticate to federal information systems and enter federally controlled facilities. (OMB M-19-17, §III)
• The organization must build digital identity risk management under NIST SP 800-63 into existing processes, selecting assurance levels that match the risk to each digital service. (OMB M-19-17, §IV Governance 4)

HSPD-12: Homeland Security Presidential Directive 12: Policy for a Common Identification Standard for Federal Employees and Contractors

• The organization must require a common, secure, and reliable form of identification that meets FIPS 201 for employees and contractors who access federally controlled facilities and information systems. (HSPD-12; FIPS 201-3)

EO 14432: Streamlining Access to Government Services Through America.gov

• The organization must identify the Organization’s covered public services, connect them to America.gov securely, and finish their Login.gov sign-in integration as OMB M-26-18 requires. Deadline: On the schedule in OMB’s implementation memorandum, due by 2026-12-28. (EO 14432, §5(b); OMB M-26-18)

CISA Zero Trust Maturity Model v2.0

• The organization should reach Advanced identity maturity by combining phishing-resistant MFA, device health checks, and behavioral analytics, and move toward continuous, risk-adaptive authentication at Optimal maturity. (CISA ZTMM v2.0, Table 2)

NIST SP 800-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials

• The organization should where a PIV card cannot be used with a mobile device, issue a derived PIV credential on the device based on the user’s PIV card. (NIST SP 800-157)

3. Policy #

The Organization must implement and maintain its identification and authentication controls to meet the following requirements:

IA-01 — Policy and Procedures #

Baselines: Low / Moderate / High 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] identification and authentication 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 identification and authentication policy and the associated identification and authentication controls;

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

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 Organization must keep an identification and authentication policy and the procedures that put it into practice. The policy applies to every system. A System Owner may add system-level direction where a system’s risk requires it. The CISO owns both documents. The CISO develops them, documents them, and distributes them to the Authorizing Official, System Owners, Information System Security Officers (ISSOs), and other stakeholders when they are issued and after every revision. The policy states its purpose and scope, assigns roles and responsibilities, records management’s commitment, and sets expectations for coordination and compliance. It must stay consistent with the laws, executive orders, directives, and standards that apply to the Organization, including the phishing-resistant authentication requirements in OMB M-22-09. The CISO reviews and updates the policy and the procedures every year, and sooner when a change in law or federal direction affects them. The CISO sets the Organization’s ICAM strategy, zero trust maturity targets, and milestones in the Zero Trust and ICAM Implementation Plan (PLAN-ZT-001).

IA-02 — Identification and Authentication (Organizational Users) #

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

Requirement:

Uniquely identify and authenticate organizational users and associate that unique identification with processes acting on behalf of those users.

Implementation guidance:

Every organizational user, employee or contractor, must hold one unique identity that the Organization manages centrally under OMB M-22-09. Users must authenticate with that identity before they receive access. A job or process that runs on a user’s behalf uses that user’s identity. The identity team must not issue shared credentials for interactive use. Anonymous access is limited to the narrow exceptions that each System Security and Privacy Plan (SSPP) documents. PIV credentials issued under Federal Information Processing Standards (FIPS) 201-3 are the primary authenticator for federal systems. The single sign-on (SSO) service and the cloud directory enforce authentication for federated applications, and the on-premises directory enforces it across the Windows domain. System Owners must confirm at provisioning that every account maps to exactly one person. The ISSO must treat a credential that two people use as a security incident.

IA-02(1) — Multi-factor Authentication to Privileged Accounts #

Baselines: Low / Moderate / High

Requirement:

Implement multi-factor authentication for access to privileged accounts.

Implementation guidance:

Every privileged account must authenticate with multi-factor authentication for local, network, and remote access. Privileged users must never sign in with a password alone. The factors must be phishing-resistant PIV or hardware security key credentials, consistent with OMB M-22-09. The identity team must configure cloud directory conditional access and the SSO service authentication policies to block any privileged sign-on that does not present the required factors. The identity team must set the on-premises directory to require the smart card for administrative logons. The CISO must not approve any standing exception to privileged multi-factor authentication.

IA-02(2) — Multi-factor Authentication to Non-privileged Accounts #

Baselines: Low / Moderate / High

Requirement:

Implement multi-factor authentication for access to non-privileged accounts.

Implementation guidance:

All non-privileged accounts must authenticate with multiple factors for local, network, and remote access. The PIV credential is the primary factor, issued under FIPS 201-3 and consistent with the phishing-resistant direction in OMB M-22-09. The SSO service enforces the requirement across federated applications through its adaptive risk policies, and cloud directory conditional access enforces it for cloud services. System Owners must not deploy an application whose authentication path bypasses the enterprise identity providers. Multi-factor authentication applies to every account, not only to administrators.

IA-02(8) — Access to Accounts — Replay Resistant #

Baselines: Low / Moderate / High

Requirement:

Implement replay-resistant authentication mechanisms for access to [Selection (one or more): privileged accounts; non-privileged accounts — to be defined].

Implementation guidance:

Users must authenticate to privileged and non-privileged accounts with replay-resistant mechanisms. Certificate-based PIV and hardware security key authentications complete a fresh cryptographic exchange at every sign-on. The on-premises directory issues Kerberos tickets that expire, so no one can present a ticket a second time. The identity team must configure the SSO service and the cloud directory to reject protocols that pass reusable secrets. The identity team must disable legacy authentication paths that lack replay protection. The CISO must approve the authentication protocols permitted in the enterprise.

IA-02(12) — Acceptance of PIV Credentials #

Baselines: Low / Moderate / High

Requirement:

Accept and electronically verify Personal Identity Verification-compliant credentials.

Implementation guidance:

System Owners must configure their systems to accept PIV credentials and verify them electronically. Verification validates the certificate; reading the card is not enough. The identity team must configure the SSO service, the cloud directory, and the on-premises directory for certificate-based PIV authentication under FIPS 201-3, including derived PIV credentials on approved devices. System Owners must connect new applications to the enterprise identity providers so the applications inherit PIV acceptance. System Owners must not build local logons for those applications.

IA-04 — Identifier Management #

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

Requirement:

Manage system identifiers by: a. Receiving authorization from at a minimum, the ISSO (or similar role within the organization) to assign an individual, group, role, service, or device identifier; b. Selecting an identifier that identifies an individual, group, role, service, or device; c. Assigning the identifier to the intended individual, group, role, service, or device; and d. Preventing reuse of identifiers for at least two (2) years.

Implementation guidance:

The identity team must not assign an identifier without authorization from, at minimum, the System Owner, ISSO, or System Administrator. Each identifier must designate exactly one individual, group, role, service, or device, and it stays with that subject for the life of the account. The identity team must not reassign a retired identifier for at least 2 years, so logs, records, and investigations never point to the wrong party. The SSO service is the authoritative source for user identifiers, and it synchronizes them into the on-premises directory and the cloud directory. The identity team manages service and device identifiers in the same directories under the same authorization rule. The ISSO must audit identifier records for uniqueness and premature reuse.

IA-05 — Authenticator Management #

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

Requirement:

Manage system authenticators by: a. Verifying, as part of the initial authenticator distribution, the identity of the individual, group, role, service, or device receiving the authenticator; b. Establishing initial authenticator content for any authenticators issued by the organization; c. Ensuring that authenticators have sufficient strength of mechanism for their intended use; d. Establishing and implementing administrative procedures for initial authenticator distribution, for lost or compromised or damaged authenticators, and for revoking authenticators; e. Changing default authenticators prior to first use; f. Changing or refreshing authenticators [Assignment: organization-defined time period by authenticator type — to be defined] or when [Assignment: organization-defined events — to be defined] occur; g. Protecting authenticator content from unauthorized disclosure and modification; h. Requiring individuals to take, and having devices implement, specific controls to protect authenticators; and i. Changing authenticators for group or role accounts when membership to those accounts changes.

Implementation guidance:

The Organization manages every authenticator from issuance to revocation. The identity team must verify the recipient’s identity before it issues any authenticator. The identity team must change every default credential before a component enters service. The identity team must change or refresh authenticators [IA-05 parameter 1 — to be defined]. No one has to change a password on a schedule, as NIST SP 800-63B-4 directs; the identity team forces a change instead. The identity team must replace any authenticator immediately when compromise is confirmed or when indicators of compromise suggest it. Users must safeguard the authenticators in their possession, report loss or suspected compromise at once, and never share them. The identity team must revoke an authenticator when the need for it ends. The identity team issues and recovers PIV cards and hardware security keys under FIPS 201-3. Before the service desk resets a password or binds a new authenticator, it must verify the person’s identity. It checks a government-issued photo ID in person or over live video, or uses a phishing-resistant authenticator the person still holds. The service desk must never ask for a password, personal identification number (PIN), or one-time code and must not use knowledge-based questions, as NIST SP 800-63B-4 directs. PIV PIN resets follow FIPS 201-3.

IA-05(1) — Password-based Authentication #

Baselines: Low / Moderate / High

Requirement:

For password-based authentication: (a) Maintain a list of commonly-used, expected, or compromised passwords and update the list [Assignment: organization-defined frequency — to be defined] and when organizational passwords are suspected to have been compromised directly or indirectly; (b) Verify, when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5(1)(a); (c) Transmit passwords only over cryptographically-protected channels; (d) Store passwords using an approved salted key derivation function, preferably using a keyed hash; (e) Require immediate selection of a new password upon account recovery; (f) Allow user selection of long passwords and passphrases, including spaces and all printable characters; (g) Employ automated tools to assist the user in selecting strong password authenticators; and (h) Enforce the following composition and complexity rules: [Assignment: organization-defined composition and complexity rules — to be defined].

Implementation guidance:

Where passwords remain in use, they must be long, screened, and cryptographically protected. Systems must enforce these password rules: [IA-05(1) parameter 2 — to be defined]. Passwords do not expire on a schedule, as NIST SP 800-63B-4 directs. Systems must store and transmit passwords only in cryptographically protected form. Systems must reject any candidate password that appears on the blocklist of commonly used or compromised passwords. The identity team must refresh that blocklist at least every [IA-05(1) parameter 1 — to be defined]. Systems must not offer password hints. The service desk must verify a user’s identity before it resets a password and must not use knowledge-based questions. A temporary password is single-use, and the user must set a permanent password immediately.

IA-06 — Authentication Feedback #

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

Requirement:

Obscure feedback of authentication information during the authentication process to protect the information from possible exploitation and use by unauthorized individuals.

Implementation guidance:

Systems must obscure authentication information as the user enters it, so a person who watches the display sees neither the credential nor its pattern. Systems must return a failure message that does not reveal which part of a failed logon was wrong. System Owners must ensure that every interface, whether workstation, web, or application, masks credential entry and returns a generic failure message. System Owners must not weaken masking for usability without the CISO’s approval. The requirement applies to every interface: a hand-built form meets the same standard as the enterprise sign-on pages.

IA-07 — Cryptographic Module Authentication #

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

Requirement:

Implement mechanisms for authentication to a cryptographic module that meet the requirements of applicable laws, executive orders, directives, policies, regulations, standards, and guidelines for such authentication.

Implementation guidance:

System Owners must ensure that operator authentication to each cryptographic module meets the federal laws, directives, and standards that govern such modules. The mechanism must confirm both the operator’s identity and the role the operator may assume. System Owners must procure and deploy only modules that support compliant operator authentication. Administrators must access modules with individual credentials, using PIV or a hardware security key where the module supports hardware factors, and never with a shared module password. The ISSO must verify module authentication settings at deployment and after any change to the module or its host. A cryptographic module protects keys only while access to the module itself is controlled.

IA-08 — Identification and Authentication (Non-organizational Users) #

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

Requirement:

Uniquely identify and authenticate non-organizational users or processes acting on behalf of non-organizational users.

Implementation guidance:

Non-organizational users, and processes that act on their behalf, must identify and authenticate themselves uniquely before they access a system. The only exceptions are the narrow public-access cases that each System Security and Privacy Plan (SSPP) documents. External access must go through the enterprise identity providers, the SSO service and the cloud directory. System Owners must not set up local account stores for individual applications. System Owners must select the assurance level for external access from the risk of the transaction, under NIST SP 800-63-4. A system assessed under the earlier revision of NIST SP 800-63 must move to NIST SP 800-63-4 at its next reassessment or major change. The ISSO must confirm external authentication paths during assessment. The identity team closes any external identity that it cannot attribute to a person.

IA-08(1) — Acceptance of PIV Credentials from Other Agencies #

Baselines: Low / Moderate / High

Requirement:

Accept and electronically verify Personal Identity Verification-compliant credentials from other federal agencies.

Implementation guidance:

Systems must accept PIV credentials that other federal agencies issued and verify them electronically before they grant access. Verification means full certificate validation, not visual inspection of the card. The identity team must maintain the federation and trust configuration in the SSO service and the cloud directory that makes inter-agency PIV authentication work. System Owners must not create separate local accounts for federal visitors whose PIV credential the Organization can trust instead.

IA-08(2) — Acceptance of External Authenticators #

Baselines: Low / Moderate / High

Requirement:

1. Accept only external authenticators that are NIST-compliant; and
2. Document and maintain a list of accepted external authenticators.

Implementation guidance:

Systems that serve non-organizational users must accept only external authenticators that conform to NIST requirements. The identity team must document and maintain the list of accepted external authenticators, and it must add an entry only after it confirms conformance. System Owners must configure public-facing services to accept the listed authenticators and nothing else. The CISO must approve every addition to and removal from the list.

IA-08(4) — Use of Defined Profiles #

Baselines: Low / Moderate / High

Requirement:

Conform to the following profiles for identity management [Assignment: organization-defined identity management profiles — to be defined].

Implementation guidance:

The identity team must manage identities for non-organizational users under Federal Identity, Credential, and Access Management (FICAM)-issued profiles and United States Government (USG) guidance for PIV and user security group definitions. The identity team must implement federation in the SSO service and the cloud directory to those profiles. The identity team must not accept custom integration patterns that depart from the profiles. The CISO must decide on any proposed deviation before anyone deploys it. A deviation without a CISO decision does not go into production.

IA-11 — Re-authentication #

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

Requirement:

Require users to re-authenticate when [Assignment: organization-defined circumstances or situations — to be defined].

Implementation guidance:

Users must re-authenticate when a session or connection ends, when a virtual private network (VPN) disconnects, and at device lock. Users must re-authenticate when an application session closes or times out for idleness. Users must also re-authenticate when their role changes, when an authenticator or credential is replaced, or when a system’s security category changes. Users must re-authenticate before they run privileged functions. Users must also re-authenticate when a session reaches the limit for the system’s authentication assurance level (AAL). Those are the reauthentication limits in NIST SP 800-63B-4. At level 1 (AAL1), the limit is 30 days. At level 2 (AAL2), it is 24 hours in total or 1 hour of inactivity. At level 3 (AAL3), it is 12 hours in total or 15 minutes of inactivity. The identity team must implement these triggers in the SSO service and the cloud directory session policies and in the on-premises directory logon enforcement. System Owners must confirm that the session settings of their applications match this policy.

PIV Credential Life Cycle and Digital Identity Acceptance #

Each employee and contractor who needs routine access to federal facilities or systems receives a Personal Identity Verification (PIV) card under FIPS 201-3. Each system that authenticates users has a Digital Identity Acceptance Statement under NIST SP 800-63-4.

• A sponsor, a PIV registrar, and a PIV issuer must each act on a PIV card application. No one may fill more than one of these roles for the same applicant.
• The PIV issuer must not issue a card until the Federal Bureau of Investigation (FBI) fingerprint check is favorable and the background investigation has started.
• The PIV issuer must verify the cardholder’s identity by a fingerprint match before resetting a PIN.
• When a cardholder separates or no longer needs the card, the supervisor or the Contracting Officer’s Representative must collect it.
• The PIV issuer must revoke the certificates on each collected, lost, or stolen card and destroy each collected card.
• The System Owner must complete a Digital Identity Acceptance Statement for each system that authenticates users. The statement records the identity, authentication, and federation assurance levels and any compensating controls.
• The Authorizing Official must approve each statement. The System Owner must update it when the system, its users, or its data change.

Source: FIPS 201-3, Personal Identity Verification (PIV) of Federal Employees and Contractors (January 2022), section 2; HSPD-12; NIST SP 800-63-4, Digital Identity Guidelines (2025).

Protecting Tokens and Assertions #

Single sign-on and cloud services pass sign-in proof between systems as identity assertions and access tokens. An attacker who forges or steals one can act as the user without a password. These rules adopt the agency recommendations in NIST IR 8587.

• Before a system relies on a cloud identity provider or token service, the ISSO must confirm what the provider lets the Organization configure: token lifetimes, revocation, audience checks, and token logs. The ISSO records the split of duties in the SSPP.
• The identity team must set access tokens and identity tokens to last no longer than one hour. The Authorizing Official may approve a longer period only with compensating controls, such as tokens bound to the user’s device.
• The identity team must set refresh tokens to end no later than the reauthentication time NIST SP 800-63B-4 sets for the system’s authentication assurance level.
• System Owners must make each system reject a token with a missing or wrong audience. The Security Operations Center (SOC) must receive an alert each time a system rejects one.
• System Owners must use the provider’s token and session revocation, including shared revocation signals where the provider offers them, so that a disabled account loses access at once.
• Developers and administrators must never write tokens, assertions, or the personal information in them to logs, code repositories, or build pipelines. Pipelines must get secrets only from the approved secrets store.
• Each service account and automated process must use short-lived tokens that the enterprise identity platform issues, scoped to the least access it needs.
• System Owners must send token issuance, use, and revocation events to the security information and event management (SIEM) system, and the SOC must review them for signs of token theft or misuse.

Source: NIST IR 8587, Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers (NIST and CISA, September 2026), sections 1.5, 1.6, and 5.3; NIST SP 800-63B-4; NIST SP 800-53 IA-05, IA-11, AC-12, AU-02, SC-23.

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 identification and authentication 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 identification and authentication 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. Complete migration to passwordless, phishing-resistant authentication for the entire workforce.
6. Automate credential lifecycle for non-person entities with short-lived, machine-issued credentials replacing static secrets.

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 Zero Trust Maturity Model, April 11, 2023.
• Executive Order 13800: Strengthening the Cybersecurity of Federal Networks and Critical Infrastructure, May 11, 2017.
• Executive Order 14432: Streamlining Access to Government Services Through America.gov, September 29, 2026.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• 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.
• HSPD-12: Policy for a Common Identification Standard for Federal Employees and Contractors, August 27, 2004.
• NIST Cybersecurity Framework 2.0, February 26, 2024.
• NIST IR 8587: Protecting Tokens and Assertions from Forgery, Theft, and Misuse: Implementation Recommendations for Agencies and Cloud Service Providers, September 15, 2026.
• NIST SP 800-37 Rev. 2: Risk Management Framework for Information Systems and Organizations, December 2018.
• 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-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, December 2014.
• 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-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-26-18: Scaling Use of Login.gov to Deliver a Universal Sign-on for Public Services, August 31, 2026.