How Identity and Access Management Supports Federal Zero Trust

Agencies must employ centralized identity management systems for agency users that can be integrated into applications and common platforms.

In practice: Staff sign in to email, ticketing and HR apps through one central identity provider, and new applications are connected to it instead of keeping their own user lists.

Agencies must use strong MFA throughout their enterprise.

In practice: Every employee signs in with a second factor, such as a security key or authenticator app, whether they use email, the VPN or an internal app, and exceptions are listed.

MFA must be enforced at the application layer, instead of the network layer.

In practice: Each application checks the second factor at sign-in through the identity provider, so being on the office network does not skip the MFA prompt.

For agency staff, contractors, and partners, phishing-resistant MFA is required.

In practice: Employees, contractors and partners enroll a security key or certificate-based credential; a texted code is no longer accepted for routine access to agency systems.

Password policies must not require use of special characters or regular rotation.

In practice: The password policy drops forced special characters and scheduled resets; users change a password only when there is a reason to, and the setting lives on the identity provider.

Agencies must require their users to use a phishing-resistant method to access agency-hosted accounts. For routine self-service access by agency staff, contractors, and partners, agency systems must discontinue support for authentication methods that fail to resist phishing, including protocols that register phone numbers for SMS or voice calls, supply one-time codes, or receive push notifications.

In practice: For routine self-service access, the identity team turns off SMS, voice call, one-time code and push approval for staff, contractors and partners, then moves them to security keys or certificates.

When authorizing users to access resources, agencies must consider at least one device-level signal alongside identity information about the authenticated user.

In practice: An access policy checks whether the laptop is registered and healthy, as well as who the user is, before it opens a sensitive application.

Access to individual enterprise resources is granted on a per-session basis. Trust in the requester is evaluated before the access is granted. Access should also be granted with the least privileges needed to complete the task. This could mean only “sometime recently” for this particular transaction and may not occur directly before initiating a session or performing a transaction with a resource. However, authentication and authorization to one resource will not automatically grant access to a different resource.

In practice: Access to a resource is decided for each session, with the least privilege the task needs, and an administrator's elevation ends when the task is done.

Access to resources is determined by dynamic policy—including the observable state of client identity, application/service, and the requesting asset—and may include other behavioral and environmental attributes. An organization protects resources by defining what resources it has, who its members are (or ability to authenticate users from a federated community), and what access to resources those members need. For zero trust, client identity can include the user account (or service identity) and any associated attributes assigned by the enterprise to that account or artifacts to authenticate automated tasks. Requesting asset state can include device characteristics such as software versions installed, network location, time/date of request, previously observed behavior, and installed credentials. Behavioral attributes include, but not limited to, automated subject analytics, device analytics, and measured deviations from observed usage patterns. Policy is the set of access rules based on attributes that an organization assigns to a subject, data asset, or application. Environmental attributes may include such factors as requestor network location, time, reported active attacks, etc. These rules and attributes are based on the needs of the business process and acceptable level of risk. Resource access and action permission policies can vary based on the sensitivity of the resource/data. Least privilege principles are applied to restrict both visibility and accessibility.

In practice: The access policy weighs who the user is, the state of the device and unusual behavior, all backed by a role model that owners have reviewed.

All resource authentication and authorization are dynamic and strictly enforced before access is allowed. This is a constant cycle of obtaining access, scanning and assessing threats, adapting, and continually reevaluating trust in ongoing communication. An enterprise implementing a ZTA would be expected to have Identity, Credential, and Access Management (ICAM) and asset management systems in place. This includes the use of multifactor authentication (MFA) for access to some or all enterprise resources. Continual monitoring with possible reauthentication and reauthorization occurs throughout user transactions, as defined and enforced by policy (e.g., time-based, new resource requested, resource modification, anomalous subject activity detected) that strives to achieve a balance of security, availability, usability, and cost-efficiency.

In practice: Users pass MFA before each resource opens, and the identity provider keeps re-evaluating the session, asking for re-authentication when risk goes up.

Access Management

Agency authorizes need-based and session-based access, including for privileged access request, that is tailored to actions and resources.

In practice: An administrator asks for elevated rights for one task, a second person signs off, and the elevation lasts only for that session and that resource.

Access Management

Agency authorizes access, including for privileged access requests, that expires with automated review.

In practice: Access is granted for a set period and expires on its own; an automated review campaign asks the owner whether to renew it.

Access Management

Agency uses automation to authorize just-in-time and just-enough access tailored to individual actions and individual resource needs.

In practice: Automation grants just-in-time, just-enough access for a specific task, built on a role and entitlement model that owners have reviewed.

Access Management

Agency authorizes permanent access with periodic review for both privileged and unprivileged accounts.

In practice: Managers and system owners review who holds standing access, including administrator accounts, in periodic access review campaigns.

Authentication

Agency begins to authenticate all identity using phishing-resistant MFA and attributes, including initial implementation of password-less MFA via FIDO2 or PIV.

In practice: Staff begin signing in with security keys or smart cards, and passwordless sign-in is rolled out one group at a time, starting with administrators.

Authentication

Agency authenticates identity using MFA, which may include passwords as one factor and requires validation of multiple entity attributes (e.g., locale or activity).

In practice: MFA is turned on through the identity provider for staff, and the short list of accounts excluded from it is written down and reviewed.

Authentication

Agency continuously validates identity with phishing-resistant MFA, not just when access is initially granted.

In practice: After the first sign-in, the identity provider keeps watching session signals and asks the user to re-authenticate with a security key when something changes.

Authentication

Agency authenticates identity using either passwords or multi-factor authentication (MFA) with static access for entity identity.

In practice: An assessment lists which accounts still sign in with a password alone and which applications have no MFA, giving the agency a baseline to work from.

Automation and Orchestration Capability

Agency manually orchestrates privileged user identities and automates orchestration of all identities with integration across all environments.

In practice: Joiner, mover and leaver processing runs across cloud and on-premises systems, while administrators' accounts stay under manual, sign-off based handling.

Automation and Orchestration Capability

Agency manually orchestrates privileged and external identities and automates orchestration of non-privileged users and of self-managed entities.

In practice: A new hire in the HR system triggers account creation, role changes update access, and leavers are disabled automatically; privileged accounts are still handled by hand.

Automation and Orchestration Capability

Agency automates orchestration of all identities with full integration across all environments based on behaviors, enrollments, and deployment needs.

In practice: The HR system and other authoritative sources drive the full account lifecycle for every identity, adjusting access as roles and behavior change.

Automation and Orchestration Capability

Agency manually orchestrates (onboards, offboards, and disables) self-managed identities (users and entities), with little integration, and performs regular review.

In practice: HR tickets go to the help desk, whose staff create and disable accounts by hand, and a periodic review looks for accounts that were missed.

Identity Stores

Agency begins to securely consolidate and integrate some self-managed and hosted identity stores.

In practice: Duplicate directories are merged where it makes sense, and identity correlation links each person's accounts across the remaining stores.

Identity Stores

Agency has a combination of self-managed identity stores and hosted identity store(s) (e.g., cloud or other agency) with minimal integration between the store(s) (e.g., Single Sign-on.).

In practice: Cloud applications use single sign-on, and an on-premises directory is synchronized to a cloud directory so staff keep one account across both.

Identity Stores

Agency securely integrates their identity stores across all partners and environments as appropriate.

In practice: Partner agencies sign in through federation with their own identity providers, and identity data is unified across on-premises and cloud environments.

Identity Stores

Agency only uses self-managed, on-premises (i.e., planned, deployed, and maintained by agency) identity stores.

In practice: The team inventories the on-premises directories the agency runs and the applications that depend on each one, which shows what would need to move later.

For public users, phishing-resistant MFA must be an option.

In practice: The application owner runs the public-facing service; identity configures its customer sign-in to offer residents a passkey or security key as one option.

The enterprise collects as much information as possible about the current state of assets, network infrastructure and communications and uses it to improve its security posture. An enterprise should collect data about asset security posture, network traffic and access requests, process that data, and use any insight gained to improve policy creation and enforcement. This data can also be used to provide context for access requests from subjects (see Section 3.3.1).

In practice: The architecture team gathers data about assets and access requests; identity contributes request telemetry that is used to tune access policy.

Governance Capability

Agency implements identity policies for enterprise-wide enforcement with automation and updates policies periodically.

In practice: Policy is written as configuration, enforced automatically by the identity platform, and updated on a regular cycle by the policy owner.

Governance Capability

Agency defines and begins implementing identity policies for enterprise-wide enforcement with minimal automation and manual updates.

In practice: Leadership defines identity policy for the whole agency, and the identity team starts turning those rules into settings with some automation.

Governance Capability

Agency implements and fully automates enterprise-wide identity policies for all users and entities across all systems with continuous enforcement and dynamic updates.

In practice: The policy owner sets identity rules once; tools enforce them across all systems continuously and flag any setting that drifts from the rule.

Governance Capability

Agency implements identity policies (authentication, credentials, access, lifecycle, etc.) with enforcement via static technical mechanisms and manual review.

In practice: A policy owner sets identity rules for passwords and access; identity teams apply them as static settings and review them by hand.

Risk Assessments

Agency determines identity risk with some automated analysis and dynamic rules to inform access decisions and response activities.

In practice: The security team's tooling scores identity risk, and identity policy responds automatically, for example asking for a step-up MFA or blocking a sign-in.

Risk Assessments

Agency determines identity risk using manual methods and static rules to support visibility.

In practice: The security team reads sign-in risk and account reports by hand and applies fixed rules, using identity data as the input.

Risk Assessments

Agency determines identity risk in real time based on continuous analysis and dynamic rules to deliver ongoing protection.

In practice: A threat detection service run by the security team scores risk in real time, and the identity provider feeds it sign-in events and acts on its decisions.

Risk Assessments

Agency makes limited determinations for identity risk (i.e., likelihood that an identity is compromised).

In practice: Another team owns risk analytics; identity provides account and sign-in data, and a gap review notes where identity risk is not measured at all.

Visibility and Analytics Capability

Agency performs automated analysis across some user and entity activity log types and augments collection to address gaps in visibility.

In practice: Analytics run by the security team span several log types, and identity adds missing log sources so that fewer activities go unseen.

Visibility and Analytics Capability

Agency collects user and entity activity logs and performs routine manual analysis and some automated analysis, with limited correlation between log types.

In practice: Security operations owns the central log platform; identity logs are routed there, though they are only loosely correlated with other log types.

Visibility and Analytics Capability

Agency maintains comprehensive visibility and situational awareness across enterprise by performing automated analysis over user activity log types, including behavior-based analytics.

In practice: The security team's analytics correlate identity activity with other telemetry to spot unusual behavior, using identity logs as one important input.

Visibility and Analytics Capability

Agency collects user and entity activity logs, especially for privileged credentials, and performs some routine manual analysis.

In practice: The logging team collects activity logs; identity supplies sign-in and administrator logs, especially for privileged accounts, for routine manual review.