The Defense Information Systems Agency (DISA) has issued a call for a next-generation E-ICAM prototype, a cloud-hosted solution for Impact Level 5 and IL6 environments, with an enterprise capability due by September 2027. DISA refers to E-ICAM as the "critical first layer" of the Zero Trust Cybersecurity Architecture. If your team manages security for a contractor or agency enclave that relies on Department of Defense (DoD) identity services, take note: zero trust fails when the identity layer is fragmented. This guide will help you strengthen your identity management system.
The Problem and Why It Matters Now
The legacy DoD system has documented issues: a fragmented directory architecture, an interoperability solution (FedHub) that causes "severe latency," authorization models that can't dynamically evaluate identity attributes, and workflows that compromise role separation. Check if your environment has similar problems. Look for multiple directories with no authoritative source, static group-based access, and admins who can both request and approve privileged changes.
The September 2027 deadline for the enterprise capability and the fiscal 2027 zero-trust maturity goal compress your timeline. Identity changes affect every downstream system, so start now.
What You Need Before Starting
- Identity Inventory: List every directory, IdP, PKI trust anchor, and federation connection. Include Non-Person Entities (service accounts, API clients, automation).
- Authoritative Attribute Sources: Identify which system owns clearance, citizenship, role, and employment status.
- Control Mapping: Refer to NIST SP 800-53 Rev 5 families (AC, IA, AU) or NIST SP 800-171 requirements in 3.1 and 3.5 if handling CUI under DFARS 252.204-7012.
- Boundary Documentation: Identify which systems are at Impact Level 5 versus IL6, and where identity assertions cross boundaries.
- Rollback Plan: DISA's solicitation requires no unscheduled downtime on downstream mission systems during transition. Hold yourself to the same standard.
Step-by-Step Implementation
1. Consolidate to an Authoritative Identity Source:
Choose one system of record per population (workforce, partners, NPEs). Export your directories and compare them:
# Example: find accounts present in secondary directory but not in the authoritative source
comm -13 <(sort authoritative_upns.txt) <(sort secondary_upns.txt) > orphaned_accounts.txt
Each orphan gets a disposition: migrate, disable, or delete. Document the decision for AC-2 evidence.
2. Enforce Phishing-Resistant Authentication:
Require Personal Identity Verification or equivalent hardware-backed credentials for privileged and remote access (IA-2, IA-2(1), IA-2(2)). Validate X.509 Certificate chains against your trust anchors and confirm Certificate Revocation List checking is enforced. Match authenticator strength to Authenticator Assurance Level requirements for each resource.
3. Replace Static Group Access with Attribute-Based Decisions:
Role-Based Access Control remains your baseline, but add attributes (clearance, device posture, location, session risk) to your policy engine so access is evaluated per request (AC-2(6), AC-3). Start with one high-value application. Write the policy in your IdP or policy decision point, then run it in audit-only mode before enforcement.
4. Separate Duties in Provisioning Workflows:
DISA's solicitation cites role-separation flaws as an audit weakness. Audit your own: nobody should both submit and approve an access request or elevation (AC-5). Query your ticketing or IGA system for requester-equals-approver records:
SELECT request_id, requester, approver
FROM access_requests
WHERE requester = approver;
Any rows returned are findings. Fix the workflow, then add a preventive rule.
5. Bring Non-Person Entities Under Governance:
Assign each Non-Person Entity an owner, a purpose, an expiration or review date, and credential rotation (IA-5, IA-9). Move static secrets to a vault and prefer short-lived certificates or tokens. Unowned NPEs are the fastest path to an unexplained lateral movement.
6. Cut Federation Latency and Failure Points:
Map every cross-boundary authentication path and measure round-trip time. Cache validated assertions within a policy-defined lifetime, deploy regional authentication endpoints where permitted, and eliminate chained redirects. Document each boundary crossing, since reviewers will ask.
7. Centralize Audit Logging:
Forward authentication, authorization, and privilege events to your SIEM (AU-2, AU-3, AU-6). Log the policy decision and the attributes evaluated, not just success or failure. That record proves your zero-trust decisions were actually dynamic.
8. Stage the Cutover:
Migrate application by application. Run old and new authentication paths in parallel, move low-risk systems first, and keep the legacy path live until each application passes validation.
Validation: How to Verify It Works
- Orphan Test: Re-run the directory diff. Expected result: zero undispositioned accounts.
- Revocation Test: Revoke a test certificate and confirm access is denied within your defined window. If it still works, your revocation checking isn't enforcing.
- Attribute Test: Change a test user's attribute (for example, mark a device noncompliant) and confirm access is denied mid-session or at next request.
- Separation Test: Attempt a self-approved privileged request. It must fail.
- NPE Sweep: List all service accounts with no owner or past-due review. Target is zero.
- Failover Drill: Take one authentication node offline during a maintenance window and confirm dependent systems stay up. This directly tests the no-unscheduled-downtime expectation.
- Evidence Packaging: Save outputs and screenshots mapped to control IDs. If you manage artifacts in Enterprise Mission Assurance Support Service or a CMMC Self-Assessment package, attach them there so assessors see proof, not assertions.
Maintenance and Ongoing Tasks
- Quarterly: Access recertification for privileged roles; NPE ownership review; CRL and trust anchor validation.
- Monthly: Review policy-engine denials and exceptions; investigate any standing exception older than its approved window.
- Per Change: Update your boundary and federation documentation, and re-run the separation and revocation tests after any IdP or workflow change.
- Continuous: Feed identity telemetry into Continuous Authorization or continuous monitoring reporting (CA-7), and track configuration against the applicable Security Technical Implementation Guide.
Don't claim zero-trust maturity or compliance for an identity capability until you've completed assessment and authorization. Until then, document what's implemented, what's partial, and what's planned, and keep the evidence current.





