Identification and Authentication Procedure

Approval #

Revision History #

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

1. Purpose #

The people named in this procedure use it to carry out the IA control family policy (POL-IA). It covers every control in the identification and authentication family. The steps, the people responsible, and the evidence below show how the Organization meets those National Institute of Standards and Technology (NIST) SP 800-53 Rev. 5 controls. They also support the Inspector General (IG) Federal Information Security Modernization Act (FISMA) reporting metrics.

This general procedure covers every control in the IA family. A system that departs from it, or adds to it, has its own system-specific procedure for those controls.

2. Scope #

This procedure applies to every information system that the Organization operates, or that others operate for it, under the moderate security baseline.

2.1 CSF 2.0 Alignment #

The steps in this procedure support these NIST Cybersecurity Framework (CSF) 2.0 categories:

• PR.AA — Identity Management, Authentication, and Access Control (Protect function)

3. Controls Covered #

This procedure covers the following 27 controls in the IA family:

3.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 that the Procedure section carries out.

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)

4. Procedure #

4.1 General Implementation Approach #

The Organization implements the IA controls in two ways: as organization-wide common controls that systems inherit, and as system-specific implementations where a system needs them. The control-specific procedures below cover each control in the Identification and Authentication family.

The Common Control Provider (CCP) implements controls marked inherited for the whole Organization. The CCP and each System Owner share the work for controls marked hybrid. Each System Owner implements controls marked customer-configured for the system.

Responsible party: The Identity Management Administrator carries out the steps in this procedure unless a control-specific procedure names someone else. The System Owner is accountable for funding and completing the work. The CISO oversees the procedure and receives its performance measures. See the IA policy (POL-IA) for the role definitions.

4.2 Control-Specific Procedures #

IA-01 — Policy and Procedures #

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

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].

Procedure:

The CISO’s office keeps the master copies of POL-IA and PROC-IA and runs their review. The CISO’s office starts a revision every two years. It starts one sooner when an Office of Management and Budget (OMB) memorandum, a Cybersecurity and Infrastructure Security Agency (CISA) directive, or an agency policy changes a requirement in the documents. The assigned author asks System Owners and Information System Security Officers (ISSOs) which procedures are hard to follow and adds any new federal requirements, such as the phishing-resistant authentication rules in OMB M-22-09.

The author sends the draft to the Authorizing Official, System Owners, ISSOs, and other stakeholders for comment. The CISO decides each comment and approves the final text. The CISO’s office publishes the documents in the policy library and sends a distribution notice to everyone on the distribution list. The review record in the document management system shows when the review opened, who commented, and when the CISO approved the revision.

Evidence: the version history of both documents, the comment record with each decision, the approval signature, the distribution notice, and the review record with its dates.

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

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

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

Procedure:

Every identity starts with an approved ticketing system access request in the joiner workflow. The identity team creates one single sign-on (SSO) service identity for one person and synchronizes it to the on-premises directory for domain resources and to the cloud directory for cloud services. The identity team then registers the user’s PIV certificate against that identity, or a hardware security key when PIV issuance is pending. That registration ties authentication to the credential issued under Federal Information Processing Standards (FIPS) 201-3.

At sign-on, the SSO service or the cloud directory authenticates the user before any application session opens. The on-premises directory authenticates domain logons. Batch jobs and service processes run under their own identities, which the directory maps to the team that owns them. They never run under a borrowed user account.

The ISSO reviews authentication records for credentials that resolve to more than one person and opens a security incident for any shared use. Evidence: provisioning tickets, directory exports that map each account to one person, and authentication logs from the SSO service, the cloud directory, and the on-premises directory.

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

Baselines: Low / Moderate / High

Implement multi-factor authentication for access to privileged accounts.

Procedure:

Cloud directory conditional access and the SSO service sign-on policy require multi-factor authentication on every account that holds a privileged role. When a user activates an eligible role through cloud directory privileged identity management, it prompts again for the phishing-resistant factor. The identity team flags domain administrator accounts in the on-premises directory as smart-card-required, so only a PIV card or a hardware security key can open an administrative logon. The identity team exports the policy configurations after each change. Sign-in logs record the factors presented at every privileged authentication. The ISSO reviews denied privileged sign-ins for probing attempts. Evidence: the policy configuration exports and the sign-in logs that record the factors presented at each privileged authentication.

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

Baselines: Low / Moderate / High

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

Procedure:

The SSO service’s global sign-on policy requires a second factor on every workforce authentication. When its adaptive risk engine scores a sign-in as anomalous, the SSO service raises the challenge strength. Cloud directory conditional access applies the matching rule to cloud sessions. Users authenticate with PIV at the desktop, and every application authenticates users through single sign-on, so no application accepts a password alone. When the ISSO finds an application that accepts single-factor logons, the ISSO opens a ticketing system remediation ticket to bring it behind the identity providers. Evidence: policy exports and sign-in logs that record the factors satisfied at each authentication.

IA-02(5) — Individual Authentication with Group Authentication #

Baselines: Moderate / High

When shared accounts or authenticators are employed, require users to be individually authenticated before granting access to the shared accounts or resources.

Procedure:

Shared accounts are reachable only from an authenticated session. The user signs in with their own PIV-backed identity through the SSO service, the cloud directory, or the on-premises directory, and only then can the user open the shared account or resource. Directory logs tie each shared-account session to the individual sign-on that came before it. During account reviews, the ISSO confirms that this tie holds for every shared account the System Security and Privacy Plan (SSPP) justifies. Evidence: the SSPP shared-account justifications, authentication logs that pair individual and shared-account sessions, and the account review records.

IA-02(6) — Access to Accounts —separate Device #

Baselines: Moderate / High

Implement multi-factor authentication for local, network and remote access to privileged accounts; non-privileged accounts such that: (a) One of the factors is provided by a device separate from the system gaining access; and (b) The device meets FIPS-validated or NSA-approved cryptography.

Procedure:

Privileged and remote users carry their second factor on a PIV card or a hardware security key. The identity team issues each hardware security key and records its serial number against the user in the enrollment record. The SSO service and the cloud directory authentication policies restrict these access paths to hardware-backed factor types, so they refuse a sign-in that presents only software-held credentials. The ISSO checks factor enrollments whenever privileged access is granted or reviewed. Evidence: enrollment records, policy configuration exports, and sign-in logs that show the factor category presented at each authentication.

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

Baselines: Low / Moderate / High

Implement replay-resistant authentication mechanisms for access to privileged accounts; non-privileged accounts.

Procedure:

The identity team maintains the approved protocol set: PIV certificate and hardware security key authentication through the SSO service and the cloud directory, and Kerberos within the on-premises directory domain. The identity team disables legacy protocols that transmit reusable secrets in the directory and identity provider configurations, and it keeps a configuration export after each change. Sign-in logs identify the protocol used for each authentication. The ISSO watches for fallback to a non-approved protocol and opens a ticketing system ticket to correct the configuration when one appears. Evidence: the approved protocol set, the configuration exports, the sign-in logs, and the correction tickets.

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

Baselines: Low / Moderate / High

Accept and electronically verify Personal Identity Verification-compliant credentials.

Procedure:

The on-premises directory smart card logon validates the PIV certificate at the domain. The SSO service and the cloud directory validate PIV certificates for federated applications and check validity and revocation before a session opens. When an application onboards to single sign-on, the identity team confirms that PIV authentication works for that application and records the test in the onboarding ticket. Evidence: identity provider configuration exports that show certificate-based authentication enabled, the onboarding tickets, and sign-in logs that record PIV authentications.

IA-03 — Device Identification and Authentication #

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

Uniquely identify and authenticate [Assignment: organization-defined devices and/or types of devices — to be defined] before establishing a [Selection (one or more): local; remote; network — to be defined] connection.

Procedure:

Each System Owner records in the System Security and Privacy Plan (SSPP) the device types that must authenticate and the mechanism assigned to each. Windows systems join the on-premises directory domain and authenticate with their machine accounts through Kerberos before domain resources open. Devices that connect to cloud services register with the cloud directory. Conditional access evaluates the device identity at connection time and blocks devices that have none.

The identity team reconciles the machine account and device registration populations against the expected assets, clears stale entries, and records the cleanup in the ticketing system. When a new device class enters service, the System Owner updates the SSPP, and the identity team configures its authentication path before deployment.

Evidence: the SSPP device authentication definitions, machine account and device registration exports, conditional access policy exports, and connection logs that show unauthenticated devices refused.

IA-04 — Identifier Management #

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

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.

Procedure:

Identifier assignment starts with a ticketing system access request. The System Owner, ISSO, or System Administrator authorizes the assignment, and the identity team creates the identifier in the SSO service. The SSO service provisions the matching account names into the on-premises directory and the cloud directory. The identity team creates service and device identifiers in the directories under the same authorization step and names them for the owning team or asset.

When the identity team deprovisions an account, it retires the identifier instead of deleting it. The identity team disables the directory record and holds it so no one can reissue the name for at least 2 years. Before any new assignment, the identity team checks candidate identifiers against the retired set.

Evidence: authorization tickets, provisioning logs, the directory export that maps each identifier to its subject, and the retirement register with hold dates.

IA-04(4) — Identify User Status #

Baselines: Moderate / High

Manage individual identifiers by uniquely identifying each individual as contractors; foreign nationals.

Procedure:

The access request that creates an identity records the person’s status. The identity team sets the matching attribute in the SSO service: Federal, Contractor, or Non-Organizational at minimum. The SSO service synchronizes the attribute to the on-premises directory and the cloud directory, where it appears in directory attributes and display names. When a mover event occurs, such as a contractor who converts to federal service, the identity team updates the attribute through the same workflow that adjusts access. Evidence: the provisioning ticket that records status, directory exports of the status attribute, and the mover tickets behind each correction.

IA-05 — Authenticator Management #

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

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.

Procedure:

Issuance starts with identity verification. The enrollment record ties the PIV card or hardware security key serial number to a verified person. Initial passwords are temporary secrets that force a change at first use. Administrators change or disable default credentials during system build, and the build checklist records this before the ISSO accepts the system.

Password policy in the SSO service and the on-premises directory sets no expiration date. The identity team tracks the expiration dates of PIV cards and other certificates and reissues each one before it lapses. [IA-05 parameter 1 — to be defined], the identity team rotates service-account passwords, application programming interface (API) keys, and other shared secrets. The team records each rotation in the ticketing system. When monitoring or a user report points to compromise, or a person leaves a group that shares a credential, the identity team revokes and reissues the authenticator immediately. The team records the action in the ticketing system.

When a user asks for a password reset or a new authenticator, the service desk first verifies the user’s identity. It checks a government-issued photo ID in person or over live video, or confirms the request through a phishing-resistant authenticator the user still holds. It never asks for a password, personal identification number (PIN), or one-time code and does not use knowledge-based questions. The service desk records the verification method in the ticketing system ticket.

Users report lost or stolen authenticators to the service desk without delay. In the leaver workflow, the identity team recovers PIV cards and hardware security keys and disables the associated credentials at separation.

Evidence: enrollment and issuance records, identity verification records in reset tickets, build checklists that show defaults removed, policy exports that show the password and secret rules, shared-secret rotation records, revocation tickets, and separation recovery records.

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

Baselines: Low / Moderate / High

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].

Procedure:

Password policy in group policy and the SSO service enforces these rules: [IA-05(1) parameter 2 — to be defined]. Neither policy sets an expiration date or a character-class rule. The identity team maintains the compromised-password blocklist in the identity providers, refreshes it at least every [IA-05(1) parameter 1 — to be defined], and records each update. Password stores hold only salted cryptographic hashes. Before the service desk resets a password, it verifies the user’s identity against a government-issued photo ID, in person or over live video, or through a phishing-resistant authenticator the user still holds. It never uses knowledge-based questions. It then issues a temporary password that forces a permanent change at first logon.

Evidence: policy configuration exports, blocklist update records, and the reset tickets with the identity verification method.

IA-05(2) — Public Key-based Authentication #

Baselines: Moderate / High

1. For public key-based authentication:

1. Enforce authorized access to the corresponding private key; and
2. Map the authenticated identity to the account of the individual or group; and

2. When public key infrastructure (PKI) is used:

1. Validate certificates by constructing and verifying a certification path to an accepted trust anchor, including checking certificate status information; and
2. Implement a local cache of revocation data to support path discovery and validation.

Procedure:

The on-premises directory, the SSO service, and the cloud directory validate the full certification path for every certificate authentication and check revocation before the session opens. Domain controllers cache revocation data locally, so sign-on continues during an outage of the revocation service. The identity team maintains the mapping from each certificate to its account in the directory under the same authorization as any identifier. Private keys stay on the PIV card or hardware security key, and no one exports them. Evidence: configuration exports that show path validation and revocation checking, the certificate-to-account mapping records, and authentication logs.

IA-05(6) — Protection of Authenticators #

Baselines: Moderate / High

Protect authenticators commensurate with the security category of the information to which use of the authenticator permits access.

Procedure:

During categorization, the System Owner sets the security category that governs each system’s authenticators. The System Owner records it in the System Security and Privacy Plan (SSPP). The identity team matches issuance to that category. Privileged and high-category access gets hardware factors, and credential material stays only in the protected identity stores in the SSO service, the cloud directory, and the on-premises directory. When a system’s categorization changes, the ISSO re-checks whether its authenticator types still meet the requirement. The ISSO opens a ticketing system ticket for any upgrade. Evidence: SSPP categorization entries, issuance records by factor type, and the upgrade tickets.

IA-05(7) — No Embedded Unencrypted Static Authenticators #

Baselines: Moderate / High

Ensure that unencrypted static authenticators are not embedded in applications or other forms of static storage.

Procedure:

Before an application or script deploys, the owning team reviews it for embedded credentials. The System Owner’s deployment attestation in the ticketing system records the check. Anyone may find a plaintext credential embedded in code, whether in review, in audit, or in operation. When that happens, the ISSO directs the owning team to rotate the credential immediately and to correct the code to obtain its secret at runtime. The ISSO records the event as a suspected compromise. Evidence: deployment attestations, rotation tickets, and the correction record for each finding.

IA-06 — Authentication Feedback #

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

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

Procedure:

Credential fields mask input by default across the enterprise. The Windows logon inherits this behavior from platform policy, and applications behind the SSO service and the cloud directory show the identity providers’ sign-in pages instead of home-built forms. Failed logons return one generic message, and the system writes the detailed cause to logs that only administrators read.

When an application onboards to single sign-on, the onboarding check includes masked entry and generic failure responses, and the onboarding ticket records the result. The ISSO reviews individually, before deployment, any interface that cannot use the enterprise sign-on. An assessment may find a deviation in an interface. The owning team then records the deviation in a ticketing system ticket and corrects it.

Evidence: onboarding check records, the ISSO’s interface reviews, and correction tickets.

IA-07 — Cryptographic Module Authentication #

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

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.

Procedure:

When a component that contains a cryptographic module enters service, the build record documents how operator authentication to the module is configured and which roles each operator may assume. Administrators authenticate to modules individually, with PIV or hardware security key factors where the module supports them. Role assignments within the module match the duties recorded in the build documentation.

The ISSO reviews the module authentication configuration during system acceptance and re-checks it when the module or its host changes. The ISSO records the results in the acceptance record. When anyone discovers configuration drift later, the owning administrator records it in a ticketing system ticket and corrects it.

Evidence: build records, module configuration exports, acceptance sign-offs, and the correction tickets.

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

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

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

Procedure:

Every external user has a sponsor. The System Owner authorizes the access, and the identity team provisions an external identity in the SSO service or the cloud directory, separate from workforce accounts and marked non-organizational. External users authenticate through the same identity providers as the workforce, at the assurance level the System Owner selected for the transaction risk under NIST SP 800-63-4.

The System Owner documents in the System Security and Privacy Plan (SSPP) any content the public may reach without identification, so every unauthenticated path is a recorded decision. During account reviews, sponsors re-confirm the continued need for their external accounts, and the identity team disables any account a sponsor does not confirm.

Evidence: sponsorship tickets, the external identity register, sign-in logs, and the review records with disablements.

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

Baselines: Low / Moderate / High

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

Procedure:

The SSO service and the cloud directory trust the federal PKI chain for PIV certificates that other agencies issued. At sign-on, the identity providers validate the certificate path and revocation status exactly as they do for PIV credentials the Organization issued. The identity team keeps the trust configuration under change control and exports it after each change. Access still requires sponsorship: the ticketing system request records the sponsoring System Owner, and the visitor authenticates with their home-agency credential. Evidence: trust configuration exports, sponsorship tickets, and sign-in logs that record inter-agency PIV authentications.

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

Baselines: Low / Moderate / High

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

Procedure:

The identity team maintains the accepted external authenticator list. For each entry, it records the conformance basis and the CISO’s approval. The identity team keeps the list under version control and reviews it when a candidate arrives or federal guidance changes. The SSO service and the cloud directory configurations for public-facing services permit only the listed authenticator types, and the identity team exports the configuration after each change. Evidence: the versioned list with approvals and the identity provider configuration exports.

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

Baselines: Low / Moderate / High

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

Procedure:

When the identity team builds an external identity integration, it maps the configuration to the applicable Federal Identity, Credential, and Access Management (FICAM)-issued profile and records the mapping in the integration’s design record. The SSO service and the cloud directory federation settings implement the profile, and the identity team keeps the configuration export after each change. The identity team sends any proposed departure from a profile to the CISO for decision before deployment and files the decision with the design record. Evidence: design records with profile mappings, configuration exports, and the CISO decision records.

IA-11 — Re-authentication #

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

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

Procedure:

The SSO service and the cloud directory session policies enforce the session length and idle timeout for each system’s authentication assurance level (AAL), as recorded in its System Security and Privacy Plan (SSPP). An expired or idle session then presents a fresh sign-in instead of resuming. Device lock and virtual private network (VPN) reconnection require credentials again by configuration. When a user activates a privileged role through cloud directory privileged identity management, the user must authenticate again, so privileged work always follows a fresh factor.

When a user’s role, credential, or authenticator changes, the identity team revokes the user’s active sessions, so the next action requires re-authentication under the new state. The identity team links the revocation to the change ticket that caused it.

Evidence: session policy exports mapped to each system’s AAL, sign-in logs that show re-authentication events, and session revocation records linked to their change tickets.

IA-12 — Identity Proofing #

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

1. Identity proof users that require accounts for logical access to systems based on appropriate identity assurance level requirements as specified in applicable standards and guidelines;
2. Resolve user identities to a unique individual; and
3. Collect, validate, and verify identity evidence.

Procedure:

Proofing happens at enrollment, before an identity exists in the SSO service. The applicant presents identity evidence. The enrollment official checks that the evidence is genuine and current, verifies that it belongs to the person who presents it, and resolves the applicant against existing records so no person holds two workforce identities. The assurance level follows the risk of the access sought, under NIST SP 800-63-4.

The enrollment official handles evidence that contains personally identifiable information (PII) under the Senior Agency Official for Privacy (SAOP)’s direction and keeps it only as long as the enrollment record requires. Once proofing is complete, the identity team creates the identity through the provisioning workflow and issues credentials against it.

Evidence: the enrollment record, which lists the evidence types examined, the validation and verification methods, the assurance level applied, and the official who performed the steps, retained with the issuance record.

IA-12(2) — Identity Evidence #

Baselines: Moderate / High

Require evidence of individual identification be presented to the registration authority.

Procedure:

At enrollment, the registration authority takes the applicant’s identity evidence and records the types presented. The registration authority stops the process when evidence is absent or weaker than the requested access demands. The evidence record goes into the enrollment file, and the registration authority records each refusal with its reason. The ISSO samples enrollment records to confirm that applicants presented evidence and that it matched the access risk. Evidence: enrollment files with evidence records, refusal records, and the sampling results.

IA-12(3) — Identity Evidence Validation and Verification #

Baselines: Moderate / High

Require that the presented identity evidence be validated and verified through [Assignment: organization-defined methods of validation and verification — to be defined].

Procedure:

The registration authority validates each piece of evidence to confirm that it is genuine, current, and tied to a real identity. The registration authority then verifies the link to the person who presents it, using the FICAM-approved methods. Those methods are automated enrollment service validation where available, otherwise human review with attestation, and always a check against approved identity sources. The registration authority writes the method and outcome into the enrollment record. The ISSO samples records to confirm that the registration authority used approved methods. Evidence: enrollment records that name the method and outcome, and the sampling results.

IA-12(5) — Address Confirmation #

Baselines: Moderate / High

Require that a [Selection: registration code; notice of proofing — to be defined] be delivered through an out-of-band channel to verify the users address (physical or digital) of record.

Procedure:

When an applicant enrolls, registration authority staff pull the address of record, postal or digital, and send a registration code through that separate channel. The applicant returns the code to finish enrollment. When a code does not come back, the staff leave the enrollment incomplete and flag it for follow-up before any retry. The enrollment record captures the channel used, the delivery, and the returned-code confirmation. Evidence: enrollment records with delivery and confirmation entries, and the follow-up records for failed confirmations.

4.3 PIV Credential Life Cycle and Digital Identity Acceptance #

These steps follow a PIV card from request to destruction, as FIPS 201-3 describes. The last step records each system’s digital identity choices under NIST SP 800-63-4.

Step 1: Sponsor and enroll #

Confirm the need and the person’s identity.

Step 2: Issue the card #

Issue only after the checks are complete.

Step 3: Maintain the card #

Keep the card and its data current.

Step 4: Revoke and destroy #

End the credential when the need ends.

Step 5: Accept digital identity for each system #

Record how strongly each system proves and checks identity.

Evidence: the sponsorship, enrollment, fingerprint check, issuance, reset, collection, and destruction records, and each approved Digital Identity Acceptance Statement in the governance, risk, and compliance (GRC) system.

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).

4.4 Protecting Tokens and Assertions #

These steps apply to each system that uses single sign-on, federation, or a cloud identity provider. They carry out the agency recommendations in NIST IR 8587.

Step 1: Confirm what the provider supports #

Know which token protections the Organization controls before the system goes live.

Step 2: Configure tokens #

Limit how long and where a stolen token works.

Step 3: Monitor and respond #

Find token misuse quickly.

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.

5. Parameters (ODP Values) #

The following organization-defined parameters apply to controls in this family:

6. Evidence Artifacts #

Carrying out this procedure produces these records:

• Authentication system configuration
• multi-factor authentication (MFA) enrollment reports
• Password/credential policy documentation
• Credential inventory
• Evidence for IG FISMA metric IDAM.17
• Evidence for IG FISMA metric IDAM.18
• Evidence for IG FISMA metric IDAM.19
• Evidence for IG FISMA metric IDAM.20

7. Performance Measurement #

The CISO measures this procedure with the indicators below, which meet IG FISMA Level 4 (Managed and Measurable). The ISSO collects the data, and the CISO trends and reports it. When a measure moves away from its target, the CISO starts corrective action through the plan of action and milestones (POA&M) process.

8. Training Requirements #

Before they carry out the steps in this procedure, and every year after, the people who perform them must complete:

• General security awareness training, which all personnel take under POL-AT.
• Role-based training on this procedure’s steps, tools, and evidence.
• Training on the technology platforms listed under Technology Implementation, matched to their duties.

Completion is a condition of continued access. The Agency Learning Management System (LMS) holds the completion records.

9. Governance References #

• OMB Circular A-130: Managing Information as a Strategic Resource, July 28, 2016.
• 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.
• Federal Information Security Modernization Act of 2014 (44 U.S.C. § 3551 et seq.), December 18, 2014.
• 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.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations, September 2020.
• NIST SP 800-63-4: Digital Identity Guidelines, July 31, 2025.
• CISA Zero Trust Maturity Model, April 11, 2023.
• FedRAMP Consolidated Rules for 2026 (including 20x Key Security Indicators), June 24, 2026.
• 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-157: Guidelines for Derived Personal Identity Verification (PIV) Credentials, December 2014.