Identity governance and administration for defense organizations

Identity governance and administration (IGA) is the discipline of systematically controlling who has access to what, for how long, and on what authority — and producing auditable evidence that access is appropriate at every point in time. In a commercial organization, IGA manages roles, entitlements, and periodic reviews across an HR-driven employee lifecycle. In a defense organization, IGA must do all of that and simultaneously enforce a second access-control lattice built from security clearance levels, compartment memberships, need-to-know determinations, and program authorizations. The gap between those two problem statements is where most commercial IGA deployments fail when transplanted into defense. This article addresses the engineering decisions that close that gap — covering clearance-aware provisioning, role engineering for multi-classification estates, segregation of duties under small-team constraints, access certification design, CAC/PIV integration, and the audit trail architecture required to survive an RMF accreditation. For the credential-brokering layer that IGA depends on at privileged access time, see our coverage of privileged access management for defense.

Why IGA in defense differs from enterprise — clearance levels as an additional access dimension, compartment management, need-to-know enforcement

In a commercial enterprise, access control has two meaningful dimensions: who the user is (identity) and what role or group they belong to (entitlement). A defense organization adds a third dimension that is orthogonal to both: what the user is cleared and authorized to access. A senior network engineer may hold a valid SECRET clearance but have no authorization to access the intelligence compartment running on the same SECRET-level network. A junior analyst may be cleared to TOP SECRET and specifically read into a compartment that the senior engineer is not. Neither seniority nor organizational hierarchy resolves these decisions — only the formal authorization record does.

Commercial IGA platforms — SailPoint IdentityNow, Saviynt, Omada, One Identity — are designed for the two-dimensional problem. They can store custom attributes, and with sufficient customization they can enforce clearance-level constraints, but they do not natively model compartments, handling caveats, or program-access authorizations as first-class objects. The platform will let you add a custom attribute called "clearance_level" and write a provisioning rule that checks it. The platform will not, without custom development, maintain a live feed from a personnel security system, resolve the difference between a formal SCI indoctrination record and a self-reported clearance claim, or model the lattice of compartments with their own read-in and read-out workflows.

Need-to-know enforcement is the sharpest difference. In enterprise IGA, access is typically granted to a resource class — "this user can access the Finance data lake." In defense, access to the same resource may be granted to User A but not User B even though both hold the correct clearance, because User B has not been formally read into the program that produces the data. IGA must enforce this at provisioning time and at recertification time, querying authoritative program-access records rather than relying on a manager's attestation. The gap between "my manager approved my access" and "the authoritative record confirms I am read into this program" is exactly the gap that produces audit findings and, in the worst cases, unauthorized disclosures.

The practical implication is that a defense IGA deployment requires connector development and workflow customization beyond what any off-the-shelf IGA product ships with. Budget for this upfront, treat the clearance and compartment data feeds as the most critical integration work in the project, and consider whether the existing commercial product can be extended to meet the requirement or whether a defense-specific IGA solution (such as those built on the IC's enterprise identity service architecture) is the right starting point. The zero trust for defense software model depends on IGA providing accurate, continuously validated entitlement data — without it, policy engines are making authorization decisions on stale or unverifiable identity attributes.

The joiner-mover-leaver lifecycle in a classified environment — automated provisioning triggers, clearance verification integration, role transitions on reassignment

The joiner-mover-leaver (JML) lifecycle is the foundational operational loop of any IGA deployment. In defense, every phase of the loop has additional constraints that slow it down but also make it more consequential to get wrong.

Joiner workflow. A joiner event fires when an authoritative HR or personnel system creates a new record — new hire, new contractor, new temporary assignment. In defense, provisioning must not begin until the IGA platform has independently confirmed the individual's adjudicated clearance level from the personnel security system (JPAS or DISS in the US DoD context; national equivalents in allied defense organizations), and confirmed a valid CAC or PIV card DN from the enrollment system. The sequence matters: the clearance check gates the provisioning, not the other way around. An IGA platform that provisions an account first and then checks clearance in a background job has already created an exploitable window.

The joiner workflow should also fire a compartment-access check for any entitlement that requires formal read-in to a program. If the read-in record exists in the authoritative program-access system, provisioning proceeds. If it does not, the entitlement is suppressed and a workflow item is created for the security officer to initiate the formal indoctrination process. The account exists; the sensitive entitlement does not, until the paper record exists to justify it.

Mover workflow. Reassignment in defense organizations is frequent and consequential. A person moving from one program to another typically loses access to the first program's systems and gains access to the second's. The IGA mover workflow must resolve this transition deterministically: compute the entitlement delta between the old role set and the new, revoke what is no longer appropriate, and provision what is newly warranted — all gated by the same clearance and compartment checks. Where the new role requires a higher clearance than the individual currently holds, the account for that classification domain is suppressed pending a clearance upgrade determination.

The harder mover case is temporary duty (TDY) or secondment. The individual retains their home-unit role set and acquires a time-bounded supplemental role set for the duration of the assignment. IGA must model this without giving the person permanently elevated access that survives the end of the assignment. Time-bounded role grants with automatic expiry, reviewed by both the home-unit and host-unit security officers, are the correct pattern.

Leaver workflow. The leaver workflow — triggered by termination, end-of-contract, retirement, or clearance revocation — is the highest-stakes phase and the one where commercial IGA deployments most commonly fall short in defense. The expectation is same-day de-provisioning for all accounts across all connected systems, irrespective of whether the individual has physically returned their CAC, logged off their workstation, or completed any HR checkout process. The IGA platform must not wait for an HR record to reach "terminated" status before revoking access — the clearance revocation event from the personnel security system is the trigger, and it must propagate in near-real-time.

# Leaver workflow SLA targets (defense context)
clearance_revocation_to_AD_disable:   < 1 hour
AD_disable_to_all_app_deprovisioning: < 4 hours
CAC_invalidation_propagation:         < 1 hour (DEERS → connected systems)
audit_closure_record_generated:       same business day
physical_access_revocation:           same day (physical security system integration)

Role engineering for multi-classification environments — role model design, clearance-scoped role sets, attribute-based vs role-based hybrid for compartments

Role engineering — the process of defining and maintaining the role model that the IGA platform enforces — is the most time-consuming part of a defense IGA deployment and the one most likely to produce persistent technical debt if done poorly. The fundamental constraint is that roles must be stable across organizational changes, because every role change in the IGA platform is an administrative event that requires change control, re-testing, and potentially a recertification campaign.

The first design decision is domain separation. Defense organizations operate across multiple classification domains — at minimum UNCLASSIFIED and SECRET, often also TOP SECRET and one or more SCI enclaves. Roles must be defined within each domain separately and stored in separate directory instances. A role named "analyst" in the UNCLASSIFIED domain and a role named "analyst" in the SECRET domain are not the same role — they carry different entitlements, different clearance prerequisites, and are managed by different security officers. Conflating them into a single cross-domain role is an architectural mistake that accreditors will find immediately and that creates real risk of cross-domain entitlement leakage.

Within each domain, roles should be functional rather than organizational. An organizational role — "member of 3rd Squadron Intelligence Cell" — is stable only as long as the organization is. A functional role — "intelligence analyst, classified systems" — travels with the person's function across organizational boundaries and survives the reorganizations that happen every eighteen months in most defense environments. Functional roles also compose more cleanly: a person with a dual role (analyst and section administrator) gets two functional roles, each independently managed and certified.

Compartment management requires an attribute-based access control (ABAC) layer on top of the RBAC foundation. The role establishes what the person can do; the compartment attributes on their identity record establish what they can see while doing it. This hybrid model — RBAC for structural entitlements, ABAC for data-level filtering — is the architecture that scales to the complexity of a real defense organization without requiring a new role every time a new compartment is created.

# Identity attribute schema (simplified)
{
  "dn": "CN=J.Smith,OU=SECRET,DC=mil",
  "clearance_level": "SECRET",
  "compartments": ["ALPHA", "BRAVO"],
  "programs": ["PGM-001", "PGM-004"],
  "roles": ["intelligence-analyst-s", "portal-user-s"],
  "card_dn": "CN=SMITH.JANE.1234567890,OU=DoD,O=U.S. Government,C=US",
  "clearance_expiry": "2028-03-15",
  "last_certified": "2026-04-01"
}

Role lifecycle management — adding, modifying, and retiring roles — requires a separate governance process from user lifecycle management. New roles should require security officer approval, an entitlement impact analysis, and a test-environment validation before promotion to production. Retired roles require a migration plan that moves current role-holders to replacement roles before the old role is removed, preventing orphaned entitlements in connected systems.

Segregation of duties in defense programs — SoD rule design for acquisition and sustainment, compensating controls for small team exceptions

Segregation of duties (SoD) is the control principle that no single individual should hold both sides of a high-risk transaction — the ability to both initiate and approve a financial obligation, or to both request and grant their own access, or to both write and certify a software release. In defense acquisition and sustainment environments, SoD failures have produced some of the most costly fraud and mismanagement cases on record: a contracting officer who could also certify invoice payments; a system administrator who could modify both application code and its access controls; a logistics manager who could both order and certify receipt of materiel.

IGA enforces SoD through a rule set that identifies conflicting entitlement pairs and prevents any single identity from holding both. The rule set must be designed with the specific high-risk workflows of defense acquisition in mind, not borrowed from a commercial financial-services template. Key conflict pairs in defense contexts include:

• Contract initiation and contract approval (procurement SoD)
• Access request submission and access approval (IAM SoD)
• Code commit and code deployment authorization (DevSecOps SoD)
• Cryptographic key generation and key custodian certification
• Asset disposal authorization and asset receipt certification
• Financial obligation entry and obligation certification

The engineering challenge in defense is that many programs run with very small teams — sometimes fewer than ten cleared personnel covering all roles. An SoD rule that requires two different people to hold the conflicting entitlements may be unenforceable in a three-person forward-deployed detachment. The correct IGA response is not to disable SoD rules for small teams; it is to implement a structured exception workflow with compensating controls.

A compensating control for an SoD exception should include: documented risk acceptance signed by the authorizing official; an enhanced audit flag on all transactions executed by the exception holder, so every such transaction is surfaced in the next compliance review; a mandatory secondary-review requirement (the transaction is complete but a second cleared individual must review and countersign within a defined time window); and a sunset date on the exception that triggers re-evaluation rather than silent perpetuation.

SoD rules also surface during access certification campaigns. When a recertification reviewer approves access for someone who holds a conflicting entitlement pair, the IGA platform should present the conflict visibly and require an explicit override decision rather than silently allowing the approval. Every override is recorded as a certification exception in the audit trail, ensuring that the accreditor can see not just what access exists but what SoD conflicts were knowingly accepted and by whom.

Access certification campaigns — campaign frequency for classified system access, automated reviewer assignment by supervisor chain, batch vs risk-based recertification

Access certification is the periodic process of presenting every user's current entitlements to a responsible reviewer for attestation that the access remains appropriate. In defense, it is also the primary mechanism by which an organization demonstrates continuous compliance with AC-2 and related controls — the accreditor's question "can you show me that all access on this system is currently authorized?" is answered by the certification campaign record.

The minimum NIST 800-53 AC-2(j) floor requires annual review of all accounts, but defense practice and most accreditation guidance expects more. A practical campaign schedule for classified systems:

• Quarterly: privileged accounts (system administrators, security officers, service accounts with elevated rights), accounts on cross-domain solutions, cryptographic key management systems, and intelligence repositories
• Semi-annual: all user accounts on SECRET and above systems; accounts with access to financial obligation and contracting functions
• Annual: UNCLASSIFIED system accounts; read-only accounts with no write or privileged capability
• Event-driven: any account belonging to an individual who changes role, program, or unit; any account on a system that completes a major change; any account where a clearance renewal or upgrade/downgrade has occurred

Automated reviewer assignment is critical in defense environments where organizational structures change frequently and the IGA platform cannot depend on a static reviewer mapping. The correct source of reviewer assignment is the authoritative supervisor chain from the HR system — when the IGA platform generates a certification campaign, it queries the current supervisor record for each identity and assigns review to that supervisor. Where the supervisor position is vacant (a common occurrence in deployed environments), the chain escalates to the next-level supervisor automatically, with a defined escalation timeout that triggers a security officer override.

Batch certification — presenting all entitlements for a user population at once — is appropriate for the semi-annual and annual campaigns where the goal is a comprehensive review. Risk-based certification is preferable for high-frequency reviews: rather than presenting a privileged user's entire entitlement set every quarter, the IGA platform identifies which entitlements have changed, which have been used (and which have not), and which carry SoD conflicts, and presents only those for focused review. Unused entitlements — a privileged role granted six months ago that has never been exercised — are the highest-value finding from a risk-based campaign; they represent access that exists on paper but costs the organization nothing to revoke, and removing them immediately reduces the attack surface documented in the insider threat detection defense risk model.

Campaign completion rates are a lagging indicator of program health. A campaign that achieves 95% completion with 5% exceptions is defensible. A campaign that achieves 60% completion because reviewers ignored the notification is an audit finding waiting to happen. IGA platforms should escalate uncompleted reviews through the supervisor chain with increasing urgency, and security officers should have dashboard visibility into campaign completion rates in real time rather than discovering a completion problem at the campaign deadline.

Integration with HR, identity providers, and CAC/PIV — integration architecture for DoD/NATO PKI, CAC/PIV-linked provisioning, real-time clearance revocation propagation

The integration architecture for a defense IGA platform is more complex than any commercial deployment because it spans multiple authoritative systems that do not share a common API contract, operate at different classification levels, and are owned by different organizations.

The identity anchor in the US DoD context is the Common Access Card (CAC). Every active-duty military member, reservist on duty, and most civilian and contractor employees carry one. The CAC contains three PKI certificates (identity, email, and content-signing) whose distinguished names serve as the stable, authoritative identifier for the person across all connected systems. The IGA platform's account model must be built around the CAC DN, not around an email address or employee ID, because those can change while the CAC DN remains stable across card renewals.

CAC issuance and renewal data flows from the Defense Enrollment Eligibility Reporting System (DEERS) through the Real-time Automated Personnel Identification System (RAPIDS). The IGA integration with DEERS/RAPIDS provides three critical events: card issuance (triggers account activation), card renewal (triggers DN update propagation to all connected systems), and card revocation (triggers immediate account suspension). The revocation propagation must be near-real-time — a revoked CAC that still grants system access for 24 hours because the IGA platform polls DEERS once a day is a compliance failure and a security incident waiting to happen. The target is sub-hour propagation for revocation events, achieved through event-driven webhooks or a high-frequency delta-sync feed rather than batch polling.

Clearance revocation propagation has the same requirement. The flow is: personnel security officer revokes clearance in JPAS/DISS → IGA platform receives event → all accounts at the revoked clearance level and above are suspended → connected systems propagate the suspension through their own IGA connectors. The IGA platform is the orchestration layer; each connected system is responsible for enforcing the suspension through its own access controls, not relying on the IGA platform to individually call each system's API.

For allied defense organizations operating under NATO PKI, the integration architecture follows the same pattern with national PKI CAs rather than DoD PKI. The IGA platform must trust the appropriate national trust anchor and parse the DN structure of the national PKI certificates, which differs from the DoD format. Cross-domain scenarios — a US liaison officer operating on a partner nation's network — require federation across trust anchors, typically implemented through a PKI bridge or a mission-specific federation agreement that the IGA platform translates into a temporary identity binding.

# IGA integration topology
HR system (DCPDS / SAP) ──→ [IGA platform] ←── Personnel security (JPAS/DISS)
                                   ↑
DEERS/RAPIDS (CAC events) ─────────┘
                                   ↓
           ┌───────────────────────┼───────────────────────┐
           ↓                       ↓                       ↓
   AD (UNCLASSIFIED)        AD (SECRET)           AD (TS/SCI)
           ↓                       ↓                       ↓
   App connectors           App connectors         App connectors
   (NIPR systems)           (SIPR systems)         (JWICS systems)

Audit trails and compliance reporting — NIST 800-53 AC/IA controls, audit log requirements for classified system access, generating compliance evidence

The audit trail produced by an IGA platform is the primary evidence artifact for the access-control and identification-and-authentication control families in a NIST 800-53 assessment. Getting this right is not optional — it is the difference between an accreditation package that demonstrates continuous compliance and one that triggers a Plan of Action and Milestones (POA&M) for every access-control finding.

The IGA audit log must capture every provisioning and de-provisioning event at the transaction level. Each record should contain: the identity affected, the entitlement granted or revoked, the time of the event, the authority under which the event was executed (automated workflow, manager approval, security officer override, or certification campaign decision), and a stable reference to the source event that triggered the action (the HR record change, the clearance event, the certification decision). This level of detail supports three distinct audit use cases: reconstruction of the access state at any historical point in time, investigation of a specific access event, and aggregate compliance reporting across the user population.

The NIST 800-53 controls most directly evidenced by IGA audit data are:

• AC-2 (Account Management): IGA lifecycle records demonstrate that accounts are created only for authorized individuals, reviewed at defined frequencies, and disabled when individuals depart
• AC-5 (Separation of Duties): SoD rule enforcement logs and exception records demonstrate that conflicting duties are identified and managed
• AC-6 (Least Privilege): Role engineering records and unused-entitlement analysis from certification campaigns demonstrate that access is scoped to the minimum necessary
• IA-2 (Identification and Authentication): CAC/PIV binding records demonstrate that multi-factor authentication is enforced for all user accounts on classified systems
• IA-4 (Identifier Management): Joiner and leaver records demonstrate that account identifiers are assigned and disabled under a defined management process
• IA-5 (Authenticator Management): Card-binding and card-revocation propagation records demonstrate that authenticators are managed and revoked in a controlled, timely manner

Compliance reporting from the IGA platform should be designed to produce pre-formatted evidence packages, not raw log exports. An accreditor asked to evaluate AC-2 should be able to receive a report showing all active accounts, the date each was last reviewed, whether any are overdue for certification, and a count of exceptions — not a 500,000-row event log and a request to "parse it yourself." Designing these reports before the first accreditation review, and validating that the reports accurately reflect the control implementation, is the difference between a two-day evidence-collection process and a two-week crisis.

Audit log immutability requires write-once storage or cryptographic hash-chaining. Defense retention requirements for classified system access logs typically run 3–7 years depending on the system's mission and classification level; some nuclear-adjacent and strategic systems carry longer retention requirements. The storage tier must be sized and lifecycle-managed accordingly, with retrieval procedures that function when the original software stack is no longer supported. A retention requirement that is satisfied on day one but produces unreadable logs in year six is a compliance failure on the timeline that matters.