They should use one governance model, but extend it across both problem sets. Software vulnerabilities, service accounts, tokens, certificates, and AI agents all create exposure, and the prioritisation logic should compare them using the same business-risk lens. Separate programmes usually create separate blind spots.
One Governance Model, Broader Exposure Lens
Yes. The practical answer is to govern exposure as one portfolio, not as two disconnected programmes. Software flaws, leaked secrets, service accounts, certificates, and AI agent credentials all create exploitable exposure; the decision logic should compare them by business impact, exploitability, and blast radius rather than by asset type alone.
A split model often creates duplicate queues, inconsistent severity thresholds, and blind spots where one team sees “software risk” while another sees “identity risk” or “machine identity risk.” The better model is a shared exposure register with common scoring, common ownership, and common escalation rules, so the organisation can see which issue is most dangerous now, regardless of whether it began as a CVE or a credential problem.
That convergence is easiest to defend when teams already accept that machine credentials, tokens, and certificates are not side issues, they are access paths. NHIMG’s Human vs Non-Human Identity guide is useful here because it frames ownership, lifecycle, and governance across both people and machines.
How Software Flaws and Machine Identity Risk Should Be Compared
The comparison should start with the same questions for both categories: what can be reached, how easily can it be abused, and what happens if it is compromised. A low-severity flaw on an internet-facing service may outrank a long-lived certificate in a low-value system if the flaw enables immediate code execution. Likewise, a stale token with broad privileges may outrank a medium-severity application bug if it exposes production data or administrative functions.
That means the governance process should not privilege vulnerability management metrics over identity metrics, or the reverse. Instead, it should normalise exposure into a common decision layer that understands exploit path, privilege level, detection confidence, and remediation friction. A certificate nearing expiry, a hardcoded API key, and an unpatched library can all be urgent for different reasons, but they should still be assessed in the same prioritisation queue.
For machine identity specifically, the governance object is often not the credential alone but the whole access relationship around it. NHIMG’s Service Account Security Guide and Machine Identity, PKI and Certificate Lifecycle Guide both reinforce that lifecycle control and privilege scope matter as much as the asset that is exposed.
Why Separate Programmes Create Blind Spots
Separate programmes usually optimise for local efficiency, not enterprise exposure. Vulnerability teams tend to measure patch status, while IAM or platform teams measure account state, credential hygiene, and rotation. If those views never meet, the organisation can overinvest in patching low-impact issues while missing a dormant machine identity that still has production reach.
The blind spot becomes worse when identities are shared across environments, embedded in pipelines, or delegated to tools and agents. In those cases, exposure is not just “who has a credential,” but “what execution authority does that credential unlock.” NHIMG’s Agentic AI Identity Guide is relevant because it shows how delegated authority and lifecycle discipline apply when software can act with its own identity.
For organisations that want a concrete way to join the dots, the question is not whether the issue is a flaw or an identity problem. The question is whether it creates a meaningful path to unauthorised action, privileged access, or operational disruption. If it does, it belongs in the same exposure governance model.
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 addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Unifies exposure prioritisation across flaws and machine identities. |
| PR.AA-05 — Identity Management, Authentication and Access Control | Covers access paths created by service accounts, tokens, and certificates. | |
| ID.AM-03 — Organizational Communications and Data Flows Are Documented | Exposure governance depends on understanding which systems and services the access can reach. | |
| Recommendation — Use one business-risk scoring method for software flaws, secrets, and machine identities. Apply least-privilege access controls to every credentialed exposure path. Document service-to-service and tool-to-system access relationships before triage. | ||
| CIS Controls v8 | CIS-5 — Account Management | Account and credential lifecycle are central to machine identity risk. |
| Recommendation — Inventory, approve, and remove accounts and service identities on a defined lifecycle. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Machine identity risk often becomes material when credentials have excess privilege. |
| Recommendation — Reduce non-human identity privilege to the minimum needed for each workload. | ||
Practitioner Guidance
What to prioritise: Put one risk owner or review board in charge of comparing software vulnerabilities, credentials, certificates, and agent access paths. If different teams use different scoring logic, they will produce different “top risks” and you will lose comparability.
What to verify: Check that each exposure item has an owner, a business service attachment, and a privilege description. If you cannot tell what a leaked token, expired certificate, or CVE could actually reach, the governance process is too shallow to prioritise it correctly.
Decision rule: Treat the item with the larger blast radius and lower remediation confidence as the higher-priority exposure, even if it comes from a different programme. The most important judgement is often whether to rotate, revoke, patch, or isolate first.
Common mistake: Do not let vulnerability management become a backlog of CVEs while machine identity issues sit in a separate queue with no business scoring. That split is how organisations miss the issue that is easiest for an attacker to turn into access.
Practitioner takeaway: The goal is not to merge every team, it is to merge the decision logic so that any exposure capable of producing real access is triaged by the same business-risk standard.