DTM 25-003 ICAM Requirements: Building Conditional User Access Around Enterprise Identity
- Vishal Masih
- 7 days ago
- 6 min read
Most DoD program offices do not fail at conditional user access because they lack identity tools. They fail because identity is still fragmented across mission applications, privileged access workflows, directory services, and local authorization tables. Under DTM 25-003, that model does not hold. Conditional access depends on enterprise ICAM that can provide current identity, credential, privilege, and attribute data to the systems making access decisions.

This matters because program offices are under real pressure. PPBE timelines do not move fast. ATO schedules keep coming. Mission systems have legacy dependencies, disconnected enclaves, tactical constraints, and contractor-operated components. The practical question is not whether ICAM matters. The question is whether the current ICAM implementation can support enforceable conditional user access across the environment mapped to the DoD ZTA CoA.
What DTM 25-003 Requires for Conditional User Access
DTM 25-003 – Implementation of Zero Trust Cybersecurity Activities makes enterprise ICAM a foundational activity for DoD Zero Trust. It is not a side project and it is not limited to CAC issuance, directory synchronization, or single sign-on. For the User pillar, enterprise ICAM must support conditional access decisions across systems, environments, and mission contexts.
The DoD Zero Trust Strategy and DoD ZTA CoA move access control away from static allow lists and fixed role assignments. Access decisions must be based on enterprise attributes, user context, credential strength, privilege level, device posture, risk signals, and mission need. NSA ZIG reinforces the same point: ICAM services must integrate with policy engines so least-privilege access can be enforced dynamically.
That is the dividing line. A program can have identity products in place and still be immature if those products cannot feed policy decision points, support federation, expose usable attributes, or provision and deprovision access through controlled workflows. DTM 25-003 expects ICAM to operate as an enterprise service supporting conditional access, not as a collection of disconnected identity utilities.
The Diagnostic: Is ICAM Enterprise-Wide or Just Locally Useful?
The anchor question for this capability is direct: Is the organization using an enterprise-wide ICAM solution? In the AISE assessment, this maps to DoD ZTA CoA activity 1.2.1.2 at the Strategic Foundation level. That is the right place to start because conditional access cannot scale if the identity source of truth is unclear.
In practice, we look at whether the ICAM environment can support enterprise federation, authoritative attribute exchange, lifecycle management, and integration with access enforcement points. If a mission application still relies on local accounts with stale group membership, the conditional access model breaks. If the ICAM platform cannot provide real-time or near-real-time user attributes to the policy engine, access decisions revert to static rules.
The supporting questions sharpen the picture. Can users or authorized managers update approved attributes through self-service workflows without bypassing governance? Is privileged access management fully integrated with ICAM for provisioning and deprovisioning? Are Just-Enough-Administration privileges defined for administrative accounts, or are broad admin roles still the default? Does the PAM solution support Just-In-Time access, and does it restrict what administrators can do once access is granted?
The final test is operational: are application and service permissions dynamically adjusted based on enterprise user attributes? If the answer is no, the program may have identity tooling, but it does not yet have mature conditional user access.
What the AISE Maturity Score Means
AISE, Zephon's Assess, Identify, Strategize, Execute Zero Trust Maturity Platform, produces separate maturity scores for the DoD ZTA CoA and CISA ZTMM from a single assessment. For DoD program offices, the primary output is the DoD ZTA CoA maturity score. The CISA ZTMM score is kept separate as additional context, not mixed into the DoD result. One assessment. Two scorecards. Clean, defensible, and useful for program planning.
For conditional user access, a Level 1 result usually means identity exists in pockets. CAC authentication may be present, but local accounts, manual access requests, static roles, and disconnected privileged access workflows still drive many decisions. The program can authenticate users, but it cannot consistently make conditional authorization decisions across systems.
A Level 3 result indicates the program has moved into managed implementation. Enterprise ICAM is integrated with major systems, attributes are available for policy decisions, PAM is connected to identity lifecycle processes, and JIT or JEA patterns are operating for selected privileged workflows. There are still gaps, usually around legacy applications, mission partner access, or inconsistent attribute quality, but the foundation is active.
A Level 5 result reflects an operational conditional access model. Enterprise ICAM feeds policy engines with current attributes. Access is continuously evaluated. Privileged sessions are time-bound and scoped. Application permissions adjust based on authoritative identity and mission attributes. Exceptions are governed, measured, and reduced over time. This is where ICAM becomes a mission control point rather than an administrative service.
Turning Scores Into Milestones
The score is only useful if it becomes a roadmap. For DoD programs, we turn the AISE DoD ZTA CoA score into milestones that fit PPBE realities, ATO commitments, and mission system constraints. The work usually breaks into four tracks.
Authoritative identity and attribute sources: identify which systems own user identity, organization, clearance, role, affiliation, contract status, and mission attributes.
Federation and integration: connect enterprise ICAM to applications, PAM, policy engines, and access gateways using repeatable integration patterns.
Privilege modernization: define JEA models, implement JIT access for privileged users, and remove standing administrative access where mission operations allow.
Conditional access enforcement: apply attribute-based decisions to priority applications, then expand to services, APIs, administrative consoles, and mission partner access paths.
This sequence matters. Programs that buy policy tooling before fixing identity attributes create expensive dashboards with weak enforcement. Programs that modernize PAM without ICAM integration leave provisioning and deprovisioning gaps. Programs that treat conditional access as an application-by-application project create inconsistent controls that are hard to defend during technical review.
ROM Timelines for DoD Program Offices
Realistic timelines depend on system complexity, identity debt, hosting model, and acquisition path. For a program starting with fragmented identity but some enterprise directory and CAC integration, a practical ROM to reach a DTM 25-003-aligned conditional access foundation is usually 6 to 12 months. That includes assessment, authoritative source mapping, priority attribute cleanup, PAM integration planning, and initial conditional access patterns for high-value applications.
Moving from a managed Level 3 posture to a more advanced Level 5 operating model usually takes 18 to 36 months. That work includes broader application integration, JIT and JEA expansion, policy engine integration, privileged session control, dynamic access rules, exception management, and measurement across mission environments. Legacy systems, disconnected operations, and contractor-managed components can extend the timeline.
The key is to avoid boiling the ocean. Start with mission impact and risk. Prioritize systems with privileged access, sensitive mission data, external mission partner access, or high ATO visibility. Build repeatable patterns, then scale them.
An Anonymized Federal Scenario
One DoD-aligned program we supported had CAC authentication in place and believed its ICAM posture was mature. The assessment showed a different picture. User authentication was enterprise-connected, but application authorization depended on local groups maintained by system administrators. Privileged access was requested by email, approved outside the identity workflow, and often remained active after personnel moved roles. Contractor attributes were inconsistent across environments.
The program did not need a rip-and-replace. It needed an implementation sequence. We mapped authoritative attributes, integrated PAM provisioning with ICAM, defined JEA profiles for the highest-risk administrator roles, and established JIT access for selected operational workflows. We then connected priority applications to enterprise attributes so access decisions could change when user status, role, or mission assignment changed.
The outcome was not a slogan. It was a measurable shift from static access to conditional access. The program had a clearer DoD ZTA CoA maturity baseline, better evidence for DTM 25-003 implementation planning, and a roadmap that fit its funding and ATO constraints.
Where to Start
For conditional user access, the first question is not which tool to buy. It is whether enterprise ICAM can provide the identity, credential, privilege, and attribute signals needed to make access decisions at the point of enforcement. DTM 25-003, the DoD Zero Trust Strategy, the DoD ZTA CoA, and NSA ZIG all point in the same direction: identity must drive policy.
AISE gives DoD program offices one assessment with two separate scorecards: a DoD ZTA CoA maturity score for the mission and mandate, and a CISA ZTMM score for additional context. No civilian framework noise in the DoD score. Just a clear baseline for where ICAM stands and what needs to move next.
Get your AISE maturity baseline at zephon.tech/zt.



Comments