Who is accountable when a known exploited Office vulnerability remains unpatched?

Why This Matters for Security Teams

A known exploited Office vulnerability is not just a patching backlog item. It is a control failure that can expose mailboxes, endpoints, and the privileged workstations used to approve updates, reset credentials, and administer identity systems. Once a CVE appears in the Known Exploited Vulnerabilities catalog, the question is no longer whether exploitation is possible. The question is whether governance has kept pace with the threat.

That matters because Office vulnerabilities often sit at the intersection of user productivity and high-value access. Attackers do not need to own every endpoint if they can land through a document, pivot through email, and reach a privileged session that was never meant to be reachable from a standard workstation. CISA’s cyber threat advisories make the operational expectation clear: known exploited issues demand accelerated remediation, not normal-change cadence.

In practice, many security teams encounter accountability gaps only after an exploit chain has already moved from a user inbox to a privileged environment.

How It Works in Practice

Accountability usually spans more than one control owner. Endpoint patching teams own OS and application remediation. Email security teams own the controls that reduce initial delivery and execution risk. Privileged workstation governance owns the systems that should never be casually exposed to Office-driven attack paths. When any one of those layers slips, the overall exposure remains open.

For known exploited vulnerabilities, current guidance favors a response model that combines asset inventory, exposure prioritization, and deadline-driven remediation. CISA advisories should be mapped into internal SLAs so that KEV-listed issues move ahead of routine maintenance. That mapping is especially important for Microsoft Office because the blast radius often includes macros, preview panes, linked content, token theft, and lateral movement into administrative sessions. The practical lesson from recent NHI incidents, including the patterns discussed in 52 NHI Breaches Analysis, is that exposure rarely stays confined to the first compromised endpoint.

• Assign a single incident owner, but keep shared accountability across patching, email, and privileged access teams.
• Use KEV status as a prioritization signal, not a reporting label.
• Track patch age, exposed asset count, and privileged workstation coverage separately.
• Escalate unpatched KEV items into risk acceptance only with explicit sign-off from the business owner.

For operational context, the Top 10 NHI Issues research reinforces a broader pattern: weaknesses in one identity plane often become footholds for wider compromise. These controls tend to break down when remote users, unmanaged devices, or delayed reboot cycles prevent patch deployment within the required window.

Common Variations and Edge Cases

Tighter remediation deadlines often increase operational overhead, requiring organisations to balance speed against change-failure risk. That tradeoff is real, especially in environments with legacy Office integrations, heavily customized add-ins, or regulated desktop images.

There is no universal standard for this yet, but best practice is evolving toward tiered handling. A KEV-listed Office flaw on a standard user device may be remediated through expedited patching and reboot enforcement. The same flaw on a privileged workstation may warrant temporary isolation, stricter network segmentation, or even emergency removal from service until the update is verified. Where mail gateways or endpoint controls can reduce exploitability, they should be treated as compensating controls, not substitutes for patching.

One useful way to reduce ambiguity is to separate accountability from execution:

• Security leadership is accountable for risk acceptance thresholds.
• Platform and endpoint teams are accountable for patch delivery and verification.
• Identity and privileged access teams are accountable when the vulnerable system can reach admin-grade assets.

That structure becomes especially important when a business unit resists downtime or when patch telemetry is incomplete. In those cases, the exposure is not just technical debt. It is an explicit decision to leave a known exploited path open longer than policy intended. The practical lesson from OWASP NHI Top 10 is that governance failures usually emerge at the junction between access, execution, and trust, not in a single control domain.

Related resources from NHI Mgmt Group

• Who is accountable when an unsupported cryptographic library remains in production?
• What is the difference between patching a vulnerability and reducing identity blast radius?
• Who should be accountable for Cloudflare changes that affect production traffic?
• Who is accountable when a manipulated identity authorises a major crypto transfer?