CISA ZTMM User Attribute Federation: Meeting OMB M-22-09 Identity Management Requirements

The conditional access problem inside most civilian agencies is not a lack of identity tools. It is that the enterprise ICAM stack does not have clean, trusted, federated user attributes to make access decisions. The result is predictable: cloud applications, on-prem systems, shared services, and bureau-specific platforms still rely on static groups, local exceptions, and manual approvals. That limits progress against the CISA Zero Trust Maturity Model and creates visible gaps against OMB M-22-09 identity expectations.

A Mature Identity Model Starts with a Mature Attribute Model

Policy Grounding: What OMB M-22-09 and CISA ZTMM Require

OMB M-22-09 makes continuous verification of identity and context a core federal requirement. For the identity pillar, that means access cannot be based only on a successful login. Agencies need to evaluate who the user is, what role they hold, what device and network context applies, what risk signals are present, and whether the requested access matches least-privilege policy.

The CISA ZTMM pushes this further by defining maturity in practical terms. At higher maturity levels, conditional user access depends on dynamic attribute-based decisions, federation support, and consistent enforcement across applications. This is where many agencies stall. They have MFA. They have an IdP. They may even have federation. But the attributes that drive access decisions are incomplete, inconsistent, or not governed.

FISMA reinforces the same direction through risk-based access control and continuous monitoring. FedRAMP also matters because civilian agencies increasingly buy identity, security, and application capabilities through cloud services. Procurement teams need to know whether a FedRAMP-authorized service can consume and enforce federated user attributes, not simply whether it supports SAML or OIDC on paper.

The Real Assessment Question: Do We Know Which Attributes Matter?

The anchor question for this capability is direct: has the organization identified all relevant user and group attributes that need to be federated with the enterprise ICAM solution?

For civilian agencies, those attributes typically include role, bureau or component, employment type, privileged status, PIV status, contractor affiliation, location, device trust, mission assignment, application entitlement, and separation status. In some environments, additional attributes such as adjudication status, data handling need, emergency role, or field-office assignment matter just as much.

The issue is not whether these data elements exist somewhere. They usually do. The issue is whether they are authoritative, synchronized, normalized, and usable by the enterprise identity provider and downstream applications.

That leads to the supporting diagnostic questions we use in implementation work. Does the cloud-based enterprise IdP support both cloud and on-premises applications for authentication and authorization? Are roles defined consistently across bureaus, shared services, and legacy systems? Is there a governance structure for managing roles and permissions, including approval of changes? Is there a process that mandates standardized roles and permissions instead of allowing each application team to invent its own access model?

For agencies with field operations, intermittent connectivity, inspection environments, or mission locations with constrained access, another question matters: can local capabilities continue operations while still aligning back to centralized ICAM management? Civilian agencies may not use the DoD term DDIL, but the operational problem is familiar. Field teams need to work when connectivity is degraded, and identity decisions still need to reconcile cleanly when the environment reconnects.

The final diagnostic point is monitoring. If an agency cannot audit how roles and permissions are used, it cannot manage conditional access at scale. That includes tracking which applications consume which attributes, which policies use them, which users receive exceptions, and whether role assignments drift from approved governance.

What the AISE Score Means for Conditional User Access

AISE, Zephon LLC'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 identity requirements. The DoD ZTA CoA score provides additional context for agencies that operate with DoD partners, federal integrators, or mission systems that must align across government environments.

One assessment. Two scorecards. A CISA ZTMM maturity score for leadership reporting, and a separate OMB M-22-09 gap view that shows where identity implementation needs work. The DoD ZTA CoA score remains separate and clean, so the agency does not mix civilian reporting with defense-specific maturity language.

Level 1: Static Access With Limited Attribute Use

At Level 1, access is mostly based on directory groups, application-local roles, and manually maintained permissions. The agency may have MFA and federation, but conditional access policies depend on broad rules. User attributes are incomplete, not consistently synchronized, or not trusted for authorization decisions. Procurement teams may buy tools that support identity federation but do not require usable attribute mapping in the RFP or statement of work.

Level 3: Centralized Identity With Partial Conditional Access

At Level 3, the enterprise IdP supports major cloud and on-premises applications. Common attributes are synchronized, and some conditional access policies use user context. The agency has role definitions for major user populations, but exceptions remain common. Governance exists, but it may not cover all bureaus, contractors, privileged users, or legacy systems. This is where many civilian agencies sit: better than static access, but not yet mature enough for consistent CISA ZTMM Advanced behavior.

Level 5: Dynamic Attribute-Based Access Across the Enterprise

At Level 5, user attributes are governed as enterprise security data. Authoritative sources are defined. Changes are approved, monitored, and propagated through ICAM workflows. Conditional access policies use real-time or near-real-time attributes to support least privilege across cloud, on-prem, and hybrid systems. Application teams do not create unmanaged local roles without mapping them back to enterprise identity governance. Leadership can see maturity trends, policy coverage, exception volume, and high-risk access patterns.

Turning Scores Into Milestones

A useful maturity score does not sit in a slide deck. It becomes an execution plan. For Conditional User Access, we turn the CISA ZTMM score into milestones across four tracks: attribute inventory, federation coverage, policy enforcement, and governance.

• Attribute inventory: identify authoritative sources for role, affiliation, privileged status, bureau, contractor status, device trust, and other access-driving fields.

• Federation coverage: map which applications consume enterprise identity, which still depend on local accounts, and which need modernization or compensating controls.

• Policy enforcement: define conditional access rules that use verified attributes instead of static group membership alone.

• Governance: create an approval and monitoring process for roles, permissions, exceptions, and attribute changes.

This is also where procurement officers have real impact. If RFPs and task orders do not require attribute federation, conditional access support, logging, and FedRAMP-aligned identity integration, the agency will inherit another tool that works technically but does not move the maturity needle.

ROM Timelines for Moving the Capability Forward

These are ROM timelines based on federal implementation realities, not best-case vendor diagrams. Continuing resolution budget uncertainty, lean IT staffing, shared service dependencies, and legacy application constraints all affect sequencing.

• 0 to 30 days: complete an AISE maturity baseline, identify high-value user attributes, document authoritative sources, and map major applications to current identity patterns.

• 30 to 90 days: prioritize critical applications, validate cloud IdP support for both cloud and on-premises authentication, and define the first set of standardized roles and permissions.

• 90 to 180 days: implement conditional access policies for privileged users, contractors, high-risk applications, and remote access paths. Begin exception tracking and role governance.

• 6 to 12 months: expand attribute federation across major business systems, reduce local application roles, and integrate monitoring into FISMA reporting and security operations workflows.

• 12 to 18 months: move toward dynamic attribute-based access across hybrid environments, with leadership reporting tied to CISA ZTMM maturity progression and OMB M-22-09 implementation priorities.

The goal is not to boil the ocean. The goal is to identify the access decisions that carry the most mission risk and modernize those first.

Anonymized Federal Scenario

One civilian agency we worked with had a mature MFA deployment and a well-known cloud identity provider. On paper, the identity program looked strong. In practice, access to several mission applications still depended on local roles created years earlier by individual system owners.

The agency's IdP could authenticate users, but it did not consistently pass trusted attributes into downstream authorization workflows. Contractor status was not always current. Privileged user status lived in a separate process. Bureau assignment was formatted differently across directories. Some applications treated all federated users the same after login.

We started with the attribute map, not a tool replacement. The team identified which attributes were required for conditional user access, which systems were authoritative, and where synchronization failed. Procurement language was updated so new FedRAMP cloud services had to support attribute consumption, logging, and policy enforcement. The agency then prioritized privileged access and contractor access before expanding to broader application groups.

The outcome was measurable. Leadership could see which applications supported federated attributes, which policies were enforcing conditional access, where exceptions existed, and which gaps mapped directly to CISA ZTMM and OMB M-22-09 identity priorities. That is the level of clarity federal CISOs and IT directors need when resources are tight.

Get the Baseline Before You Fund the Next Tool

Conditional User Access depends on trusted user attribute federation. Without it, agencies stay trapped in static access models even when they have modern identity platforms. AISE gives civilian agencies a CISA ZTMM maturity baseline mapped to OMB M-22-09, with a separate DoD ZTA CoA score for cross-framework visibility.

If your agency is planning identity modernization, FedRAMP cloud procurement, or FY budget justification work, start with the baseline. See where your Conditional User Access capability stands and which implementation gaps matter first.

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