Secrets Management vs Identity Governance

Most organisations that have invested in Non-Human Identity security have a secrets manager. They have centralised where credentials are stored, eliminated some of the worst hard-coding practices, and provided developers a structured way to retrieve secrets at runtime. This is progress — and it is not enough. A secrets vault is storage infrastructure. Identity governance is a programme. Conflating the two leaves the most consequential NHI risks unaddressed, because the vault has no opinion about whether the identity behind the credential should still exist, what it should be allowed to do, or who is accountable for it.

What Secrets Management Actually Does

Secrets management platforms — HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, CyberArk Conjur — solve a specific set of problems: centralising secret storage, controlling access to retrieval, enabling rotation, and providing an audit log of who retrieved what. These are genuine security improvements over the alternatives: hard-coded credentials in source code, plaintext environment variables, shared password spreadsheets maintained by operations teams.

The vault model works well for the secrets it knows about. It enforces retrieval controls, generates rotation events, and surfaces access patterns. What it does not do: discover secrets that were never put into it, assess whether the applications consuming stored secrets still have a legitimate need for the access those secrets grant, identify credentials whose consuming application has been decommissioned, or enforce any opinion about the scope of permissions that a secret authorises. The vault stores the credential faithfully — it has no visibility into, and no authority over, what that credential can do.

This is not a criticism of secrets management platforms — it is a description of their design intent. They were built to solve the storage and rotation problem, and they solve it well. The governance layer — who owns each NHI, what it should be allowed to do, and when its access should end — is a programme problem, not a tooling problem.

What Identity Governance Adds

Identity governance and administration (IGA) programmes for human identities cover a well-understood set of controls: access certification (periodic review of whether each user's access is still appropriate), lifecycle management (provisioning on hire, modification on role change, deprovisioning on departure), role-based access control (defining the standard access profile for each function), and separation of duties enforcement (preventing any individual from holding access combinations that create fraud risk). These controls exist because access for human identities is dynamic — it changes as people move through organisations — and because human identities face external accountability (employment law, audit obligations, regulatory requirements) that creates incentives for governance.

Non-Human Identities require the same governance framework applied to a different lifecycle. A service account is provisioned when a project begins — the equivalent of a new hire. Its access should be scoped to the minimum required for its function — the equivalent of role-based access control. It should be reviewed periodically to confirm the application it supports is still active and the access it holds is still appropriate — the equivalent of access certification. And it should be deprovisioned when the project ends — the equivalent of offboarding.

IGA platforms are beginning to extend natively to NHI. SailPoint, Saviynt, and Omada now offer NHI management modules that bring service accounts, API keys, and OAuth grants into the same governance workflows used for human identities — including automated discovery, owner assignment, access review campaigns, and lifecycle event triggers. The convergence of human and non-human identity governance into a single programme is the architectural direction the industry is moving toward, for the obvious reason that the governance principles are identical even if the underlying credentials differ.

Access Certification for Non-Human Identities

Access certification — the periodic review process where access owners confirm that each identity's permissions remain appropriate — is one of the highest-value governance controls for NHI because the population of orphaned or over-privileged machine identities is so large in most enterprises. The challenge is ownership: many NHIs have no documented owner because they were created informally, the original owner has left, or ownership was never recorded at provisioning time.

Effective NHI access certification programmes solve the ownership problem first: every NHI requires an assigned owner before it can be included in a certification cycle. For the large population of NHIs with no current owner, the assignment process itself is the highest-priority remediation activity — it forces a review of whether the identity is still needed and who is accountable for it. Identities that cannot be assigned to any current owner are strong candidates for immediate revocation, because the absence of an accountable owner is itself evidence of orphan status.

Certification frequency for NHIs should reflect the risk profile of the access they hold. NHIs with privileged access to production systems or sensitive data stores warrant quarterly review at minimum. Lower-privilege NHIs with read access to non-sensitive systems can be reviewed annually. The certification process should ask two questions: is the consuming application still active, and is the access scope still the minimum required? A "yes" to both extends the credential for another cycle; a "no" to either triggers immediate remediation.

Lifecycle Integration: Where Governance Becomes Operational

The highest-maturity NHI governance programmes integrate identity lifecycle events into the automated workflows that trigger provisioning and deprovisioning for human identities. When a project is closed in the IT service management system, deprovisioning workflows fire for both the human team members and the NHIs associated with that project. When a vendor contract is terminated, offboarding automation revokes both the vendor's human user accounts and the API credentials and OAuth grants that vendor's applications hold. When an application is decommissioned in the service catalogue, its service accounts and API keys are revoked automatically rather than requiring a separate manual step that is reliably forgotten.

Building these integrations requires the infrastructure of identity governance — an NHI inventory, an ownership model, and a lifecycle state machine — plus the integrations between your ITSM platform, your IGA platform, and your secrets manager. The secrets manager executes the revocation; the IGA platform decides when revocation is warranted; the ITSM system provides the business event (project closure, vendor offboarding, application decommission) that triggers the decision. None of these three systems can substitute for the other two — each layer is necessary, and the governance programme is what connects them.

The Maturity Progression

For organisations building NHI governance from a secrets management foundation, the maturity progression has four stages. First, extend discovery: the vault knows what it stores; run discovery tooling to find NHIs outside the vault's scope and bring them into a centralised inventory. Second, assign ownership: every NHI in the inventory needs an accountable owner before any other governance control is meaningful. Third, implement access certification: run quarterly review campaigns for privileged NHIs, annual for lower-privilege ones, using the ownership model built in stage two. Fourth, integrate lifecycle events: connect NHI deprovisioning to the business events — project closure, vendor offboarding, application decommission — that should trigger it automatically.

Organisations at stage four have a programme, not a tool. Their secrets manager handles storage and rotation; their IGA platform handles ownership, certification, and lifecycle governance; and the two systems are connected through integrations that keep the operational state consistent with the governance record. The vault is infrastructure. Governance is the programme that decides what the vault should contain, who should be able to access it, and when entries should be removed. Building both — and connecting them — is the full scope of what NHI security requires.