They should use parallel entitlement governance and recertification processes for systems that sit outside the directory boundary. Access packages can simplify internal administration, but they do not certify roles in every SaaS or on-prem environment. The right response is to separate convenience inside the directory from governance coverage across the estate.
Why access packages stop at the directory boundary
Access packages are a directory-native convenience layer: they streamline request, approval, and assignment inside the identity plane, but they do not automatically create governance coverage for every application in the estate. The practical test is whether the target system can actually consume the package’s entitlement model. If it cannot, teams need a separate control path for those external systems.
That distinction matters because many organisations mix directory-managed entitlements with SaaS admin roles, local application permissions, and legacy on-prem access. The governance question is not whether a user was approved once, but whether the entitlement was correctly represented, reviewed, and revoked in the system that actually enforces access.
Where the external application has its own role model, access reviews, or admin console, the directory process can be only one input to the broader control design. In practice, that means the internal request is useful for consistency, but the authoritative record for the external app still has to live where the permission exists.
How parallel entitlement governance should work
Teams should run parallel entitlement governance and recertification for systems outside the directory boundary, rather than trying to force all access through one package workflow. That usually means maintaining an application inventory, mapping business roles to system-specific entitlements, and defining a review cadence that matches the risk and change rate of each external platform.
A clean design separates request convenience from assurance. The access package can remain the front door for directory-scoped access, while external apps use their own approval, provisioning, and access review controls. That avoids the common failure mode where a package creates the impression of governance without actually proving who can do what in the target system.
For external systems, the control evidence should be specific to the application, not inferred from the directory. Teams need to be able to show current entitlement owners, last review dates, and revocation outcomes for those systems, especially where the app supports privileged functions or third-party collaboration.
When the estate includes many SaaS platforms, this is easier to operate if entitlement governance is standardised on a role catalogue and recertification schedule. The directory then becomes one governance channel among several, not the only one, which is the right model when application boundaries do not align with identity boundaries.
What good practice looks like when access packages are not enough
The strongest pattern is to treat the access package as the intake and coordination layer, while the external application remains the source of truth for enforcement and certification. That means each non-directory system should have a named owner, a defined entitlement inventory, and an explicit review process for joiners, movers, leavers, and privileged access.
Teams should also define a decision rule for exceptions: if an application cannot be represented accurately in the package model, do not stretch the package to cover it. Use the package for request routing if helpful, but keep the actual approval and recertification in the target system or its governance workflow. That is particularly important for systems with sensitive data, delegated admin, or complex role hierarchies.
Parallel governance works best when it is operationally visible. A team should be able to answer three questions quickly: which external applications sit outside package coverage, who certifies their entitlements, and when the last review found and removed stale access.
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 | AC-2 — Account Management | External app entitlements need governed assignment and review. |
| AC-6 — Least Privilege | Package gaps often leave overbroad app permissions unchecked. | |
| IA-5 — Authenticator Management | External systems often depend on separate credential lifecycle controls. | |
| Recommendation — Tie each external entitlement to governed assignment, review, and timely revocation. Limit external application access to the minimum role needed. Track and rotate credentials used by non-directory applications. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | The question is about access governance across systems outside one boundary. |
| A.5.18 — Access rights | Recertification and revocation of external entitlements are central here. | |
| Recommendation — Define access control rules that cover both directory and external applications. Review and revoke external access rights on a defined schedule. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Managing access across non-directory apps requires consistent control of permissions. |
| Recommendation — Centralize access control management for apps that sit outside package coverage. | ||
Practitioner Guidance
What to prioritise: Identify the systems that cannot inherit package-based governance and classify them by risk, change frequency, and privileged access. The highest-priority gaps are usually apps with direct business impact, broad admin rights, or weak revocation discipline.
What to verify: Confirm that every external application has an owner, an entitlement source of truth, and a recertification trail. If the only evidence is that the user was approved in the directory, the control is incomplete.
Common mistake: Treating a successful access package request as proof that access is governed everywhere. Convenience in the directory is not the same as assurance in the downstream system.
Practitioner takeaway: Use access packages to simplify intake, but use application-native entitlement governance to prove ongoing access correctness outside the directory boundary.
Related resources from NHI Mgmt Group
- How should security teams run access reviews for non-human identities?
- How should security teams govern non-human identities that have persistent access?
- How should security teams govern API keys used for generative AI access?
- What is the difference between protecting applications and protecting access?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org