CISA ZTMM User Attribute Architecture: Meeting OMB M-22-09 Requirements for Federal Identity Management

Conditional access breaks down fast when user attributes live in too many places. We see this across civilian agencies: HR owns one version of the user, Active Directory owns another, the identity provider has a partial profile, and mission applications maintain local roles that nobody reconciles until access is wrong. That is not a tool problem first. It is an attribute architecture problem, and it directly affects how well an agency can implement OMB M-22-09 and the CISA Zero Trust Maturity Model User pillar.

Proper Conditional Access Requires Unified User Attributes

What OMB M-22-09 and CISA ZTMM Require for Conditional User Access

OMB M-22-09 directs agencies to move away from static, network-centric access and toward identity-centric controls based on continuous verification and least privilege. Section III.B is clear on the direction: access decisions need to depend on identity, context, and risk, not network location alone. Section IV pushes that further by requiring conditional access policies that use user and environmental attributes across agency systems.

CISA ZTMM gives agencies the maturity path for that requirement. In the User pillar, Level 2 maturity for conditional user access depends on a standardized and centralized user attribute schema. That schema needs to include the attributes that policy engines can actually use: identity, role, affiliation, clearance or suitability where applicable, location, employment status, privileged access status, and other agency-defined factors.

For civilian agencies, this is also tied to FISMA and FedRAMP execution. FISMA continuous monitoring depends on knowing who has access, why they have it, and whether access still matches current business need. FedRAMP-authorized services can support the procurement path, but the agency still has to define, govern, and feed trusted attributes into the identity provider, PAM platform, and policy decision points.

The hard part is not agreeing with the policy. The hard part is implementing it while operating under continuing resolution budget uncertainty, lean identity teams, aging application portfolios, and procurement cycles that often buy tools before the attribute model is settled.

The Diagnostic: Start With the User Attribute Foundation

The anchor question for this capability is straightforward: has the agency established a basic set of user attributes for authentication and authorization across the enterprise? In AISE, this maps to Conditional User Access under the User pillar and sits at the Strategic Foundation level. For CISA ZTMM, it is the point where identity stops being a login event and starts becoming a policy input.

We do not treat that as a yes-or-no checkbox. We look at whether the agency has a canonical attribute schema that is recognized across ICAM, PAM, HR, cloud platforms, and major mission systems. If the schema exists only in a slide deck, it will not support conditional access. If the schema exists in the identity provider but application owners still maintain local roles with no registration process, it will not scale.

The next diagnostic question is whether enterprise roles and attributes required for authorization are registered within the ICAM system. That includes standard workforce roles, contractor affiliations, privileged roles, emergency access, service account ownership, and application-specific entitlements that have enterprise relevance. When these attributes remain buried in application silos, conditional access policies become shallow. They can confirm the user authenticated, but they cannot consistently evaluate whether the user should reach that system from that device under that context.

Attribute life-cycle management is the next test. User attributes need to connect to joiner, mover, and leaver processes. When an employee changes office, mission function, contract status, or privileged responsibility, the attribute update must flow into ICAM quickly enough to affect access decisions. If those updates depend on help desk tickets and manual group changes, the agency may have identity tooling in place, but it does not yet have reliable conditional user access.

Privileged access is where weak attribute governance becomes visible. A dedicated PAM solution is required for mature control, but the larger issue is whether all privileged users are managed exclusively through that PAM path. If privileged access still exists through unmanaged local admin groups, shared administrator accounts, or application-native roles outside PAM, the agency's conditional access picture is incomplete.

The final maturity test is whether application owners can request, register, and use enterprise attributes through a controlled self-service process. This matters because agency IT teams cannot hand-build every integration. Application owners need a governed path to consume approved attributes without creating their own identity stores. That is how agencies reduce custom access logic while still supporting mission-system complexity.

What the AISE Maturity Score Means in Practice

AISE, Zephon's Zero Trust Maturity Platform, produces separate maturity scores for CISA ZTMM and DoD ZTA CoA from a single assessment. For civilian agencies, the primary output is the CISA ZTMM maturity score mapped to OMB M-22-09 requirements. The DoD ZTA CoA score provides additional context for agencies working with defense partners, shared services, or cross-domain identity expectations.

For Conditional User Access, a low AISE score usually means the agency has fragmented user attributes. HR, Active Directory, the identity provider, PAM, and applications each hold part of the story. Access decisions rely on basic roles or groups, and many authorization rules are still embedded in applications. Leadership may hear that MFA is deployed, but MFA alone does not satisfy the intent of identity-centric conditional access.

At Maturity Level 1, the agency has basic authentication and some role-based access controls, but there is no authoritative enterprise attribute model. User attributes are inconsistent, and privileged access may be partially managed outside a dedicated PAM solution. Conditional access policies are limited because the policy engine does not have enough trusted data.

At Maturity Level 3, the agency has a defined user attribute schema, registered enterprise roles, and integration between identity life-cycle management and ICAM. PAM covers the primary privileged accounts. Attribute changes are handled through a standard process, even if some mission applications still require custom handling. This is where agencies begin to make practical progress against OMB M-22-09 conditional access expectations.

At Maturity Level 5, user attributes are treated as operational security data. They are governed, updated automatically from authoritative sources, consumed by policy decision points, and available to application owners through a controlled registration process. PAM is the exclusive path for privileged access. Conditional policies evaluate identity, role, affiliation, device posture, location, and risk signals in near real time. That is the target operating model for mature zero trust user access.

Turning Scores Into Milestones

A score only matters if it drives the next funding decision, engineering sprint, or procurement requirement. We translate Conditional User Access scores into milestones that agency leaders can use with CISOs, IT directors, acquisition teams, and system owners.

• Define the canonical user attribute schema and identify authoritative sources for each attribute.

• Register enterprise roles and authorization attributes in the ICAM system.

• Connect attribute updates to identity life-cycle management for joiner, mover, and leaver events.

• Move privileged access into a dedicated PAM solution and remove unmanaged admin paths.

• Require identity tools and cloud services to support standardized attribute federation during procurement.

• Create a governed self-service process for application owners to consume approved enterprise attributes.

This is also where procurement officers become essential. If a solicitation buys an identity product without requiring attribute federation, standards-based integration, and support for agency-defined authorization attributes, the agency inherits another silo. FedRAMP can reduce cloud authorization friction, but it does not replace the need for agency-owned attribute governance.

ROM Timelines for Practical Progress

For agencies starting with fragmented attributes and manual group management, a realistic first phase is 60 to 90 days. That phase should establish the current-state inventory, identify authoritative sources, define the first version of the enterprise user attribute schema, and map the gaps to CISA ZTMM and OMB M-22-09 expectations.

The next 90 to 180 days should focus on implementation of priority integrations. That usually means connecting HR and identity life-cycle processes to ICAM, registering core enterprise roles, integrating the identity provider with policy decision points, and moving high-risk privileged accounts into PAM. Agencies under staffing constraints should start with privileged users, high-value applications, and systems already moving through modernization or FedRAMP-based procurement.

A 6 to 12 month window is realistic for broader adoption across major applications, especially where legacy systems require custom role mapping. This phase should include application owner self-service registration, standardized attribute consumption patterns, and continuous monitoring measures that support FISMA reporting.

For large civilian agencies with distributed bureaus, complex grants systems, or major public-facing platforms, the full operating model may take 12 to 24 months. That timeline is normal. The key is to show measurable movement: fewer unmanaged attributes, more applications consuming enterprise attributes, greater PAM coverage, and conditional policies that use real context.

Federal Scenario: From Role Sprawl to Attribute-Based Access

One civilian agency we supported had deployed MFA and a modern identity provider, but conditional access remained weak. The issue was not authentication. The issue was that roles were spread across HR feeds, directory groups, SaaS applications, and local mission-system tables. Procurement had also introduced new cloud services without consistent attribute federation requirements.

We started by building the enterprise user attribute inventory and mapping each attribute to an authoritative source. The agency then defined a canonical schema for workforce identity, contractor affiliation, privileged status, office assignment, and application authorization attributes. PAM was prioritized for system administrators and application support teams. Application owners received a registration path for approved enterprise attributes instead of creating new local identity fields.

The result was not a grand rewrite of every application. It was a controlled shift from static roles to governed attributes. Conditional access policies became more meaningful because the identity platform had trusted data to evaluate. FISMA reporting improved because access decisions were easier to explain and monitor. The agency also used the attribute requirements in new FedRAMP-based procurements, which reduced downstream integration work.

Get the Baseline Before the Next Tool Decision

Conditional user access depends on the quality of the attributes behind the policy. Agencies that skip the schema work end up with expensive identity tools enforcing shallow rules. Agencies that define and govern user attributes can make OMB M-22-09 and CISA ZTMM implementation measurable, fundable, and understandable to leadership.

AISE gives civilian agencies one assessment and two scorecards: a clean CISA ZTMM maturity score mapped to OMB M-22-09 requirements, plus a separate DoD ZTA CoA score for additional context. If Conditional User Access is on your roadmap, start with the maturity baseline before the next procurement package or system modernization sprint.

Get your AISE maturity baseline at zephon.tech/zt or contact defend@zephon.tech.