Who is accountable when exploit-validated vulnerabilities remain open after prioritisation?

Why This Matters for Security Teams

Exploit-validated vulnerabilities are not just technical findings; they are active governance obligations. Once exploitation is credible, the question shifts from “is it vulnerable?” to “who is accountable for closing or accepting the exposure?” That distinction matters because prioritisation without ownership leaves teams with dashboards, not control. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls frames this as a control problem tied to risk treatment, not a reporting exercise.

For NHI-heavy environments, open weaknesses often involve secrets, tokens, service accounts, and automation paths that bypass normal human review. NHIMG’s The State of Secrets in AppSec notes that the average time to remediate a leaked secret is 27 days, even though most organisations claim strong confidence in their secrets management. That gap is exactly where accountability fails: the issue is known, exploitable, and still unresolved. In practice, many security teams encounter blame-shifting after an incident rather than clear remediation ownership before exposure becomes an incident.

How It Works in Practice

Accountability starts by separating four roles: the issue finder, the asset owner, the remediation owner, and the risk acceptor. The same person or team may fill more than one role, but the record must show each decision explicitly. If exploit validation confirms real-world use, prioritisation should trigger a time-bound response, compensating controls where needed, and formal acceptance if the fix cannot land immediately. This is especially important for NHIs because the exposed credential may be used by a workload, pipeline, or agent rather than a human.

Operationally, mature teams link findings to asset inventory, service ownership, and change records. They track whether the vulnerability is:

• assigned to a named technical owner
• covered by a mitigation such as segmentation, token revocation, or access restriction
• subject to a documented exception with expiry and approver
• retested after the fix or mitigation is deployed

That workflow becomes more reliable when vulnerability data is joined with identity and secrets telemetry. The LLMjacking research shows how quickly attackers move against exposed credentials, which is why remediation timelines matter as much as severity labels. CISA’s Known Exploited Vulnerabilities Catalog is useful here because it reinforces a simple rule: exploitability changes priority, and priority must map to a person accountable for action. These controls tend to break down when asset ownership is stale and the exposed secret belongs to a shared automation account with no named business owner.

Common Variations and Edge Cases

Tighter remediation governance often increases operational overhead, requiring organisations to balance speed of closure against the friction of exception management. That tradeoff becomes visible in large environments where dozens of teams, platforms, or product lines share the same identity and secrets infrastructure.

Current guidance suggests that “who is accountable” can differ by vulnerability class. For application code flaws, accountability may sit with product engineering; for leaked secrets, it usually belongs to the platform or service owner that issued or stored the credential; for compensating controls, it often sits with security or infrastructure teams. There is no universal standard for this yet, so the organisation needs a consistent decision model rather than ad hoc escalation.

Edge cases also appear when remediation depends on vendors, managed services, or legacy systems that cannot be patched quickly. In those cases, the accountable party is still the internal owner of the risk, even if a third party performs the fix. The key test is whether leadership can show the exploit-validated issue was prioritised, tracked, mitigated, and either closed or formally accepted. NHIMG’s 52 NHI Breaches Analysis is a reminder that identity-related exposures are rarely isolated, and unresolved items often cluster around weak ownership rather than weak tooling alone.

Related resources from NHI Mgmt Group

• Why do leaked secrets remain such a persistent NHI risk?
• Who is accountable when inherited NHI credentials remain active after a merger or acquisition?
• Who is accountable when backup login methods remain enabled after passwordless rollout?
• Who is accountable when subcontractor access remains open after a project ends?