Why patching without validation still leaves manufacturers exposed

At a glance

What this is: This is a case study on continuous offensive validation in manufacturing, with the key finding that patching alone did not prove risk was closed.

Why it matters: It matters because IAM, PAM, and security teams need evidence that access paths, misconfigurations, and exposed systems are actually remediated, not just reported as fixed.

By the numbers:

• The manufacturer reduced exposures from High to Medium in 40 days at a key site.
• The team eliminated 94 exploitable attack paths.
• The manufacturer achieved a 100% reduction in network-level compromise scenarios.

👉 Read Horizons.ai's post on continuous validation for critical vulnerability remediation

Context

Patch management reduces known exposure, but it does not prove that the attack path is gone in the live environment. In manufacturing, where inherited systems, acquisitions, and long-lived operational technology can create hidden weaknesses, continuous validation is often what separates compliance activity from real risk reduction. This is especially relevant to identity governance when misconfigurations and overexposed services create paths that attackers can use without needing new malware.

The primary lesson here is not about one vendor tool. It is about the gap between remediation intent and verified security outcome. For teams responsible for IAM, PAM, NHI, and broader security operations, the question is whether the environment has been tested in a way that reflects how attackers actually move, escalate, and validate access once a vulnerability is disclosed.

Key questions

Q: What breaks when patching is done without exploitability validation?

A: Patching without exploitability validation breaks the assumption that a vulnerability is actually closed. A ticket can be marked complete while the environment still contains a live route to compromise because of trust relationships, misconfiguration, or an unpatched sibling system. The result is remediation theatre, where compliance improves faster than real security.

Q: Why do manufacturing environments need continuous validation more than annual pentests?

A: Manufacturing environments accumulate risk through acquisitions, ageing infrastructure, and long-lived services that change between scheduled tests. Annual pentests cannot keep pace with disclosure windows measured in hours. Continuous validation gives defenders evidence that exposed paths are gone after each critical change, not just at audit time.

Q: How do teams know if a vulnerability is truly exploitable?

A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it. Scanner data alone cannot answer that question reliably. Validation gives defenders evidence they can use to separate theoretical issues from immediate response priorities.

Q: Who is accountable when a patched application is still exploitable in production?

A: Accountability sits with the owners of the application, the security team setting prioritisation, and the business leaders who accept residual risk while manual fixes are pending. For regulated or high-value environments, the governance question is whether exposure windows were tracked and escalated fast enough to prevent unauthorized execution and data theft.

Technical breakdown

Why point-in-time pentests miss live attack paths

Annual or quarterly pentests produce a snapshot, but attacker exposure changes continuously as systems are patched, acquired, reconfigured, and integrated. A point-in-time test can show that a weakness existed, yet it cannot prove whether the same weakness was later reopened through a dependency, a stale configuration, or a forgotten host. In operational environments, especially manufacturing, that gap matters because asset sprawl and inherited access often outlast the original remediation cycle.

Practical implication: replace one-off testing with recurring validation tied to change events, not just calendar cycles.

How exploitability validation differs from vulnerability scanning

Vulnerability scanning identifies potential weaknesses, but exploitability validation tests whether an attacker can actually turn a finding into access or compromise. That distinction matters because severity scores do not account for local trust relationships, perimeter exposure, or adjacent misconfigurations that create a real path. In identity-heavy environments, the same issue can be low risk in one context and breach-enabling in another if an exposed service sits next to privileged systems.

Practical implication: prioritise exploitability evidence over scanner noise when deciding what to fix first.

Why identity and network paths must be tested together

Attackers rarely exploit a single control failure in isolation. They often chain initial exposure, directory misconfiguration, and privilege misuse into a viable route toward broader compromise. That is why testing must include network edges, identity systems, and the trust relationships between them. When Active Directory misconfigurations or weak service boundaries exist, the real issue is not only technical exposure but the absence of verified path disruption across the environment.

Practical implication: test identity routes, service trust, and network exposure as one attack surface.

Threat narrative

Attacker objective: The attacker’s objective is to convert a disclosed vulnerability into a verified breach path before defenders can prove the exposure is closed.

1. Entry began when a publicly exposed or known exploitable service, such as Citrix NetScaler, could be reached before patching was completed.
2. Escalation followed if the exposed perimeter control provided a path to deeper internal access or a full perimeter breach.
3. Impact was the creation of a confirmed route into sensitive environments, which attackers could turn into ransomware, data theft, or broader compromise.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

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

NHI Mgmt Group analysis

Patching without proof creates remediation theatre: the organisation may believe risk has been reduced while the attack path remains viable. Continuous validation closes that gap by testing whether the fix actually changes attacker reachability in the production environment. For identity and access teams, that means remediation must be measured by path elimination, not ticket closure. The practical conclusion is that verified exposure closure belongs in the security operating model.

Attack-path elimination is the real control objective: the manufacturer’s results show that reducing exposures, removing paths, and retesting quickly matters more than simply meeting a patch deadline. This aligns with a broader security truth: adversaries do not care whether a control was updated if the route still works. In governance terms, remediation needs evidence of impact, not evidence of activity. Practitioners should treat attack-path reduction as the control outcome.

Identity misconfiguration remains a breach multiplier: the article’s references to Active Directory misconfigurations and inherited site risks show how operational sprawl turns local weaknesses into enterprise exposure. This is where IAM and PAM intersect with broader security testing. If privileged paths, service trusts, or directory relationships are not validated under attack conditions, the organisation is effectively assuming that access design matches reality. The practical conclusion is to validate identity trust chains as part of remediation assurance.

Manufacturing security programmes need a validation cadence, not a compliance cadence: annual review cycles cannot keep pace with KEV-driven exploitation windows and infrastructure inherited through acquisitions. The named concept here is remediation confidence gap, the distance between a patch being applied and the environment being proven safe. That gap is where attackers operate. Security leaders should align assurance to the speed of disclosure, not the speed of reporting.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• From our research: Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, according to The State of Non-Human Identity Security.
• Forward look: Use 52 NHI Breaches Analysis to compare how hidden access paths and weak lifecycle controls become real incidents.

What this signals

Patch validation is becoming a governance issue, not just an operations issue. As environments inherit more systems and attackers move faster after disclosure, practitioners need assurance models that prove closure in production rather than assuming a ticketed fix equals risk reduction. That shift also strengthens the case for identity-aware testing, because exposed services and privileged routes often intersect.

Remediation confidence gap: the gap between patch deployment and verified exposure closure will widen whenever acquisition sprawl, unmanaged services, or directory trust issues are present. Teams should expect more pressure to provide evidence of exploitability testing and path reduction, particularly for KEV-class vulnerabilities and internet-facing assets. The practical response is to align retesting to change velocity.

For identity programmes, the relevant signal is whether identity trust chains are being validated under attack conditions. If Active Directory, service accounts, or privileged pathways are part of the attack route, remediation has to include those relationships, not only the vulnerable service. That is why continuous validation belongs beside IAM and PAM assurance, not outside it.

For practitioners

• Tie remediation to verified retesting Require a retest after every critical patch, especially for internet-facing services and inherited systems, so the team can confirm the exposure is actually closed.
• Map attack paths across identity and network layers Use offensive validation to trace how exposed services, Active Directory relationships, and privileged routes connect into a full compromise path.
• Prioritise KEV-driven validation windows Treat known exploited vulnerabilities as immediate testing triggers, not just patch queue items, and validate the fix before adversaries can sweep the environment.
• Build weekly assurance for inherited assets Standardise weekly internal and external testing for acquired or long-lived environments where misconfigurations and stale systems are most likely to persist.
• Use tripwires for high-value services Place detection controls on key services and directory systems so attacker behaviours such as password spraying, lateral movement, and enumeration are surfaced early.

Key takeaways

• The core problem is not patching speed but proof that the exposed path is gone.
• The evidence shows that continuous validation can compress remediation from weeks into hours and remove large numbers of attack paths.
• Security teams should treat exploitability retesting, not ticket closure, as the measure of remediation success.

Key terms

• Exploitability Management: Exploitability management is the practice of prioritising vulnerabilities based on whether they can actually be used in a specific environment. It combines vulnerability intelligence, asset reachability, and compensating controls so teams focus on exposure that can lead to real operational impact.
• Attack path: A sequence of identities, permissions, systems, and data stores that an attacker can traverse after obtaining trusted access. In practice, attack paths matter more than single accounts because they show how a low-risk identity can become a route to high-value exposure.
• Remediation gap: The remediation gap is the distance between identifying a security issue and proving that the underlying exposure is actually gone. In practice, it includes ownership, deployment, validation, and evidence. The gap matters because a fix that never reaches production leaves the attacker-facing condition unchanged.
• Known Exploited Vulnerability: A Known Exploited Vulnerability is a flaw that has confirmed active exploitation in the wild and is tracked for urgent remediation. In governance terms, KEV status turns patching from a general hygiene task into a time-bound operational obligation.

What's in the full article

Horizons.ai's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how Rapid Response testing was used to validate a Citrix exposure before broad weaponisation.
• Operational detail on how weekly internal and external testing was standardised across inherited environments and acquisitions.
• Specific examples of NodeZero Tripwires placement and the attacker behaviours they were designed to surface.
• Details on how vulnerability findings were tied to business impact through the Vulnerability Management Hub.

👉 Horizons.ai's full post covers the Citrix test sequence, inherited risk findings, and the remediation workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a common language for controlling access, lifecycle, and privilege risk across modern environments.