How Identity and Access Management Supports NIST SP 800-53 Rev 5

Account Management

a. Define and document the types of accounts allowed and specifically prohibited for use within the system;

b. Assign account managers;

c. Require [Assignment: organization-defined prerequisites and criteria] for group and role membership;

d. 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)] for each account;

e. Require approvals by [Assignment: organization-defined personnel or roles] for requests to create accounts;

f. Create, enable, modify, disable, and remove accounts in accordance with [Assignment: organization-defined policy, procedures, prerequisites, and criteria];

g. Monitor the use of accounts;

h. Notify account managers and [Assignment: organization-defined personnel or roles] within:

1. [Assignment: organization-defined time period] when accounts are no longer required;

2. [Assignment: organization-defined time period] when users are terminated or transferred; and

3. [Assignment: organization-defined time period] when system usage or need-to-know changes for an individual;

i. Authorize access to the system based on:

1. A valid access authorization;

2. Intended system usage; and

3. [Assignment: organization-defined attributes (as required)];

j. Review accounts for compliance with account management requirements [Assignment: organization-defined frequency];

k. Establish and implement a process for changing shared or group account authenticators (if deployed) when individuals are removed from the group; and

l. Align account management processes with personnel termination and transfer processes.

In practice: HR events create, change and remove accounts in a lifecycle workflow, every account has a named owner, and managers often review their team's accounts on a quarterly schedule.

Account Management | Automated System Account Management

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

In practice: Connectors create, change and disable accounts directly from the HR record, and a scheduled reconciliation job flags any account that no longer matches its source.

Account Management | Automated Temporary and Emergency Account Management

Automatically [Selection: remove; disable] temporary and emergency accounts after [Assignment: organization-defined time period for each type of account].

In practice: A contractor's temporary account is created with an end date and switches off on that date automatically, so nobody has to remember to remove it.

Account Management | Disable Accounts

Disable accounts within [Assignment: organization-defined time period] 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 [Assignment: organization-defined time period].

In practice: A scheduled job disables accounts that expired or have not signed in for a long stretch, and the few kept on purpose are listed with a reason and an owner.

Account Management | Automated Audit Actions

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

In practice: Every account creation, change, disablement and removal is written to an audit log and sent to the security team's monitoring tool for review.

Account Management | Privileged User Accounts

(a) Establish and administer privileged user accounts in accordance with [Selection: a role-based access scheme; an attribute-based access scheme];

(b) Monitor privileged role or attribute assignments;

(c) Monitor changes to roles or attributes; and

(d) Revoke access when privileged role or attribute assignments are no longer appropriate.

In practice: Administrators use separate admin accounts, hold privileged roles only when needed, and the small group with those roles is reviewed on a regular schedule.

Account Management | Restrictions on Use of Shared and Group Accounts

Only permit the use of shared and group accounts that meet [Assignment: organization-defined conditions for establishing shared and group accounts].

In practice: A shared account turns up in a correlation report, gets a named owner and a written reason, and where allowed, is checked out from a vault so each use traces to one person.

Account Management | Usage Conditions

Enforce [Assignment: organization-defined circumstances and/or usage conditions] for [Assignment: organization-defined system accounts].

In practice: Sign-in rules limit sensitive accounts to approved locations and managed devices, so an administrator account is blocked from an unusual place.

Account Management | Account Monitoring for Atypical Usage

(a) Monitor system accounts for [Assignment: organization-defined atypical usage]; and

(b) Report atypical usage of system accounts to [Assignment: organization-defined personnel or roles].

In practice: Sign-in analytics flag unusual account activity, such as a login from a new country at 3 a.m., and the alert goes to a named team with a defined reporting path.

Account Management | Disable Accounts for High-risk Individuals

Disable accounts of individuals within [Assignment: organization-defined time period] of discovery of [Assignment: organization-defined significant risks].

In practice: When HR or the security team flags a high-risk individual, a fast-track lifecycle action disables their accounts within the time the organization has set.

Access Enforcement

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

In practice: Access to an application comes from group or role membership granted through an approved request, and the sign-in service checks that membership each time someone tries to open it.

Access Enforcement | Role-based Access Control

Enforce a role-based access control policy over defined subjects and objects and control access based upon [Assignment: organization-defined roles and users authorized to assume such roles].

In practice: Teams analyze who holds which access, build a reviewed catalogue of job-based roles, and map each role to the entitlements it grants so access follows the job.

Access Enforcement | Revocation of Access Authorizations

Enforce the revocation of access authorizations resulting from changes to the security attributes of subjects and objects based on [Assignment: organization-defined rules governing the timing of revocations of access authorizations].

In practice: When someone changes jobs or a reviewer says no, the access is removed through the same workflow, and the time between the event and the removal is tracked.

Access Enforcement | Attribute-based Access Control

Enforce attribute-based access control policy over defined subjects and objects and control access based upon [Assignment: organization-defined attributes to assume access permissions].

In practice: HR attributes like department, location and worker type feed dynamic groups, so a nurse and an accountant get different access automatically from their record.

Separation of Duties

a. Identify and document [Assignment: organization-defined duties of individuals requiring separation]; and

b. Define system access authorizations to support separation of duties.

In practice: The business lists conflicting duties, such as creating and paying a vendor, and the request workflow blocks that combination or sends it for exception sign-off with a compensating check.

Least Privilege

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.

In practice: Access is scoped to what each job needs: roles are designed narrowly, managers recertify access on a schedule, and extra rights are granted for a limited time.

Least Privilege | Authorize Access to Security Functions

Authorize access for [Assignment: organization-defined individuals or roles] to:

(a) [Assignment: organization-defined security functions (deployed in hardware, software, and firmware)]; and

(b) [Assignment: organization-defined security-relevant information].

In practice: Rights to change security settings sit in a few named privileged roles, each with an approval step and a short, known list of people who can hold it.

Least Privilege | Non-privileged Access for Nonsecurity Functions

Require that users of system accounts (or roles) with access to [Assignment: organization-defined security functions or security-relevant information] use non-privileged accounts or roles, when accessing nonsecurity functions.

In practice: Administrators read email and browse the web with a normal account, and switch to a separate admin account only when they perform security work.

Least Privilege | Privileged Accounts

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

In practice: Only people in defined roles can hold privileged accounts; the list is tied to job role, and an access review checks that it still matches.

Least Privilege | Privileged Access by Non-organizational Users

Prohibit privileged access to the system by non-organizational users.

In practice: Members of the public who sign in to agency portals are held in a separate account population, policy blocks administrator role assignment to that population, and a review looks for any that were granted by mistake.

Least Privilege | Review of User Privileges

(a) Review [Assignment: organization-defined frequency] the privileges assigned to [Assignment: organization-defined roles or classes of users] to validate the need for such privileges; and

(b) Reassign or remove privileges, if necessary, to correctly reflect organizational mission and business needs.

In practice: Reviewers go through each role's and each person's privileges in a certification campaign, and every keep or remove decision is recorded with the reviewer's name.

Least Privilege | Log Use of Privileged Functions

Log the execution of privileged functions.

In practice: Each time someone activates a privileged role or runs an admin action, the event is logged with the person, the time and the action for later review.

Unsuccessful Logon Attempts

a. Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts by a user during a [Assignment: organization-defined time period]; and

b. Automatically [Selection (one or more): lock the account or node for [Assignment: organization-defined time period]; lock the account or node until released by an administrator; delay next logon prompt per [Assignment: organization-defined delay algorithm]; notify system administrator; take other [Assignment: organization-defined action]] when the maximum number of unsuccessful attempts is exceeded.

In practice: After a set number of wrong passwords, the account locks or slows down, with the limit and timing chosen by the organization and applied in the directory and sign-in service.

Remote Access

a. Establish and document usage restrictions, configuration/connection requirements, and implementation guidance for each type of remote access allowed; and

b. Authorize each type of remote access to the system prior to allowing such connections.

In practice: Remote workers sign in through the identity service with MFA and access rules that check device and location, under a documented remote access policy.

Identification and Authentication (Organizational Users)

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

In practice: Every employee and contractor signs in with their own account through one enterprise identity service, accounts are matched to real people, and MFA is required.

Identification and Authentication (Organizational Users) | Multi-factor Authentication to Privileged Accounts

Implement multi-factor authentication for access to privileged accounts.

In practice: Administrators must use MFA every time they sign in or activate a privileged role, enforced by policy on those roles rather than left to individual choice.

Identification and Authentication (Organizational Users) | Multi-factor Authentication to Non-privileged Accounts

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

In practice: Regular users also go through MFA at sign-in, and a registration report shows who has set up a second factor and who still needs to.

Identification and Authentication (Organizational Users) | Individual Authentication with Group Authentication

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

In practice: When a shared account is allowed, the person first signs in as themselves, then checks the credential out from a vault, so each use traces to one individual.

Identification and Authentication (Organizational Users) | Access to Accounts —separate Device

Implement multi-factor authentication for [Selection (one or more): local; network; remote] access to [Selection (one or more): 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 [Assignment: organization-defined strength of mechanism requirements].

In practice: The second factor lives on a separate device, such as a phone authenticator app, a hardware security key or a passkey stored on that device.

Identification and Authentication (Organizational Users) | Access to Accounts — Replay Resistant

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

In practice: Phishing-resistant methods such as security keys or certificates are used; they are designed so a captured sign-in does not work when replayed by someone else.

Identification and Authentication (Organizational Users) | Single Sign-on

Provide a single sign-on capability for [Assignment: organization-defined system accounts and services].

In practice: Users sign in once and open their business apps without more prompts, because the apps trust the enterprise identity service through standard federation.

Identifier Management

Manage system identifiers by:

a. Receiving authorization from [Assignment: organization-defined personnel or roles] 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 [Assignment: organization-defined time period].

In practice: Managers or HR authorize new accounts, each person gets one unique identifier at hire under a written naming standard, and old identifiers are not reused for the period the organization sets.

Identifier Management | Identify User Status

Manage individual identifiers by uniquely identifying each individual as [Assignment: organization-defined characteristic identifying individual status].

In practice: Each identifier shows whether the person is an employee, contractor or intern, using worker-type and employment-status fields from the HR record.

Authenticator Management

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] or when [Assignment: organization-defined events] 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.

In practice: People register authenticators such as an authenticator app or key through a defined process, shared secrets sit in a vault, and credentials are rotated on a schedule.

Authenticator Management | Password-based Authentication

For password-based authentication:

(a) Maintain a list of commonly-used, expected, or compromised passwords and update the list [Assignment: organization-defined frequency] 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].

In practice: The sign-in service blocks common or leaked passwords and sets minimum length, while service account passwords are kept in a vault and changed regularly.

Authenticator Management | Public Key-based Authentication

(a) 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

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

In practice: Certificates and managed SSH keys can be used to sign in, with the private key kept restricted and each key mapped to one account owner.

Authenticator Management | No Embedded Unencrypted Static Authenticators

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

In practice: Scripts and applications no longer hold passwords in code or config files; the secrets move to a vault or the application uses a workload identity.

Authenticator Management | Federated Credential Management

Use the following external organizations to federate credentials: [Assignment: organization-defined external organizations].

In practice: Two organizations set up a trust between their identity services, so a partner's user can sign in with the credential their own employer issued.

Identification and Authentication (Non-organizational Users)

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

In practice: Partners and guests sign in through external identity federation or a guest policy, so each outside person is still individually identified.

Identification and Authentication (Non-organizational Users) | Acceptance of External Authenticators

(a) Accept only external authenticators that are NIST-compliant; and

(b) Document and maintain a list of accepted external authenticators.

In practice: The organization accepts only outside authenticators that meet NIST guidelines, keeps a written list of them, and limits federation with partner identity services to that list.

Adaptive Authentication

Require individuals accessing the system to employ [Assignment: organization-defined supplemental authentication techniques or mechanisms] under specific [Assignment: organization-defined circumstances or situations].

In practice: Sign-in becomes stricter when something looks risky, such as an unfamiliar country, so the user is asked for an extra step on those attempts only.

Re-authentication

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

In practice: Sensitive actions, such as changing bank details or approving a high-value request, prompt the user to sign in again, and a reauthentication interval policy sets how often.

Identity Proofing

a. 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;

b. Resolve user identities to a unique individual; and

c. Collect, validate, and verify identity evidence.

In practice: New hires have their identity checked during onboarding, including remote checks with verifiable credentials, before an account with real access is issued.

Identity Providers and Authorization Servers

Employ identity providers and authorization servers to manage user, device, and non-person entity (NPE) identities, attributes, and access rights supporting authentication and authorization decisions in accordance with [Assignment: organization-defined identification and authentication policy] using [Assignment: organization-defined mechanisms].

In practice: The organization runs its identity service and authorization server as the trusted source of sign-in, with managed signing keys, set token lifetimes and verified assertions.

Identity Providers and Authorization Servers | Verification of Identity Assertions and Access Tokens

The source and integrity of identity assertions and access tokens are verified before granting access to system and information resources.

In practice: Each application checks that a token's signature is valid, that it was meant for that app and that it has not expired, before letting the person in.

Identity Providers and Authorization Servers | Token Management

In accordance with [Assignment: organization-defined identification and authentication policy], assertions and access tokens are:

(a) generated;

(b) issued;

(c) refreshed;

(d) revoked;

(e) time-restricted; and

(f) audience-restricted.

In practice: Tokens have set lifetimes, can be revoked when a user leaves, and may be tied to a device or session, which limits what a stolen one can do.

Personnel Termination

Upon termination of individual employment:

a. Disable system access within [Assignment: organization-defined time period];

b. Terminate or revoke any authenticators and credentials associated with the individual;

c. Conduct exit interviews that include a discussion of [Assignment: organization-defined information security topics];

d. Retrieve all security-related organizational system-related property; and

e. Retain access to organizational information and systems formerly controlled by terminated individual.

In practice: On the termination date, an HR event disables the person's accounts, removes their access and prompts return of credentials, all within the time the organization has set.

Personnel Termination | Automated Actions

Use [Assignment: organization-defined automated mechanisms] to [Selection (one or more): notify [Assignment: organization-defined personnel or roles] of individual termination actions; disable access to system resources].

In practice: A termination in the HR system automatically starts a workflow that notifies the manager and security team and disables the accounts, with no manual ticket needed.

Personnel Transfer

a. Review and confirm ongoing operational need for current logical and physical access authorizations to systems and facilities when individuals are reassigned or transferred to other positions within the organization;

b. Initiate [Assignment: organization-defined transfer or reassignment actions] within [Assignment: organization-defined time period following the formal transfer action];

c. Modify access authorization as needed to correspond with any changes in operational need due to reassignment or transfer; and

d. Notify [Assignment: organization-defined personnel or roles] within [Assignment: organization-defined time period].

In practice: When someone moves to a new department, a mover workflow asks the manager to confirm which old access is still needed and removes the rest.

Policy and Procedures

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

1. [Selection (one or more): organization-level; mission/business process-level; system-level] access control policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

(b) 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;

b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the access control policy and procedures; and

c. Review and update the current access control:

1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and

2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events].

In practice: The security team writes the access control policy; identity work supplies the inputs, such as account types, who signs off on requests, how often access is reviewed and how exceptions are logged.

Account Management | Inactivity Logout

Require that users log out when [Assignment: organization-defined time period of expected inactivity or description of when to log out].

In practice: Policy tells users to sign out when they expect to be away longer than a set time, and session limits at the sign-in service are kept consistent with that rule.

Account Management | Dynamic Privilege Management

Implement [Assignment: organization-defined dynamic privilege management capabilities].

In practice: Rather than leaving broad rights in place all the time, staff request elevated access for a task and it expires afterward; the security team defines when that applies.

Account Management | Dynamic Account Management

Create, activate, manage, and deactivate [Assignment: organization-defined system accounts] dynamically.

In practice: Accounts for short-lived systems or automated workloads are created when the workload starts and removed when it ends, using the same lifecycle rules as people.

Access Enforcement | Dual Authorization

Enforce dual authorization for [Assignment: organization-defined privileged commands and/or other organization-defined actions].

In practice: For the riskiest actions, a second person must sign off before the elevation or vault check-out goes through, and both names are recorded.

Access Enforcement | Audited Override of Access Control Mechanisms

Employ an audited override of automated access control mechanisms under [Assignment: organization-defined conditions] by [Assignment: organization-defined roles].

In practice: A break-glass account exists for emergencies; every use is alerted on and reviewed afterward by someone other than the person who used it.

Information Flow Enforcement | Domain Authentication

Uniquely identify and authenticate source and destination points by [Selection (one or more): organization, system, application, service, individual] for information transfer.

In practice: When two systems exchange data, each uses its own service identity and certificate so both ends are known; the network and application teams own the flow itself.

Least Privilege | Network Access to Privileged Commands

Authorize network access to [Assignment: organization-defined privileged commands] only for [Assignment: organization-defined compelling operational needs] and document the rationale for such access in the security plan for the system.

In practice: Remote use of powerful commands goes through a brokered session that records who connected and requires a written business reason first.

Least Privilege | Privilege Levels for Code Execution

Prevent the following software from executing at higher privilege levels than users executing the software: [Assignment: organization-defined software].

In practice: The endpoint team decides which software may run with elevated rights; identity roles help by limiting who can request that elevation in the first place.

Least Privilege | Prohibit Non-privileged Users from Executing Privileged Functions

Prevent non-privileged users from executing privileged functions.

In practice: The endpoint team sets elevation rules that stop regular users from running admin functions; identity contributes role design that keeps admin rights out of ordinary roles.

Unsuccessful Logon Attempts | Use of Alternate Authentication Factor

(a) Allow the use of [Assignment: organization-defined authentication factors] that are different from the primary authentication factors after the number of organization-defined consecutive invalid logon attempts have been exceeded; and

(b) Enforce a limit of [Assignment: organization-defined number] consecutive invalid logon attempts through use of the alternative factors by a user during a [Assignment: organization-defined time period].

In practice: After repeated failed attempts, a user may show who they are another way, such as a security key; the allowed methods are set in the authentication policy.

Previous Logon Notification | Notification of Account Changes

Notify the user, upon successful logon, of changes to [Assignment: organization-defined security-related characteristics or parameters of the user’s account] during [Assignment: organization-defined time period].

In practice: When a user's password or sign-in method changes, the identity service sends them an alert, so they can spot a change they did not make.

Concurrent Session Control

Limit the number of concurrent sessions for each [Assignment: organization-defined account and/or account type] to [Assignment: organization-defined number].

In practice: The security team sets how many sessions one account can hold at once; where the sign-in service supports it, extra sessions are limited or ended.

Session Termination

Automatically terminate a user session after [Assignment: organization-defined conditions or trigger events requiring session disconnect].

In practice: Sessions end after conditions the organization sets, such as a maximum length or a revoked sign-in, using session lifetime and token revocation settings.

Session Termination | User-initiated Logouts

Provide a logout capability for user-initiated communications sessions whenever authentication is used to gain access to [Assignment: organization-defined information resources].

In practice: Users have a clear sign out option, and where single sign-on is used, signing out can end the session across connected applications.

Permitted Actions Without Identification or Authentication

a. Identify [Assignment: organization-defined user actions] that can be performed on the system without identification or authentication consistent with organizational mission and business functions; and

b. Document and provide supporting rationale in the security plan for the system, user actions not requiring identification or authentication.

In practice: The application owner lists the few actions anyone may take without signing in, like viewing a public page, and that list is reviewed with the access policy.

Security and Privacy Attributes

a. Provide the means to associate [Assignment: organization-defined types of security and privacy attributes] with [Assignment: organization-defined security and privacy attribute values] for information in storage, in process, and/or in transmission;

b. Ensure that the attribute associations are made and retained with the information;

c. Establish the following permitted security and privacy attributes from the attributes defined in AC-16a for [Assignment: organization-defined systems]: [Assignment: organization-defined security and privacy attributes];

d. Determine the following permitted attribute values or ranges for each of the established attributes: [Assignment: organization-defined attribute values or ranges for established attributes];

e. Audit changes to attributes; and

f. Review [Assignment: organization-defined security and privacy attributes] for applicability [Assignment: organization-defined frequency].

In practice: Data owners define labels such as sensitivity or department, and identity attributes are managed under a standard with a named owner for each attribute.

Security and Privacy Attributes | Attribute Value Changes by Authorized Individuals

Provide authorized individuals (or processes acting on behalf of individuals) the capability to define or change the value of associated security and privacy attributes.

In practice: Only people in defined roles can change the value of a security attribute on a user or resource, and each change is logged and reviewed.

Security and Privacy Attributes | Attribute Configuration by Authorized Individuals

Provide authorized individuals the capability to define or change the type and value of security and privacy attributes available for association with subjects and objects.

In practice: Only named administrators can add or change the types of security attributes that exist, and that small group is part of regular access reviews.

Remote Access | Monitoring and Control

Employ automated mechanisms to monitor and control remote access methods.

In practice: Remote sign-ins are logged and checked against policy; identity tooling provides the sign-in records that the network team's monitoring uses.

Remote Access | Privileged Commands and Access

(a) 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]; and

(b) Document the rationale for remote access in the security plan for the system.

In practice: Admin commands from outside the office run through a brokered session, so the activity is authorized and recorded before it reaches the system.

Remote Access | Disconnect or Disable Access

Provide the capability to disconnect or disable remote access to the system within [Assignment: organization-defined time period].

In practice: When a remote worker leaves or a device is lost, the help desk revokes their sessions and disables the account within the time the organization has set.

Remote Access | Authenticate Remote Commands

Implement [Assignment: organization-defined mechanisms] to authenticate [Assignment: organization-defined remote commands].

In practice: Remote commands carry a signed request from a known workload identity, so the receiving system can check who sent it; the platform team owns the setup.

Wireless Access

a. Establish configuration requirements, connection requirements, and implementation guidance for each type of wireless access; and

b. Authorize each type of wireless access to the system prior to allowing such connections.

In practice: The network team sets wireless rules and authorizes each type of access; identity work supplies the directory-backed or certificate-based sign-in that users and devices use.

Wireless Access | Authentication and Encryption

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

In practice: Laptops and phones join the wireless network with a certificate or directory login, and traffic is encrypted; identity supplies the credentials, and the network team runs the radios.

Access Control for Mobile Devices

a. Establish configuration requirements, connection requirements, and implementation guidance for organization-controlled mobile devices, to include when such devices are outside of controlled areas; and

b. Authorize the connection of mobile devices to organizational systems.

In practice: Phones and tablets must be registered and meet device rules before they can reach company apps; the endpoint team sets the rules, and sign-in policy checks them.

Use of External Systems

a. [Selection (one or more): establish [Assignment: organization-defined terms and conditions]; identify [Assignment: organization-defined controls asserted to be implemented on external systems]], 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

b. Prohibit the use of [Assignment: organizationally-defined types of external systems].

In practice: Policy decides what people may do from partner networks or personal devices, and identity settings control guest users and unmanaged device access to company apps.

Use of External Systems | Non-organizationally Owned Systems — Restricted Use

Restrict the use of non-organizationally owned systems or system components to process, store, or transmit organizational information using [Assignment: organization-defined restrictions].

In practice: From a personal or unmanaged laptop, a user gets limited access, such as browser-only with downloads blocked, based on device-state conditions at sign-in.

Access Control Decisions

[Selection (one or more): establish procedures; implement mechanisms] to ensure [Assignment: organization-defined access control decisions] are applied to each access request prior to access enforcement.

In practice: A central policy decision point in the identity service checks each request's attributes before access is granted; the application owner defines what must be checked.

Access Control Decisions | Transmit Access Authorization Information

Transmit [Assignment: organization-defined access authorization information] using [Assignment: organization-defined controls] to [Assignment: organization-defined systems] that enforce access control decisions.

In practice: After sign-in, the identity service passes signed tokens with the user's roles to the application, which relies on them to decide what the person may open.

Event Logging

a. Identify the types of events that the system is capable of logging in support of the audit function: [Assignment: organization-defined event types that the system is capable of logging];

b. Coordinate the event logging function with other organizational entities requiring audit-related information to guide and inform the selection criteria for events to be logged;

c. Specify the following event types for logging within the system: [Assignment: organization-defined event types (subset of the event types defined in AU-2a.) along with the frequency of (or situation requiring) logging for each identified event type];

d. Provide a rationale for why the event types selected for logging are deemed to be adequate to support after-the-fact investigations of incidents; and

e. Review and update the event types selected for logging [Assignment: organization-defined frequency].

In practice: The security team chooses which events to log; identity contributes sign-ins, authentication method changes, role changes and privileged activations to that list.

Content of Audit Records

Ensure that audit records contain information that establishes the following:

a. What type of event occurred;

b. When the event occurred;

c. Where the event occurred;

d. Source of the event;

e. Outcome of the event; and

f. Identity of any individuals, subjects, or objects/entities associated with the event.

In practice: Each identity log entry shows who did what, when, from where and whether it worked, which helps the security team follow an event.

Audit Record Review, Analysis, and Reporting

a. Review and analyze system audit records [Assignment: organization-defined frequency] for indications of [Assignment: organization-defined inappropriate or unusual activity] and the potential impact of the inappropriate or unusual activity;

b. Report findings to [Assignment: organization-defined personnel or roles]; and

c. Adjust the level of audit record review, analysis, and reporting within the system when there is a change in risk based on law enforcement information, intelligence information, or other credible sources of information.

In practice: The security team reviews logs on a schedule; identity risk detections and SIEM content for sign-ins and privileged activity point reviewers to what to look at.

Protection of Audit Information

a. Protect audit information and audit logging tools from unauthorized access, modification, and deletion; and

b. Alert [Assignment: organization-defined personnel or roles] upon detection of unauthorized access, modification, or deletion of audit information.

In practice: Only a small group can read or manage identity logs, and administrators who run the identity system are kept separate from those who guard its logs.

Audit Record Generation

a. Provide audit record generation capability for the event types the system is capable of auditing as defined in AU-2a on [Assignment: organization-defined system components];

b. Allow [Assignment: organization-defined personnel or roles] to select the event types that are to be logged by specific components of the system; and

c. Generate audit records for the event types defined in AU-2c that include the audit record content defined in AU-3.

In practice: The identity service, governance platform and privileged access vault each have logging turned on, and their records are routed to the central SIEM.

Session Audit

a. Provide and implement the capability for [Assignment: organization-defined users or roles] to [Selection (one or more): record; view; hear; log] the content of a user session under [Assignment: organization-defined circumstances]; and

b. Develop, integrate, and use session auditing activities in consultation with legal counsel and in accordance with applicable laws, executive orders, directives, regulations, policies, standards, and guidelines.

In practice: When someone uses a privileged account, the session can be recorded so an authorized reviewer can replay what was done later.

Policy and Procedures

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

1. [Selection (one or more): organization-level; mission/business process-level; system-level] identification and authentication policy that:

(a) Addresses purpose, scope, roles, responsibilities, management commitment, coordination among organizational entities, and compliance; and

(b) 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;

b. Designate an [Assignment: organization-defined official] to manage the development, documentation, and dissemination of the identification and authentication policy and procedures; and

c. Review and update the current identification and authentication:

1. Policy [Assignment: organization-defined frequency] and following [Assignment: organization-defined events]; and

2. Procedures [Assignment: organization-defined frequency] and following [Assignment: organization-defined events].

In practice: The security team writes the sign-in policy; identity assessment supplies the inputs, such as which authenticators are in use, what assurance level each app needs and what exceptions exist.

Identification and Authentication (Organizational Users) | Acceptance of PIV Credentials

Accept and electronically verify Personal Identity Verification-compliant credentials.

In practice: Where federal-style smart cards are in use, the sign-in service is set up to read and check the card's certificate; the badge office issues the cards.

Identification and Authentication (Organizational Users) | Out-of-band Authentication

Implement the following out-of-band authentication mechanisms under [Assignment: organization-defined conditions]: [Assignment: organization-defined out-of-band authentication].

In practice: A user may confirm a sign-in through a phone notification or call to a registered number, under conditions the organization chooses.

Device Identification and Authentication

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

In practice: Company laptops and devices are registered and carry a certificate, so the network can tell a known device from an unknown one; the endpoint team owns the devices.

Device Identification and Authentication | Cryptographic Bidirectional Authentication

Authenticate [Assignment: organization-defined devices and/or types of devices] before establishing [Selection (one or more): local; remote; network] connection using bidirectional authentication that is cryptographically based.

In practice: A device and the server it connects to each present a certificate and check the other's, so neither side talks to an impostor; identity supports the certificate setup.

Device Identification and Authentication | Device Attestation

Handle device identification and authentication based on attestation by [Assignment: organization-defined configuration management process].

In practice: At sign-in, the identity service checks whether the device's health report comes from the organization's configuration process, and blocks devices that fail.

Identifier Management | Prohibit Account Identifiers as Public Identifiers

Prohibit the use of system account identifiers that are the same as public identifiers for individual accounts.

In practice: A person's login name is kept different from their public email or published name, which is handled in identifier and directory design.

Identifier Management | Dynamic Management

Manage individual identifiers dynamically in accordance with [Assignment: organization-defined dynamic identifier policy].

In practice: Identifiers for short-lived systems or workloads are issued and retired automatically under a dynamic identifier policy the organization sets.

Identifier Management | Cross-organization Management

Coordinate with the following external organizations for cross-organization management of identifiers: [Assignment: organization-defined external organizations].

In practice: When partners need access, the two organizations agree how each other's people are identified, usually set up in federation or external identity configuration.

Identifier Management | Pairwise Pseudonymous Identifiers

Generate pairwise pseudonymous identifiers.

In practice: Some applications see a unique, meaningless identifier for each user instead of a shared one, a pairwise option offered by modern sign-in standards.

Identifier Management | Attribute Maintenance and Protection

Maintain the attributes for each uniquely identified individual, device, or service in [Assignment: organization-defined protected central storage].

In practice: Each person's attributes, such as title and manager, are kept in one protected authoritative source, with named owners and a change process.

Authenticator Management | Change Authenticators Prior to Delivery

Require developers and installers of system components to provide unique authenticators or change default authenticators prior to delivery and installation.

In practice: When a new appliance or platform arrives, the installer changes its default password to a unique one before it goes into service, and the new credential is vaulted.

Authenticator Management | Protection of Authenticators

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

In practice: Credentials are stored in a vault with limited access, and the more sensitive the system they open, the tighter the controls around them.

Authenticator Management | Multiple System Accounts

Implement [Assignment: organization-defined security controls] to manage the risk of compromise due to individuals having accounts on multiple systems.

In practice: People who hold accounts on many systems sign in once through single sign-on or go passwordless, which lowers the number of passwords that can be lost.

Authenticator Management | Dynamic Credential Binding

Bind identities and authenticators dynamically using the following rules: [Assignment: organization-defined binding rules].

In practice: Short-lived workload credentials and device-bound credentials are tied to their owner by defined rules when issued, then expire.

Authenticator Management | Expiration of Cached Authenticators

Prohibit the use of cached authenticators after [Assignment: organization-defined time period].

In practice: Cached credentials stop working after a set time, which token lifetime and session policy settings carry out, limiting how long a stolen cache stays useful.

Authenticator Management | In-person or Trusted External Party Authenticator Issuance

Require that the issuance of [Assignment: organization-defined types of and/or specific authenticators] be conducted [Selection: in person; by a trusted external party] before [Assignment: organization-defined registration authority] with authorization by [Assignment: organization-defined personnel or roles].

In practice: For high-trust credentials like hardware security keys, onboarding includes handing the key over in person or through a trusted third party.

Authenticator Management | Password Managers

(a) Employ [Assignment: organization-defined password managers] to generate and manage passwords; and

(b) Protect the passwords using [Assignment: organization-defined controls].

In practice: Staff use an approved enterprise password manager or vault to create and store passwords, with user guidance on how to use it.

Authentication Feedback

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

In practice: The sign-in page hides what is typed and gives generic error messages, so it does not reveal whether the username or the password was wrong.

Identification and Authentication (Non-organizational Users) | Acceptance of PIV Credentials from Other Agencies

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

In practice: Where agencies share smart cards, the sign-in service trusts their certificates through a configured certificate trust; the card issuer handles the cards.

Identification and Authentication (Non-organizational Users) | Use of Defined Profiles

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

In practice: Federation with outside parties follows a defined profile, so the claims and formats exchanged are the same for each partner.

Identification and Authentication (Non-organizational Users) | Acceptance of PIV-I Credentials

Accept and verify federated or PKI credentials that meet [Assignment: organization-defined policy].

In practice: Certificates issued to affiliated or non-government people are accepted only when they meet the organization's stated policy, using configured certificate trust.

Service Identification and Authentication

Uniquely identify and authenticate [Assignment: organization-defined system services and applications] before establishing communications with devices, users, or other services or applications.

In practice: Applications and services show who they are to each other with workload identities and certificates or tokens before they exchange data.

Identity Proofing | Supervisor Authorization

Require that the registration process to receive an account for logical access includes supervisor or sponsor authorization.

In practice: A new account request includes a manager or sponsor sign-off step in the onboarding workflow, so someone accountable vouches for the person.

Identity Proofing | Identity Evidence

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

In practice: The onboarding procedure states which identity documents the registration team must see, and the verification tool settings reflect that rule.

Identity Proofing | Identity Evidence Validation and Verification

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

In practice: The documents a new hire presents are checked for validity, often through a remote verification service, before the registration team issues the account.

Identity Proofing | Accept Externally-proofed Identities

Accept externally-proofed identities at [Assignment: organization-defined identity assurance level].

In practice: If a trusted outside provider has already verified someone's identity, the organization accepts that result at the assurance level it has chosen, through federation.

Identity Providers and Authorization Servers | Protection of Cryptographic Keys

Cryptographic keys that protect access tokens are generated, managed, and protected from disclosure and misuse.

In practice: The certificates that sign tokens are tracked on a calendar, renewed before expiry and stored in protected key storage, with access limited to a few administrators.

Personnel Screening

a. Screen individuals prior to authorizing access to the system; and

b. Rescreen individuals in accordance with [Assignment: organization-defined conditions requiring rescreening and, where rescreening is so indicated, the frequency of rescreening].

In practice: HR finishes background screening first, and the onboarding workflow holds back the new hire's access until the screening is recorded as complete.

Access Agreements

a. Develop and document access agreements for organizational systems;

b. Review and update the access agreements [Assignment: organization-defined frequency]; and

c. Verify that individuals requiring access to organizational information and systems:

1. Sign appropriate access agreements prior to being granted access; and

2. Re-sign access agreements to maintain access to organizational systems when access agreements have been updated or [Assignment: organization-defined frequency].

In practice: New hires and contractors acknowledge the rules of use during onboarding or when they request access, and the signed acknowledgment is stored with the request.

External Personnel Security

a. Establish personnel security requirements, including security roles and responsibilities for external providers;

b. Require external providers to comply with personnel security policies and procedures established by the organization;

c. Document personnel security requirements;

d. Require external providers to notify [Assignment: organization-defined personnel or roles] of any personnel transfers or terminations of external personnel who possess organizational credentials and/or badges, or who have system privileges within [Assignment: organization-defined time period]; and

e. Monitor provider compliance with personnel security requirements.

In practice: Contractors and vendor staff have a named sponsor and an end date on their accounts, and their access is reviewed on a schedule; HR and procurement set the terms.

Separation of System and User Functionality

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

In practice: Administrators use a separate account and admin portal, kept apart from the ordinary user interface; the platform team designs that separation.

Network Disconnect

Terminate the network connection associated with a communications session at the end of the session or after [Assignment: organization-defined time period] of inactivity.

In practice: Network connections close after a period of inactivity set by the organization, and the identity session timeout is aligned with that period.

Cryptographic Key Establishment and Management

Establish and manage cryptographic keys when cryptography is employed within the system in accordance with the following key management requirements: [Assignment: organization-defined requirements for key generation, distribution, storage, access, and destruction].

In practice: The keys and certificates that sign identity tokens are generated, stored in a protected place and renewed before they expire; the security team owns key policy.

Public Key Infrastructure Certificates

a. Issue public key certificates under an [Assignment: organization-defined certificate policy] or obtain public key certificates from an approved service provider; and

b. Include only approved trust anchors in trust stores or certificate stores managed by the organization.

In practice: Certificates for devices and user sign-in come from an approved certificate authority under the organization's certificate policy, which the security team runs.

Session Authenticity

Protect the authenticity of communications sessions.

In practice: Signed assertions and protected session tokens help show that a session belongs to the user who started it, while the network team secures the connection itself.

Access Enforcement | Mandatory Access Control

Enforce [Assignment: organization-defined mandatory access control policy] over the set of covered subjects and objects specified in the policy, and where the policy:

(a) Is uniformly enforced across the covered subjects and objects within the system;

(b) Specifies that a subject that has been granted access to information is constrained from doing any of the following;

(1) Passing the information to unauthorized subjects or objects;

(2) Granting its privileges to other subjects;

(3) Changing one or more security attributes (specified by the policy) on subjects, objects, the system, or system components;

(4) Choosing the security attributes and attribute values (specified by the policy) to be associated with newly created or modified objects; and

(5) Changing the rules governing access control; and

(c) Specifies that [Assignment: organization-defined subjects] may explicitly be granted [Assignment: organization-defined privileges] such that they are not limited by any defined subset (or all) of the above constraints.

Access Enforcement | Discretionary Access Control

Enforce [Assignment: organization-defined discretionary access control policy] over the set of covered subjects and objects specified in the policy, and where the policy specifies that a subject that has been granted access to information can do one or more of the following:

(a) Pass the information to any other subjects or objects;

(b) Grant its privileges to other subjects;

(c) Change security attributes on subjects, objects, the system, or the system’s components;

(d) Choose the security attributes to be associated with newly created or revised objects; or

(e) Change the rules governing access control.

Access Enforcement | Security-relevant Information

Prevent access to [Assignment: organization-defined security-relevant information] except during secure, non-operable system states.

Access Enforcement | Controlled Release

Release information outside of the system only if:

(a) The receiving [Assignment: organization-defined system or system component] provides [Assignment: organization-defined controls]; and

(b) [Assignment: organization-defined controls] are used to validate the appropriateness of the information designated for release.

Access Enforcement | Restrict Access to Specific Information Types

Restrict access to data repositories containing [Assignment: organization-defined information types].

Access Enforcement | Assert and Enforce Application Access

(a) Require applications to assert, as part of the installation process, the access needed to the following system applications and functions: [Assignment: organization-defined system applications and functions];

(b) Provide an enforcement mechanism to prevent unauthorized access; and

(c) Approve access changes after initial installation of the application.

Access Enforcement | Individual Access

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

Access Enforcement | Discretionary and Mandatory Access Control

(a) Enforce [Assignment: organization-defined mandatory access control policy] over the set of covered subjects and objects specified in the policy; and

(b) Enforce [Assignment: organization-defined discretionary access control policy] over the set of covered subjects and objects specified in the policy.

Information Flow Enforcement

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

Information Flow Enforcement | Object Security and Privacy Attributes

Use [Assignment: organization-defined security and privacy attributes] associated with [Assignment: organization-defined information, source, and destination objects] to enforce [Assignment: organization-defined information flow control policies] as a basis for flow control decisions.

Information Flow Enforcement | Processing Domains

Use protected processing domains to enforce [Assignment: organization-defined information flow control policies] as a basis for flow control decisions.

Information Flow Enforcement | Dynamic Information Flow Control

Enforce [Assignment: organization-defined information flow control policies].

Information Flow Enforcement | Flow Control of Encrypted Information

Prevent encrypted information from bypassing [Assignment: organization-defined information flow control mechanisms] by [Selection (one or more): decrypting the information; blocking the flow of the encrypted information; terminating communications sessions attempting to pass encrypted information; [Assignment: organization-defined procedure or method]].

Information Flow Enforcement | Embedded Data Types

Enforce [Assignment: organization-defined limitations] on embedding data types within other data types.

Information Flow Enforcement | Metadata

Enforce information flow control based on [Assignment: organization-defined metadata].

Information Flow Enforcement | One-way Flow Mechanisms

Enforce one-way information flows through hardware-based flow control mechanisms.

Information Flow Enforcement | Security and Privacy Policy Filters

(a) Enforce information flow control using [Assignment: organization-defined security or privacy policy filters] as a basis for flow control decisions for [Assignment: organization-defined information flows]; and

(b) [Selection (one or more): block; strip; modify; quarantine] data after a filter processing failure in accordance with [Assignment: organization-defined security or privacy policy].

Information Flow Enforcement | Human Reviews

Enforce the use of human reviews for [Assignment: organization-defined information flows] under the following conditions: [Assignment: organization-defined conditions].

Information Flow Enforcement | Enable and Disable Security or Privacy Policy Filters

Provide the capability for privileged administrators to enable and disable [Assignment: organization-defined security or privacy policy filters] under the following conditions: [Assignment: organization-defined conditions].

Information Flow Enforcement | Configuration of Security or Privacy Policy Filters

Provide the capability for privileged administrators to configure [Assignment: organization-defined security or privacy policy filters] to support different security or privacy policies.

Information Flow Enforcement | Data Type Identifiers

When transferring information between different security domains, use [Assignment: organization-defined data type identifiers] to validate data essential for information flow decisions.

Information Flow Enforcement | Decomposition into Policy-relevant Subcomponents

When transferring information between different security domains, decompose information into [Assignment: organization-defined policy-relevant subcomponents] for submission to policy enforcement mechanisms.

Information Flow Enforcement | Security or Privacy Policy Filter Constraints

When transferring information between different security domains, implement [Assignment: organization-defined security or privacy policy filters] requiring fully enumerated formats that restrict data structure and content.

Information Flow Enforcement | Detection of Unsanctioned Information

When transferring information between different security domains, examine the information for the presence of [Assignment: organization-defined unsanctioned information] and prohibit the transfer of such information in accordance with the [Assignment: organization-defined security or privacy policy].

Information Flow Enforcement | Validation of Metadata

When transferring information between different security domains, implement [Assignment: organization-defined security or privacy policy filters] on metadata.

Information Flow Enforcement | Approved Solutions

Employ [Assignment: organization-defined solutions in approved configurations] to control the flow of [Assignment: organization-defined information] across security domains.

Information Flow Enforcement | Physical or Logical Separation of Information Flows

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

Information Flow Enforcement | Access Only

Provide access from a single device to computing platforms, applications, or data residing in multiple different security domains, while preventing information flow between the different security domains.

Information Flow Enforcement | Modify Non-releasable Information

When transferring information between different security domains, modify non-releasable information by implementing [Assignment: organization-defined modification action].

Information Flow Enforcement | Internal Normalized Format

When transferring information between different security domains, parse incoming data into an internal normalized format and regenerate the data to be consistent with its intended specification.

Information Flow Enforcement | Data Sanitization

When transferring information between different security domains, sanitize data to minimize [Selection (one or more): delivery of malicious content, command and control of malicious code, malicious code augmentation, and steganography-encoded data; spillage of sensitive information] in accordance with [Assignment: organization-defined policy].

Information Flow Enforcement | Audit Filtering Actions

When transferring information between different security domains, record and audit content filtering actions and results for the information being filtered.

Information Flow Enforcement | Redundant/Independent Filtering Mechanisms

When transferring information between different security domains, implement content filtering solutions that provide redundant and independent filtering mechanisms for each data type.

Information Flow Enforcement | Linear Filter Pipelines

When transferring information between different security domains, implement a linear content filter pipeline that is enforced with discretionary and mandatory access controls.

Information Flow Enforcement | Filter Orchestration Engines

When transferring information between different security domains, employ content filter orchestration engines to ensure that:

(a) Content filtering mechanisms successfully complete execution without errors; and

(b) Content filtering actions occur in the correct order and comply with [Assignment: organization-defined policy].

Information Flow Enforcement | Filter Mechanisms Using Multiple Processes

When transferring information between different security domains, implement content filtering mechanisms using multiple processes.

Information Flow Enforcement | Failed Content Transfer Prevention

When transferring information between different security domains, prevent the transfer of failed content to the receiving domain.

Information Flow Enforcement | Process Requirements for Information Transfer

When transferring information between different security domains, the process that transfers information between filter pipelines:

(a) Does not filter message content;

(b) Validates filtering metadata;

(c) Ensures the content associated with the filtering metadata has successfully completed filtering; and

(d) Transfers the content to the destination filter pipeline.

Least Privilege | Separate Processing Domains

Provide separate processing domains to enable finer-grained allocation of user privileges.

Unsuccessful Logon Attempts | Purge or Wipe Mobile Device

Purge or wipe information from [Assignment: organization-defined mobile devices] based on [Assignment: organization-defined purging or wiping requirements and techniques] after [Assignment: organization-defined number] consecutive, unsuccessful device logon attempts.

Unsuccessful Logon Attempts | Biometric Attempt Limiting

Limit the number of unsuccessful biometric logon attempts to [Assignment: organization-defined number].

System Use Notification

a. Display [Assignment: organization-defined system use notification message or banner] 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;

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

c. For publicly accessible systems:

1. Display system use information [Assignment: organization-defined conditions], 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.

Previous Logon Notification

Notify the user, upon successful logon to the system, of the date and time of the last logon.

Previous Logon Notification | Unsuccessful Logons

Notify the user, upon successful logon, of the number of unsuccessful logon attempts since the last successful logon.

Previous Logon Notification | Successful and Unsuccessful Logons

Notify the user, upon successful logon, of the number of [Selection: successful logons; unsuccessful logon attempts; both] during [Assignment: organization-defined time period].

Previous Logon Notification | Additional Logon Information

Notify the user, upon successful logon, of the following additional information: [Assignment: organization-defined additional information].

Device Lock

a. Prevent further access to the system by [Selection (one or more): initiating a device lock after [Assignment: organization-defined time period] of inactivity; requiring the user to initiate a device lock before leaving the system unattended]; and

b. Retain the device lock until the user reestablishes access using established identification and authentication procedures.

Device Lock | Pattern-hiding Displays

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

Session Termination | Termination Message

Display an explicit logout message to users indicating the termination of authenticated communications sessions.

Session Termination | Timeout Warning Message

Display an explicit message to users indicating that the session will end in [Assignment: organization-defined time until end of session].

Security and Privacy Attributes | Dynamic Attribute Association

Dynamically associate security and privacy attributes with [Assignment: organization-defined subjects and objects] in accordance with the following security and privacy policies as information is created and combined: [Assignment: organization-defined security and privacy policies].

Security and Privacy Attributes | Maintenance of Attribute Associations by System

Maintain the association and integrity of [Assignment: organization-defined security and privacy attributes] to [Assignment: organization-defined subjects and objects].

Security and Privacy Attributes | Association of Attributes by Authorized Individuals

Provide the capability to associate [Assignment: organization-defined security and privacy attributes] with [Assignment: organization-defined subjects and objects] by authorized individuals (or processes acting on behalf of individuals).

Security and Privacy Attributes | Attribute Displays on Objects to Be Output

Display security and privacy attributes in human-readable form on each object that the system transmits to output devices to identify [Assignment: organization-defined special dissemination, handling, or distribution instructions] using [Assignment: organization-defined human-readable, standard naming conventions].

Security and Privacy Attributes | Maintenance of Attribute Association

Require personnel to associate and maintain the association of [Assignment: organization-defined security and privacy attributes] with [Assignment: organization-defined subjects and objects] in accordance with [Assignment: organization-defined security and privacy policies].

Security and Privacy Attributes | Consistent Attribute Interpretation

Provide a consistent interpretation of security and privacy attributes transmitted between distributed system components.

Security and Privacy Attributes | Association Techniques and Technologies

Implement [Assignment: organization-defined techniques and technologies] in associating security and privacy attributes to information.

Security and Privacy Attributes | Attribute Reassignment — Regrading Mechanisms

Change security and privacy attributes associated with information only via regrading mechanisms validated using [Assignment: organization-defined techniques or procedures].

Remote Access | Protection of Confidentiality and Integrity Using Encryption

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

Remote Access | Managed Access Control Points

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

Remote Access | Protection of Mechanism Information

Protect information about remote access mechanisms from unauthorized use and disclosure.

Wireless Access | Disable Wireless Networking

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

Wireless Access | Restrict Configurations by Users

Identify and explicitly authorize users allowed to independently configure wireless networking capabilities.

Wireless Access | Antennas and Transmission Power Levels

Select radio antennas and calibrate transmission power levels to reduce the probability that signals from wireless access points can be received outside of organization-controlled boundaries.

Access Control for Mobile Devices | Restrictions for Classified Information

(a) Prohibit the use of unclassified mobile devices in facilities containing systems processing, storing, or transmitting classified information unless specifically permitted by the authorizing official; and

(b) Enforce the following restrictions on individuals permitted by the authorizing official to use unclassified mobile devices in facilities containing systems processing, storing, or transmitting classified information:

(1) Connection of unclassified mobile devices to classified systems is prohibited;

(2) Connection of unclassified mobile devices to unclassified systems requires approval from the authorizing official;

(3) Use of internal or external modems or wireless interfaces within the unclassified mobile devices is prohibited; and

(4) Unclassified mobile devices and the information stored on those devices are subject to random reviews and inspections by [Assignment: organization-defined security officials], and if classified information is found, the incident handling policy is followed.

(c) Restrict the connection of classified mobile devices to classified systems in accordance with [Assignment: organization-defined security policies].

Access Control for Mobile Devices | Full Device or Container-based Encryption

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

Use of External Systems | Limits on Authorized Use

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.

Use of External Systems | Portable Storage Devices — Restricted Use

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

Use of External Systems | Network Accessible Storage Devices — Prohibited Use

Prohibit the use of [Assignment: organization-defined network accessible storage devices] in external systems.

Use of External Systems | Portable Storage Devices — Prohibited Use

Prohibit the use of organization-controlled portable storage devices by authorized individuals on external systems.

Information Sharing

a. 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 where user discretion is required]; and

b. Employ [Assignment: organization-defined automated mechanisms or manual processes] to assist users in making information sharing and collaboration decisions.

Information Sharing | Automated Decision Support

Employ [Assignment: organization-defined automated mechanisms] to enforce information-sharing decisions by authorized users based on access authorizations of sharing partners and access restrictions on information to be shared.

Information Sharing | Information Search and Retrieval

Implement information search and retrieval services that enforce [Assignment: organization-defined information sharing restrictions].

Publicly Accessible Content

a. Designate individuals authorized to make information publicly accessible;

b. Train authorized individuals to ensure that publicly accessible information does not contain nonpublic information;

c. Review the proposed content of information prior to posting onto the publicly accessible system to ensure that nonpublic information is not included; and

d. Review the content on the publicly accessible system for nonpublic information [Assignment: organization-defined frequency] and remove such information, if discovered.

Data Mining Protection

Employ [Assignment: organization-defined data mining prevention and detection techniques] for [Assignment: organization-defined data storage objects] to detect and protect against unauthorized data mining.

Access Control Decisions | No User or Process Identity

Enforce access control decisions based on [Assignment: organization-defined security or privacy attributes] that do not include the identity of the user or process acting on behalf of the user.

Reference Monitor

Implement a reference monitor for [Assignment: organization-defined access control policies] that is tamperproof, always invoked, and small enough to be subject to analysis and testing, the completeness of which can be assured.

Device Identification and Authentication | Dynamic Address Allocation

(a) Where addresses are allocated dynamically, standardize dynamic address allocation lease information and the lease duration assigned to devices in accordance with [Assignment: organization-defined lease information and lease duration]; and

(b) Audit lease information when assigned to a device.

Authenticator Management | Biometric Authentication Performance

For biometric-based authentication, employ mechanisms that satisfy the following biometric quality requirements [Assignment: organization-defined biometric quality requirements].

Authenticator Management | Managing Content of PKI Trust Stores

For PKI-based authentication, employ an organization-wide methodology for managing the content of PKI trust stores installed across all platforms, including networks, operating systems, browsers, and applications.

Authenticator Management | GSA-approved Products and Services

Use only General Services Administration-approved products and services for identity, credential, and access management.

Authenticator Management | Presentation Attack Detection for Biometric Authenticators

Employ presentation attack detection mechanisms for biometric-based authentication.