Who is accountable for fixing EPM poisoning risk when it appears in a Windows client?

Why This Matters for Security Teams

EPM poisoning is not just a client bug, it is an identity and trust failure at the point where a Windows client decides which server, endpoint, or registration source to trust. That makes ownership split across the client application team, the platform vendor, and the security function that validates exposure and monitors abuse. NIST’s NIST Cybersecurity Framework 2.0 is clear that asset, identity, and protection duties must be assigned, not assumed.

The practical risk is that a poisoned endpoint can redirect client trust, enable rogue registrations, or turn a local weakness into a repeatable access path across many machines. NHIMG has repeatedly shown that identity failures scale faster than teams expect, including in the Ultimate Guide to NHIs, where mismanaged identities and delayed remediation are common. In a recent NHIMG and Oasis Security report, 72% of organisations said they had experienced or suspected an NHI breach, which is a reminder that trust-chain issues rarely stay isolated.

In practice, many security teams encounter EPM poisoning only after a client has already accepted a malicious registration path or exposed RPC surface, rather than through intentional validation before deployment.

How It Works in Practice

The immediate accountability usually begins with the client owner because the client must validate what it connects to, what it loads, and which remote registrations it accepts. The platform vendor is accountable when the weakness sits in the product design, default configuration, or exposed RPC behavior. Security teams then own verification, detection, and containment, not just policy documentation. That division is important because a poisoned endpoint often lives at the intersection of software design, Windows hardening, and trust decisions made at runtime.

In operational terms, the response should include patching the affected client, reviewing any exposed RPC surfaces, checking whether the client verifies server identity or registration provenance, and blocking unsafe fallback behavior. The same pattern should be tested independently in every client or agent that uses similar discovery logic. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both emphasize that insecure trust assumptions and weak lifecycle controls become recurring failure modes when identities are not continuously validated.

• Assign a named client owner for remediation and a platform owner for product-level fixes.
• Validate server identity, endpoint provenance, and registration trust at runtime.
• Patch affected Windows clients and review any RPC or discovery paths they expose.
• Deploy detection for rogue registrations, abnormal lookups, and unexpected trust changes.
• Retest each client independently instead of assuming one fix applies everywhere.

Where this guidance breaks down is in legacy Windows environments with hard-coded trust logic, shared libraries, or vendor-managed agents that cannot be patched quickly because the client cannot be changed without breaking dependent workflows.

Common Variations and Edge Cases

Tighter client validation often increases operational overhead, requiring organisations to balance stronger trust checks against support burden and compatibility risk. That tradeoff becomes sharper when the Windows client is embedded in a line-of-business application, managed by a third party, or distributed to thousands of endpoints with limited maintenance windows.

Current guidance suggests treating those cases as exceptions to be documented, not as reasons to weaken the control permanently. If the vendor says the issue is “upstream,” that does not remove the local duty to contain exposure, disable unsafe discovery behavior, or add compensating detection. If the client is packaged with the OS or a management agent, then security and platform teams should coordinate with the vendor while still hardening what they can on the endpoint. The 2024 ESG Report: Managing Non-Human Identities shows how often organisations are already dealing with compromised NHIs, which makes delayed response especially costly.

For the most visible guidance on control alignment, NIST SP 800-53 Rev 5 Security and Privacy Controls supports layered validation, monitoring, and configuration management even when a specific protocol flaw is still under vendor review. In environments with custom RPC brokers, VDI fleets, or security products that impersonate clients, the exact failure mode may differ, but the accountability pattern stays the same: fix the client, contain the trust path, and prove the exposure is gone.

Related resources from NHI Mgmt Group

• Who is accountable for cross-application access risk when emergency access is extended beyond ERP?
• Who is accountable when an organisation modernises authentication but leaves transaction risk controls incomplete?
• Why do non-human identities create more audit risk than human accounts?
• Why do non-human identities create audit risk in modern environments?