Direct access is granted explicitly, such as through a request or just-in-time approval, while indirect access comes through groups or access rules. The difference matters because indirect access can persist or change without a user ever submitting a new request, which makes lineage and review more important.
How direct access differs from indirect access in JML
Direct access is the cleanest form of entitlement because there is an explicit request, approval, and assignment path tied to the person’s joiner, mover, or leaver state. Indirect access is inherited through a group, role, policy, or rule, so the user may receive or lose access without a fresh request each time the underlying membership changes.
The practical difference is not just administrative, it changes how you prove why access exists. Direct access is easy to point to in a request trail, while indirect access often requires tracing the parent group, role, or rule that produced the entitlement. That is why JML governance has to treat effective access, not just assigned access, as the audit object.
In mature IAM and IGA Basics, direct access is usually handled as a discrete entitlement, while indirect access is managed as part of the access model itself. That distinction matters when you are deciding whether a mover event should remove one entitlement or recalculate an entire role or group structure.
Why indirect access is harder to govern in JML
Indirect access is more operationally efficient, but it is also more opaque. A user can retain access after moving teams, changing duties, or leaving a business process if the group membership or rule that grants access is not updated at the same time.
It also creates a lineage problem. The access may be valid today because of one group membership, but tomorrow that same membership may be inherited from a different role path or automated rule, which makes recertification and root-cause analysis harder. Effective governance depends on knowing both the resulting permission and the mechanism that produced it.
That is why a good Joiner-Mover-Leaver (JML) Guide treats indirect access as something to recalculate, not just something to record. If the access model is based on groups or roles, the JML event should trigger validation of inherited entitlements, not just the explicit ones on the user record.
What this means for reviews, recertification, and cleanup
Direct access is usually reviewed at the entitlement level, because the approval path is tied to the specific grant. Indirect access requires a broader review lens, because one group or role change can affect many permissions at once, and one permission may be shared by many users through the same inheritance path.
For that reason, access reviews should confirm whether the entitlement is direct, inherited, or both. If the reviewer only sees the effective permission and not the source, they may rubber-stamp a valid-looking access state that is actually rooted in stale group membership, excessive role scope, or a leaver who was never fully detached from inherited access.
Practitioners often find value in pairing JML with Access Reviews and Certification Guide because indirect access only becomes manageable when review evidence includes source, scope, and business justification. Where role structure itself is driving the inheritance, Role Mining and Role Design Guide is the better companion for reducing hidden inheritance and role sprawl.
Risk and Threat Considerations
Indirect access increases exposure when entitlements persist after a move or departure, because the access path can survive even when the person no longer needs it. The main risk is not the inheritance mechanism itself, but the fact that it can hide stale access behind apparently legitimate group or role membership.
Failure mechanism: A joiner, mover, or leaver event updates the user record, but the inherited group, role, or policy is left intact, so the user keeps access through a source entitlement that is no longer appropriate.
Impact: Excess privilege, orphaned access paths, and slower detection of unauthorized retention become more likely, especially when many permissions are inherited from a small number of parent groups.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | JML access changes often depend on credential lifecycle and revocation. |
| AC-2 — Account Management | JML governance is fundamentally about account and entitlement changes over time. | |
| AC-6 — Least Privilege | Direct and indirect access both need privilege minimisation to limit inherited excess. | |
| Recommendation — Revoke or reissue authenticators when a joiner, mover, or leaver event changes access. Track and update accounts and inherited access when employment or role status changes. Limit both explicit and inherited permissions to the minimum required for the role. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | JML requires control over who receives and retains access, including inherited access. |
| Recommendation — Define rules for granting, changing, reviewing, and removing access through the JML process. | ||
| CIS Controls v8 | CIS-5 — Account Management | JML is an account lifecycle and entitlement governance problem. |
| Recommendation — Maintain and review account access so inherited permissions do not persist after role changes. | ||
Practitioner Guidance
What to verify: For every JML change, confirm both the explicit grant and the inheritance source. If a user still has access after a move, the question is not only “what do they have?” but “where is it coming from?”
Decision rule: If the access was granted directly, remove or reapprove it per the event. If it is indirect, recalculate the parent group, role, or rule first, then validate the resulting effective access before closing the case.
What practitioners underestimate: Indirect access is often the harder control problem because it looks cleaner in the request system than it is in the entitlement graph. The best JML programs manage lineage, not just assignments.
Practitioner takeaway: Direct access is governed at the grant level, but indirect access must be governed at the source-of-truth level, or JML will miss the permissions that survive by inheritance.
Related resources from NHI Mgmt Group
- What is the difference between role-based access and API key governance for NHI security?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
- What is the difference between human IAM controls and NHI governance?