Treat custom applications as first-class identity targets and require them to participate in the same lifecycle and certification process as standard systems wherever possible. If they cannot, the exception should be explicit, risk-owned, and time-bound rather than left as a permanent manual workaround.
Why This Matters for Security Teams
Custom applications are often where identity governance slips out of policy and into exception handling. When a system cannot consume standard integrations, teams may leave credentials in code, reuse shared service accounts, or rely on manual approvals that never expire. That creates an identity surface that is harder to inventory, rotate, and revoke, especially when the app sits outside normal onboarding and offboarding processes. NHI Mgmt Group’s Lifecycle Processes for Managing NHIs frames this as a lifecycle problem, not just a tooling problem.
The risk is not theoretical. NHI Mgmt Group reports that 71% of NHIs are not rotated within recommended time frames, which is exactly the pattern custom applications tend to worsen when they resist automation. The better governance question is not whether the app is standard, but whether its identity, secrets, and access paths are certifiable, reviewable, and removable. In practice, many security teams encounter compromise only after a custom integration becomes the longest-lived exception in the environment, rather than through intentional review.
How It Works in Practice
Governance starts by treating the custom application as a first-class identity target. That means assigning an owner, defining its purpose, documenting what secrets or tokens it uses, and requiring a control path for issuance, review, rotation, and revocation. If the application cannot integrate with the normal platform, the exception should still map to the same lifecycle expectations described in the Top 10 NHI Issues: visibility, credential hygiene, and offboarding.
A practical model usually includes:
- Registering the application in the identity inventory with a named business and technical owner.
- Requiring secrets to be stored in a managed vault, not in source code, scripts, or configuration files.
- Setting explicit TTLs for tokens, API keys, and certificates so exceptions are time-bound.
- Recording compensating controls such as network restriction, scoped permissions, and monitoring for unusual use.
- Reviewing the exception on a fixed cadence and forcing renewal or retirement decisions.
Where possible, use the same policy language and control objectives that govern standard systems. The NIST Cybersecurity Framework 2.0 is useful here because it keeps the focus on governance, protection, detection, and recovery rather than on a specific integration method. That makes it easier to justify a manual control only when automation genuinely is not possible. These controls tend to break down when the custom app is owned by a development team with no operational offboarding process, because the exception survives longer than the application change cycle.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, so organisations have to balance velocity against control certainty. Some custom applications are too old, too brittle, or too vendor-constrained to support modern federation, so current guidance suggests using a documented exception rather than forcing a brittle integration that will fail silently. The exception should be explicit, risk-owned, and time-limited, not a permanent workaround.
There is no universal standard for every legacy pattern, but the decision logic is consistent. If a system cannot join normal identity workflows, then compensating controls must become stronger, not weaker. That usually means shorter credential lifetimes, more frequent attestation, tighter blast-radius limits, and stronger evidence collection for audit. NHI Mgmt Group’s Regulatory and Audit Perspectives is a useful reference when teams need to justify why a manual path exists and how it will be retired. Best practice is evolving, but the core rule is stable: if the app resists standard integration, governance must resist permanent exception drift.
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-03 | Custom apps often fail rotation and revocation discipline. |
| NIST CSF 2.0 | PR.AC-4 | Access control governance applies to nonstandard applications too. |
| NIST AI RMF | GOVERN | Governance requires ownership, accountability, and exception oversight. |
Map each custom app exception to least-privilege access and review it as part of access management.
Related resources from NHI Mgmt Group
- How should security teams govern social media accounts that do not support standard IAM integration?
- How should security teams govern entitlements in custom applications that lack standard connectors?
- How do identity teams govern direct role changes made inside applications?
- How should organisations govern software licence data when records are inconsistent?
