DTM 25-003 User Attribute Management: Building DoD Zero Trust Foundation Through Enterprise ICAM Integration

Unified User Attributes

Conditional user access fails in DoD environments when every application, enclave, and mission system defines identity attributes its own way. The policy engine may be modern, the MFA may be in place, and the dashboard may look clean, but the access decision is still weak if the attributes behind it are local, stale, or disconnected from enterprise ICAM. Under DTM 25-003, that is not a small implementation detail. It is a User pillar foundation issue.

Program offices are under ATO pressure, PPBE timelines do not move fast, and mission systems rarely give the team a clean greenfield path. That is exactly why enterprise user attribute management has to be treated as architecture, not cleanup. Conditional access only works when the attributes driving the decision are authoritative, governed, and reusable across the enterprise.

What DTM 25-003 Requires for Conditional User Access

DTM 25-003 – Implementation of Zero Trust Cybersecurity Activities makes the direction clear for DoD Components: access decisions cannot depend on system-specific identity logic or ad-hoc attributes maintained inside individual applications. The User pillar requires movement toward attribute-based access control using enterprise-managed user attributes that support conditional access across mission and enterprise systems.

The DoD Zero Trust Strategy and the DoD ZTA Capability Outcomes reinforce the same operating model. The objective is continuous verification and least-privilege access based on standardized identity context. That means identity attributes must be centrally governed, current, and consumable by policy decision points. The NSA Zero Trust guidance points in the same direction: avoid siloed identity data and establish enterprise attribute standards that support consistent access decisions across environments.

This matters because many programs still describe static role-based rules as conditional access. A rule that says users in Role X can access Application Y is not enough. Conditional user access requires the access decision to evaluate who the user is, what role they hold, what attributes are authoritative, whether the privilege is elevated, whether the user lifecycle is current, and whether the request aligns with policy at that moment.

The Diagnostic: Start With Enterprise Attributes, Not the Tool

The anchor question for this capability is straightforward: have we established a basic set of user attributes for authentication and authorization across the enterprise? In AISE, this maps to DoD ZTA CoA User pillar capability 1.2.1.1 at Strategic Foundation, with a maturity level 2 expectation. It is not asking whether a program has a directory. It is asking whether the enterprise has a governed attribute baseline that systems can trust for access decisions.

When we assess this with DoD program teams, the conversation quickly moves from the anchor question into operational reality. Are enterprise roles and attributes required for user authorization actually registered within ICAM, or are they buried in application tables and spreadsheets? Are those attributes tied to an identity lifecycle process, or do they depend on manual updates from system administrators? Is there a standardized process for updating roles and attributes, or does every system owner make separate judgment calls?

Privileged access exposes the gaps faster than anything else. If privileged access management is still split between local administrator groups, scripts, shared accounts, and partial PAM onboarding, conditional access will not behave consistently. DTM 25-003 implementation depends on privileged users being managed through a dedicated PAM solution, with users who require elevated access handled exclusively through that control path. If some privileged access is governed by PAM and some is governed by local exception, the access model is not mature enough for enterprise conditional enforcement.

The last diagnostic point is application owner integration. Mature programs do not make every application team open a ticket and wait months to use an enterprise attribute. Application owners need a self-service registration path to request new attributes or consume existing enterprise attributes under governance. That does not mean uncontrolled attribute creation. It means the enterprise has a repeatable process to register, approve, publish, and reuse attributes without forcing mission teams back into local workarounds.

What AISE Scores Mean in Practical Terms

AISE produces separate maturity scores for both the DoD ZTA CoA and the CISA Zero Trust Maturity Model from a single assessment. For DoD program offices, we lead with the DoD ZTA CoA maturity score. The CISA ZTMM score is available as additional context, but it does not pollute the DoD view. One assessment. Two scorecards. Your DoD ZTA CoA maturity score and your CISA ZTMM score stay separate, clean, and defensible.

For Conditional User Access, a Level 1 environment usually means identity attributes are scattered. Applications maintain local roles. Privileged access may be partly documented but not consistently controlled. Attribute updates depend on manual tickets, local administrators, or mission-specific processes. A team may have MFA and directory services in place, but enterprise policy enforcement is limited because the attributes are not authoritative across systems.

At Level 3, the program has moved beyond isolated identity management. There is a defined enterprise attribute set. ICAM is the authoritative registration point for core user attributes. Identity lifecycle events feed attribute updates. PAM is implemented for defined privileged access use cases. Conditional access policies can consume common attributes for a meaningful portion of systems. There are still gaps, especially in legacy mission applications, but the architecture is no longer ad-hoc.

At Level 5, enterprise user attributes are governed as a shared mission service. Policy decision points consume authoritative attributes from ICAM and related authoritative sources. Privileged access is managed through PAM as the standard operating path. Application owners can register and consume attributes through a governed service model. Conditional access decisions are dynamic, centrally managed, and applied consistently across enterprise and mission systems, including legacy integrations where modernization is staged.

Turning Scores Into Milestones

A maturity score only matters if it changes the work plan. For Conditional User Access, we turn the AISE DoD ZTA CoA score into milestones that a program office can fund, assign, and defend through governance.

• Milestone 1: Define the enterprise user attribute baseline for authentication and authorization, including required attributes, authoritative sources, owners, update rules, and consuming systems.

• Milestone 2: Register authorization roles and attributes inside ICAM instead of leaving them in disconnected application stores.

• Milestone 3: Connect user attributes to identity lifecycle management so onboarding, transfers, role changes, separation, and privilege changes update access context in a repeatable way.

• Milestone 4: Complete PAM migration for privileged access use cases and remove unmanaged elevated access paths.

• Milestone 5: Establish an application owner registration process for consuming existing attributes or requesting new governed attributes.

• Milestone 6: Expand conditional access policy enforcement across priority systems based on mission risk, ATO timing, and integration feasibility.

This is how we keep the work realistic. Not every mission system will integrate at the same pace. Not every program has the same funding profile. The point is to stop treating attributes as local configuration and start managing them as an enterprise access control dependency.

ROM Timelines for Moving the Capability Forward

For a program starting from a low maturity state, the first 30 to 60 days should focus on discovery and attribute authority mapping. We identify where user attributes currently live, which systems consume them, which attributes drive authorization, where privileged access is granted, and which lifecycle events update the data. This phase gives the program a defensible baseline against DTM 25-003 and the DoD ZTA CoA.

From 60 to 120 days, the program can define the enterprise attribute baseline, assign ownership, map attributes to ICAM, and identify the first wave of consuming systems. This is also the right window to reconcile mission-specific attributes against enterprise schemas. Prime contractors should be held to that mapping. Hard-coded mission attributes that do not align to the enterprise model create future rework.

From 120 to 240 days, the focus moves to integration. ICAM authoritative attributes feed policy decision points. PAM migration expands for privileged users. Lifecycle events begin updating attributes through a defined process. Application teams start consuming existing attributes instead of maintaining separate local identity logic.

From 240 to 365 days, mature programs expand enforcement across priority systems and refine policy governance. Legacy systems may need compensating patterns or phased integration, but the target state remains the same: conditional access based on authoritative enterprise attributes, not local role assumptions.

Anonymized Federal Scenario

One DoD mission program we assessed had strong identity tooling on paper. MFA was deployed, the directory was stable, and several applications claimed conditional access. The problem was attribute fragmentation. One application used local mission roles, another used directory groups, another used a contractor-maintained table, and privileged users were split between a PAM tool and legacy administrator groups.

The AISE DoD ZTA CoA maturity score showed the gap clearly. The program was not failing because it lacked effort. It was failing because the access decision depended on inconsistent attribute sources. The CISA ZTMM score provided useful secondary context, but the DoD team needed the CoA view to brief leadership and align remediation to DTM 25-003.

The corrective path was not to buy another access tool. The program defined an enterprise attribute baseline, mapped mission roles into ICAM, prioritized PAM onboarding for elevated access, and created a governed process for application owners to consume approved attributes. Within the first two quarters, the team had moved from local authorization logic toward repeatable enterprise conditional access for the highest-priority systems. That progress supported the DTM 25-003 implementation path without pretending every legacy integration could be fixed at once.

Where to Start

Conditional User Access is not a dashboard problem. It is an enterprise attribute management problem. DTM 25-003, the DoD Zero Trust Strategy, the DoD ZTA CoA, and NSA Zero Trust guidance all point to the same requirement: access decisions must be driven by authoritative, governed user attributes that can be evaluated consistently across systems.

AISE gives DoD program offices a clean DoD ZTA CoA maturity score for this capability while also producing a separate CISA ZTMM score from the same assessment. No civilian framework noise in the DoD scorecard. Just a clear view of where the User pillar stands and what needs to move next.

To get your AISE maturity baseline and see where you stand against DTM 25-003, visit zephon.tech/zt.