NHI 2×2 framework shows how to close visibility and remediation gaps

At a glance

What this is: Veza's NHI 2x2 framework is an operating model for non-human identity governance that links visibility, prioritisation, guardrails, and verified remediation across four identity types.

Why it matters: For IAM and NHI teams, it reframes machine identity work as a closed-loop control problem rather than a one-time inventory exercise.

👉 Read Veza's analysis of the NHI 2x2 framework and closed-loop remediation

Context

Non-human identity governance fails when teams can list identities but cannot prove who owns them, what they can reach, or whether risky access has actually been removed. In NHI programmes, that gap shows up as dormant service accounts, overbroad tokens, and unverified changes that drift back after audits. This is the core problem the NHI 2x2 framework is trying to solve.

The framework is built around four motions, visibility, intelligence, management, and remediation, applied across service accounts, service principals, certificates, and API tokens. That structure matters because NHI risk is not limited to one system or one credential type. It is a cross-environment governance problem that has to be resolved in the systems where access is created, inherited, and revoked.

Key questions

Q: How should security teams prioritise non-human identity remediation?

A: Prioritise the identities with the largest blast radius first. That usually means service accounts or tokens that can write to production, cross trust boundaries, or reach sensitive data. A useful programme ranks remediation by effective permissions and business impact, not by how many identities exist or how old the finding looks.

Q: Why do non-human identities complicate zero trust architecture?

A: Non-human identities complicate zero trust because they often authenticate through inherited, delegated, or long-lived access paths that are hard to inspect continuously. Zero trust depends on current verification, but machine identities can retain broad reach through consents, scopes, and dormant credentials. That makes lifecycle control and continuous validation essential.

Q: What is the difference between visibility and intelligence in NHI governance?

A: Visibility tells you what identities exist, who owns them, and what they can reach. Intelligence ranks that information so teams know what to fix first. In practice, visibility is the inventory and access picture, while intelligence is the prioritisation layer that turns discovery into a work queue.

Q: Should organisations treat certificates and tokens like other non-human identities?

A: Yes. Certificates and tokens are identities with authority, reach, and lifecycle risk, even if they do not look like accounts. They should be governed with ownership, expiry, rotation, and revocation controls, because the damage usually comes from stale trust, not from the credential format itself.

Technical breakdown

How the NHI 2x2 maps identity sprawl into a control loop

The NHI 2x2 is a control model, not a taxonomy. Its horizontal axis represents four governance motions: visibility, intelligence, management, and remediation. The vertical axis represents four common NHI types: service accounts, service principals, certificates, and API tokens. The technical value is that each row can be governed in the same sequence, from discovery to prioritisation to policy enforcement to verified cleanup. That matters because the effective risk is rarely in the object itself. It is in the permissions, inheritance, consent paths, and downstream data reach attached to it.

Practical implication: Use one operating sequence across all NHI types so discovery, policy, and remediation stay consistent.

Why effective permissions matter more than raw identity counts

Visibility in NHI governance is not a headcount. It is a resolved view of effective permissions, ownership, last use, and reachable data. That distinction matters because role names and app labels hide the actual access path, especially when permissions flow through nested groups, OAuth scopes, delegated consent, and cross-system inheritance. Intelligence then ranks what to fix first by blast radius and data sensitivity, which is how teams move from cataloguing to action. Without that layer, remediation is guesswork and access reviews become paperwork instead of control enforcement.

Practical implication: Build visibility around effective access paths, not just identity inventories or role names.

Why remediation must verify state change, not just issue a ticket

Remediation only closes the loop when it changes the source systems and confirms the new state. In NHI environments, that means revoking unused memberships, rotating tokens or certificates, pruning stale consent, and validating that downstream access no longer works. If the system only records a finding, the risk often returns after the next sync, build, or manual exception. The architecture therefore has to include evidence of change, not just a planned change, because NHI drift is typically machine-speed and repeatable.

Practical implication: Treat remediation as a state-verification workflow, with evidence that the risky path is actually gone.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Internet Archive breach — unsecured GitLab authentication tokens exposed 31M Internet Archive accounts.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

The real NHI problem is not discovery, it is closure. Most programmes can surface service accounts and tokens, but far fewer can prove that access was reduced and stayed reduced. That is why closed-loop remediation should be treated as the core control objective, not a follow-on task. Practitioners should measure whether access changes actually stick.

Effective permissions are the unit of governance for machine identities. Raw inventory underestimates risk because inheritance, consents, and indirect data paths define the actual attack surface. A useful programme resolves who can act on what data, then ranks that by blast radius. Practitioners should base reviews on effective access, not labels.

NHI 2x2 formalises a repeatable control pattern for sprawl. The value of the model is that it creates a common motion across identity types without forcing each team to improvise its own process. That reduces friction between engineering and security, while still giving auditors a clear control story. Practitioners should standardise the loop before scale makes exceptions normal.

Certificates and tokens deserve the same governance discipline as accounts. Teams often treat them as technical artefacts instead of identities with reach, ownership, and lifecycle risk. That creates blind spots in rotation, revocation, and proof of cutover. Practitioners should bring these credentials into the same lifecycle and access-control programme as service accounts.

Identity blast radius is a more useful concept than identity count. A small number of highly privileged NHIs can create more risk than a large inventory of low-impact ones. The right prioritisation model asks which identities can change production, reach sensitive data, or cross trust boundaries. Practitioners should optimise for blast-radius reduction, not simple reduction of inventory size.

From our research:

• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• Only 20% of organisations have formal processes for offboarding and revoking API keys, leaving many machine identities active far longer than intended.
• For a broader control baseline, see Ultimate Guide to NHIs , Static vs Dynamic Secrets for how credential lifetime affects NHI risk.

What this signals

Identity blast radius will become the metric that matters most for NHI programmes. Inventory alone does not tell a CISO where risk concentrates, but effective permissions and reachable data do. Teams that cannot convert discovery into ranked action will keep finding the same problems in different systems.

With 96% of organisations storing secrets outside secrets managers in vulnerable locations, the governance challenge is clearly broader than vault hygiene alone. That pattern means NHI programmes need controls that span code, CI/CD, SaaS, and cloud access paths instead of assuming one platform can absorb the problem.

The control model should now extend to governance evidence. If remediation cannot prove that access was removed in the source systems, then the organisation is managing findings, not reducing exposure. Practitioners should align this work with NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

For practitioners

• Implement an effective-permissions inventory Resolve service accounts, service principals, certificates, and API tokens into a single inventory that includes owners, last use, environment, and reachable data. Use the result to separate harmless sprawl from identities that can change production or access sensitive systems.
• Rank remediation by blast radius Prioritise identities that can write to production, inherit privileged group memberships, or cross tenant and environment boundaries. Tie remediation queues to data sensitivity and change rights rather than to raw identity counts.
• Enforce lifecycle controls on machine credentials Require TTLs, rotation policies, owner assignment, and revocation paths for tokens, certificates, and app consents. Make exceptions visible and time-bound so credentials cannot drift into long-lived implicit trust.
• Verify that remediation changed the source of truth Confirm that revoked access no longer works in the identity provider, cloud platform, or SaaS control plane. Treat validation as part of the fix so tickets do not close before the risky path is actually removed.

Key takeaways

• NHI governance works best as a closed loop, not a static inventory.
• Effective permissions and blast radius are better prioritisation signals than identity counts alone.
• Credentials, consents, and certificates need lifecycle controls that prove risk actually went down.

Key terms

• Effective Permissions: The actual access an identity can exercise after inheritance, delegation, scopes, and group membership are resolved. In NHI governance, effective permissions matter more than assigned roles because they reveal what a service account, token, or certificate can really reach or change.
• Identity Blast Radius: The amount of damage an identity could cause if it is abused or compromised. For non-human identities, blast radius is shaped by write access, privileged scopes, trust boundaries, and data reach, so it is a better prioritisation measure than raw identity volume.
• Closed-Loop Remediation: A governance process that does not stop at finding risk. It removes or reduces access, confirms the change in the source systems, and keeps evidence that the risky condition stayed fixed. For NHIs, this is the difference between inventory and actual risk reduction.
• Non-Human Identity: Any machine-driven identity that authenticates and acts on behalf of a workload, application, automation, or AI agent. These identities include service accounts, API keys, tokens, certificates, and app principals, and they require lifecycle controls because they often outnumber human identities.

Deepen your knowledge

NHI lifecycle governance and closed-loop remediation are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building a machine identity programme from an inventory-first starting point, it is worth exploring.

This post draws on content published by Veza: NHI 2x2 Framework: From Blind Spots to Closed Loops. Read the original.