Machine Identity Management vs Secrets Management: Where Vaulting Ends and Governance Begins

A secrets manager can tell you that a credential is stored safely and rotated on schedule, but not who owns the identity behind it, whether that identity should still exist, or what it is allowed to do, and that gap is where most non-human identity incidents start. Secrets management protects the credential: storage, delivery, rotation and revocation. Machine identity management governs the identity: discovery, ownership, purpose, permissions, lifecycle and decommissioning, across service accounts, workload identities, certificates, OAuth applications and AI agents, whether or not they use a stored secret at all. This guide compares the two disciplines, shows where each ends, explains why the move to secretless access shifts work from one to the other, and sets out how to run them together. It is for identity architects, platform teams and NHI programme leads deciding what to fund and who owns what. The terms themselves are defined in Machine Identity vs Workload Identity vs NHI; on this page "machine identity management" means governance of all non-human identities, not only the certificate and key management sense used in the PKI market. Cloud platforms named as examples are listed alphabetically; order is not a ranking.

Key takeaways

• Secrets management answers "is this credential safe?". Machine identity management answers "should this identity exist, who owns it, and is its access right?". Neither answers the other's question.
• A perfectly vaulted secret can belong to an orphaned, over-privileged account. Vaulting does not fix improper offboarding, overprivilege, reuse or human use of NHIs, which are four of the OWASP NHI Top 10 risks.
• Secretless access moves risk, it does not remove governance. Managed identities, IAM roles and SPIFFE remove the stored secret, but the identity, its permissions and its trust configuration still need an owner and a lifecycle.
• Certificates sit in both worlds. The private key is a secret; the certificate is an identity with an owner, a validity period and a renewal process, and validity periods are shrinking toward 47 days.
• The vault is a data source for governance. Per-secret metadata (owner, purpose, consumers, last use) is the bridge; without it the two programmes cannot be joined.

What each discipline covers

Secrets management is the system and process for credentials: API keys, database passwords, SSH keys, tokens, private keys. The OWASP Secrets Management Cheat Sheet frames it as centralising storage, provisioning, auditing, rotation and access control, and walks the lifecycle of creation, rotation, revocation and expiration, with dynamic secrets issued per session as the preferred pattern. Its unit of work is the secret. Its control point is the vault or cloud secrets store. See the Secrets Management Guide.

Machine identity management (often called NHI management) is the governance of the identities themselves: service accounts in directories and clouds, workload identities, OAuth applications and service principals, certificates, bots and AI agents. Its unit of work is the identity. Its questions are inventory (what exists, across every platform), ownership (who is accountable), purpose (why it exists), entitlement (what it can reach, and whether that is least privilege), behaviour (how it is used and by whom) and lifecycle (when it is created, reviewed, rotated, and retired). Its control points are the identity providers and cloud IAM planes where identities are defined, plus an inventory that joins them. The relationship with PAM and IGA is covered in PAM vs IGA vs NHI Management.

Side-by-side comparison

Where one ends and the other begins

The boundary is clearest when you follow one service account through its life.

The middle rows are the governance gap. A secret can be rotated every 30 days for years on behalf of an account whose owner left, whose application was decommissioned and whose permissions were never reviewed. The vault reports green throughout.

Threat model and failure modes

Secrets management alone

• What it defends against: hard-coded credentials and plaintext storage (NIST SP 800-53 IA-5(7) No Embedded Unencrypted Static Authenticators), long credential lifetimes, slow revocation, and unaudited reads (ATT&CK T1552 Unsecured Credentials).
• What gets through: a stolen but valid credential still carries every permission the identity holds; an unused identity keeps its rotated secret indefinitely; identities that never used a stored secret (managed identities, OAuth apps, federated workloads) are invisible to the vault.
• Typical failure: "we assumed it was unused". In the Cloudflare Thanksgiving Breach, a service token and three service accounts exposed in an earlier supplier breach were not rotated because they were believed to be unused; the attacker used them to get in. The fix Cloudflare described, rotating over 5,000 production credentials, is a secrets action; the root cause, not knowing which identities were live, is an identity governance gap.

Machine identity management alone

• What it defends against: orphaned and forgotten identities, permission creep, shared identities across applications and environments, human use of service accounts, and new credentials quietly added to existing identities (ATT&CK T1098.001 Additional Cloud Credentials).
• What gets through: a well-owned, right-sized identity whose secret sits in a config file, a CI variable or a chat message; governance tools can flag the secret's age but cannot store or deliver it safely.
• Typical failure: a governance inventory that records "API key, owner: payments team" with no idea where the key value lives, so revocation during an incident takes days.

The combined failure is the costliest. In the Microsoft Midnight Blizzard Breach, a legacy test tenant account without MFA led to a legacy test OAuth application with elevated access to the corporate environment, which the attacker used to create applications and grant itself mailbox access. No vault would have flagged that application; only an inventory with owners, purpose and permission review would.

The secretless direction

Every major cloud platform now issues identity to workloads without a stored secret, and the guidance from each points the same way. Listed alphabetically:

• Amazon Web Services: the IAM best practices begin with "Require workloads to use temporary credentials with IAM roles to access AWS"; role credentials are delivered to EC2, Lambda and other compute, and IAM Roles Anywhere extends this to external workloads with X.509 certificates.
• Google Cloud: the service account best practices recommend avoiding service account keys whenever possible, attaching service accounts to resources, and using Workload Identity Federation for external and GKE workloads, with the "Disable service account key creation" organisation policy constraint where keys are not needed.
• Microsoft Azure: managed identities let workloads obtain Microsoft Entra tokens with no secret to handle; the documentation states that credentials are not even accessible to the developer.

Across platforms, SPIFFE provides the same pattern: the Workload API issues a short-lived X.509-SVID or JWT-SVID to an attested workload without the caller needing any prior secret, and keys rotate automatically. See SPIFFE and SPIRE Guide and the Workload Identity Federation Guide.

The consequence for this comparison is direct: as secrets disappear, the share of non-human access that secrets management can see shrinks, and the share that only identity governance can see grows. What remains to protect is identity-shaped:

• Permissions: a managed identity with Owner on a subscription is as dangerous as a leaked key with the same rights.
• Trust configuration: federation conditions, subject claims and trust domains decide which workloads can become which identity. A loose condition is the secretless equivalent of a shared password.
• Lifecycle: Azure user-assigned managed identities have an independent lifecycle and must be explicitly deleted; Google Cloud warns that deleting and recreating a service account with the same name produces a new identity, so it recommends disabling before deleting. These are governance tasks with no secret involved.

The rotate-or-eliminate choice for each credential type is in Secret Rotation vs Secret Elimination; the bootstrap problem is in the Secrets Zero Problem Guide.

Service account governance gaps a vault cannot close

Service accounts are where the two disciplines most often get confused, because the password or key is usually the first thing anyone touches. The gaps below remain after vaulting:

Practical guides for these controls include How to assign owners to orphaned service accounts and the NHI Ownership Guide.

Certificates: the shared ground

Certificates show why the two disciplines must connect. The private key is a secret and belongs in a key store or HSM. The certificate is an identity assertion with a subject, an issuer, a validity period, an owner and dependants. CA/Browser Forum Ballot SC-081v3, which passed in 2025, reduces the maximum validity of publicly trusted TLS certificates from 398 days to 47 days in steps between March 2026 and March 2029. At that cadence renewal has to be automated, and automation needs exactly the governance data that identity management holds: which service owns the certificate, which endpoints use it, and who is called when renewal fails. The certificate lifecycle itself is covered in the Machine Identity, PKI and Certificate Lifecycle Guide.

When to lead with each

• Lead with secrets management when: scanning finds plaintext credentials in code, CI variables and config; there is no central store; or revocation during incidents is slow because nobody knows where values live.
• Lead with machine identity management when: a store exists but nobody can list the identities across clouds, directories and SaaS; audit asks for owners and access reviews of service accounts; or most workloads already use managed identities and federation, so the remaining risk is permissions and lifecycle.
• Small organisations: a cloud-native secrets store plus a tagging standard (owner, purpose, environment, expiry on every identity and secret) covers much of the governance need; a spreadsheet inventory reconciled quarterly with cloud last-used data is a reasonable start.
• Large organisations: treat them as two programmes with one data model. The vault feeds secret metadata and read events; identity platforms and cloud IAM feed identities, entitlements and last use; the NHI inventory joins them by identity. See NHI Inventory Reconciliation.
• Buying tools: a secrets manager with discovery features is not an identity governance tool, and an NHI governance tool is not a secure store. Ask each vendor which half they cover and how they exchange data with the other.

How to run them together

1. Agree the data contract: every secret carries the identifier of the identity it belongs to, plus owner, purpose, consumers and rotation rule (the per-secret metadata the OWASP cheat sheet recommends). Every identity record links to its credentials, stored or not.
2. Inventory identities first, secrets second: pull service accounts, service principals, roles, managed identities, OAuth apps and certificates from each platform; then match vault paths to them. Unmatched secrets and unmatched identities are both findings.
3. Assign owners: run an attestation campaign; anything unclaimed after a fixed window is disabled in a reversible way, not deleted.
4. Right-size permissions: use platform access activity (AWS last accessed information and IAM Access Analyzer, Google Cloud Activity Analyzer and equivalent sign-in and audit data in Microsoft Entra) to remove unused entitlements.
5. Eliminate where possible: move workloads to platform identity and federation; retire the matching vault entries and long-lived keys.
6. Automate lifecycle: tie identity creation to a request with owner and expiry; tie decommissioning of an application to disabling its identities and revoking its secrets in one change. See NHI lifecycle automation.
7. Test and roll back: disable identities before deletion, keep secrets archived for a defined window, and monitor for authentication failures after each change so a wrongly retired identity can be re-enabled quickly.

Worked scenario

A retailer runs workloads in two clouds and an on-premises Active Directory. It has a mature vault: 4,200 secrets, all with rotation policies, and a clean audit finding on credential storage. An NHI inventory exercise pulls identities from both clouds and the directory and matches them to vault paths.

• Finding 1: 1,100 identities have no vault entry at all: managed identities, IAM roles and OAuth applications. 140 of them hold owner or administrator-level roles.
• Finding 2: 600 vault secrets belong to identities with no sign-in or API activity for 90 days; rotation has continued on all of them.
• Finding 3: 35 directory service accounts whose passwords sit in the vault show interactive logons from staff workstations.

The vault team had done its job. The response is identity work: owners assigned through attestation, unused identities disabled then deleted after 30 days with their secrets archived, administrator roles cut back using access activity, and interactive use moved to personal privileged accounts. Twelve months later the vault holds fewer secrets, because many workloads moved to federation, and the identity inventory is the primary register.

Detection and measurement

Monitor creation of new identities and new credentials on existing identities in every cloud and directory, interactive sign-ins by service accounts, vault reads by consumers that do not match the recorded owner, and identities with no activity beyond the review threshold. Measures that show both halves working:

• Ownership coverage: share of non-human identities with a current, attested owner.
• Join rate: share of vault secrets linked to an inventoried identity, and share of identities with stored secrets that are in the vault.
• Dormant identity count: identities with no activity in 90 days that are still enabled.
• Secretless share: share of workload access using platform identity or federation rather than stored secrets.
• Privileged NHI ratio: identities with administrator-level roles as a share of all identities, trending down.
• Mean time to revoke: from compromise or retirement decision to credential revoked and identity disabled.

Common failure patterns

• Calling the vault the inventory: it lists secrets, not identities, and misses everything secretless.
• Rotating instead of retiring: automated rotation keeps unused accounts alive and makes them look healthy.
• Exempting "unused" credentials after a breach: without last-used data from the target platform, "unused" is a guess, as the Cloudflare case shows.
• Ignoring non-production: test tenants and legacy applications sit outside both programmes, which is where the Midnight Blizzard intrusion started.
• Treating secretless as finished: federation without trust condition reviews or permission right-sizing swaps a secret problem for an authorisation problem.
• Metadata as optional: secrets stored without owner and purpose cannot be joined to identities, so neither programme can answer an auditor.

Framework mapping

Practitioner checklist

• Write down which team owns secrets management and which owns machine identity governance, and where they hand over.
• Require owner, purpose, consumers and rotation rule on every stored secret, linked to an identity identifier.
• Build an identity inventory across clouds, directories, SaaS and certificates that includes secretless identities.
• Reconcile vault paths to identities quarterly; treat both unmatched lists as findings.
• Use platform last-used data before declaring any identity unused, and disable before deleting.
• Right-size permissions with access activity tools on each cloud platform.
• Move workloads to managed identities, IAM roles, federation or SPIFFE where the target supports it.
• Review federation trust conditions and certificate ownership as identity controls.
• Detect and stop interactive use of service accounts.
• Report ownership coverage, dormant identities and secretless share alongside vault metrics.

Standards and references

• OWASP: Non-Human Identities Top 10 2025
• OWASP: Secrets Management Cheat Sheet
• NIST: SP 800-53 Rev. 5
• SPIFFE: SPIFFE Concepts
• CA/Browser Forum: Ballot SC-081v3 reducing validity and data reuse periods
• AWS: Security best practices in IAM
• Google Cloud: Best practices for using service accounts securely
• Microsoft Learn: What are managed identities for Azure resources?

Related NHI Mgmt Group resources: Secrets Scanning vs Secrets Management · PAM vs IGA vs NHI Management · Centralised vs Decentralised Secrets Management · OWASP NHI Top 10 NHI1 Improper Offboarding Guide · NHI Ownership Guide