How should teams govern access to homegrown applications that do not support standard IGA integrations?

Why This Matters for Security Teams

Homegrown applications that cannot plug into standard IGA often become the quiet exceptions where access reviews, revocation, and ownership drift out of control. That is risky because the application may still hold privileged secrets, service accounts, or write access to sensitive data, even if it never appears in the main identity stack. NHI Management Group’s Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of gap these systems create.

The right response is not to exempt the app from governance, but to make the governance model fit the app’s constraints. That means identifying who approves access, what actually grants access, how revocation works, and what evidence proves the control is working. The NIST Cybersecurity Framework 2.0 is useful here because it pushes teams toward asset visibility, control ownership, and repeatable risk treatment rather than tool-specific assumptions. In practice, many security teams discover the real access path only after a departing employee, failed audit, or incident forces a manual scramble.

How It Works in Practice

Start by treating each non-integrated application as a governed control surface. Map four things for every app: entitlement source, review owner, revocation path, and evidence source. If the application has no native connector, use the simplest pattern that still gives current-state visibility and a way to change access. That may be a database table, an admin console export, a scheduled report, or a lightweight API wrapper that reads and writes entitlements.

Then decide whether the app should sit in a manual control process or a semi-automated one. Current guidance suggests the control must be enforceable, not just documented. A manual review spreadsheet is not enough unless it is tied to a real revocation action and a dated audit trail. For broader NHI governance, the OWASP Non-Human Identity Top 10 is a useful lens for spotting where secrets, service accounts, and stale privilege are likely to accumulate. NHI Mgmt Group also recommends pairing this with lifecycle discipline from the Lifecycle Processes for Managing NHIs section of the Ultimate Guide to NHIs.

• Assign a named business and technical owner for every entitlement.
• Record where the access is created, updated, and revoked.
• Use a recurring review cadence that matches the risk of the app, not the convenience of the team.
• Require evidence of revocation, not just evidence of review.
• Escalate systems with no enforceable revocation path into tracked exception management.

If the app supports only partial visibility, use that as an interim control, but do not mistake it for complete governance. These controls tend to break down when the application stores permissions in code, local files, or ad hoc admin records because the source of truth is fragmented and revocation cannot be verified cleanly.

Common Variations and Edge Cases

Tighter control over homegrown apps often increases operational overhead, so teams must balance access assurance against the cost of retrofitting legacy software. That tradeoff is especially visible in apps built by small internal teams, where the original author is gone and no formal entitlement model ever existed. Best practice is evolving, but there is no universal standard for this yet: some organisations accept manual review plus break-glass revocation, while others require a thin connector or custom API before any privileged access is approved.

Edge cases matter. Read-only applications may need only periodic attestation, while systems that can change financial records, production data, or security settings need stronger evidence and shorter review cycles. If a system exposes secrets directly in config or code, the access problem is no longer only about user entitlements; it is also a secret-management issue tied to broader NHI risk. NHI Mgmt Group’s Top 10 NHI Issues and the breach patterns discussed in 52 NHI Breaches Analysis show why invisible service access and poor offboarding remain recurring failure points.

Where a connector cannot be built, the fallback should be a tracked manual process with explicit risk acceptance, review dates, and a retirement plan. Anything less turns a known exception into an unmanaged one.

Related resources from NHI Mgmt Group

• How should security teams govern DNS records that support authentication and service access?
• How should security teams govern policy-based access control across multiple applications?
• How should security teams govern access reviews when large parts of the environment are outside IGA scope?
• How should security teams govern non-human identities that have persistent access?