They should define a repeatable entitlement model first, then require every custom connector to support request, approval, provisioning, audit, and removal in the same workflow. If the app cannot express entitlements cleanly, teams should treat it as an exception that needs compensating controls, not as a fully governed integration.
Why This Matters for Security Teams
Custom applications without standard connectors create a governance gap because entitlement management depends on the application exposing consistent request, approval, provisioning, review, and removal paths. If each app handles access differently, security teams lose the ability to prove who has access, why they have it, and whether it was removed on time. That is where excessive access, orphaned accounts, and audit failures usually begin.
Current guidance suggests treating entitlement design as a control problem, not a tooling problem. A repeatable model gives security teams a common language for access decisions across bespoke apps, which is essential when those apps also store secrets or service-account credentials. NHI Management Group notes in its Top 10 NHI Issues that poor lifecycle handling and over-privilege remain recurring weaknesses, and the same patterns appear in custom application estates. For broader control structure, NIST Cybersecurity Framework 2.0 reinforces access governance as a core operational discipline.
In practice, many security teams encounter entitlement sprawl only after an internal app is used for years without a clean offboarding path, rather than through intentional access design.
How It Works in Practice
The practical starting point is to define the entitlement model before trying to integrate the app. That means identifying the discrete access units the application can actually enforce, such as roles, project scopes, tenant memberships, API permissions, or administrative flags. Security teams should then map those units to a single workflow: request, approval, provisioning, logging, review, and revocation. If the app cannot support that lifecycle natively, the team should wrap it with compensating controls rather than calling it governed.
A useful pattern is to separate entitlement definition from connector implementation. The governance layer decides who should receive access and under what conditions, while the integration layer translates that decision into application-specific actions. That helps prevent every custom connector from inventing its own approval logic or naming scheme. Where possible, the connector should also expose an audit trail that records who approved access, when it was granted, whether it was time-bound, and when removal occurred. This is especially important for NHI-related access, where application permissions often outlive the workload that requested them.
The Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs is useful here because entitlement governance is inseparable from lifecycle control. For implementation structure, NIST SP 800-207 Zero Trust Architecture supports the idea that access should be continuously evaluated, not granted once and forgotten.
- Define a canonical entitlement catalog for the custom app.
- Require every access grant to have an approver, an expiry, and a revocation trigger.
- Log provisioning and removal in a format that supports audit and review.
- Use compensating controls for apps that cannot enforce least privilege cleanly.
These controls tend to break down when the application exposes only manual admin screens and no reliable API, because revocation and evidence collection become inconsistent.
Common Variations and Edge Cases
Tighter entitlement governance often increases engineering and operations overhead, so organisations must balance standardisation against the reality of legacy or bespoke code. In some environments, current guidance suggests that a partial model is better than none: for example, a custom app may support approvals and logging but not fine-grained role modelling. In that case, teams should document the limitation, restrict the population allowed to use the app, and apply stronger monitoring and periodic recertification.
Another common edge case is when the app manages both human and non-human access. That usually requires separate entitlement paths, because service accounts, API keys, and human user roles have different lifecycle needs. The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a useful reference when auditors ask for evidence that access is removable and reviewable, not merely approved. For control alignment, NIST Cybersecurity Framework 2.0 remains a practical baseline for access and governance evidence.
Best practice is evolving for custom connectors that cannot support automatic deprovisioning. Where there is no universal standard for this yet, organisations should treat manual removal as a high-risk exception, set short review intervals, and require an explicit owner for every entitlement that cannot be revoked through code.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Custom connectors often create unmanaged NHI entitlements and access drift. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed across custom application entitlements. |
| NIST AI RMF | GOVERN | Governance is needed to define accountability and control exceptions in bespoke integrations. |
Assign ownership for custom entitlement exceptions and document compensating controls under AI RMF governance.
