Unpatchable Assets and Compensating Controls: A CTEM Guide to Intentional Risk

TL;DR

Some systems cannot be patched on a vendor's schedule: OS-bound legacy software, end-of-life edge appliances, embedded print and OT devices, and vendor-locked applications where the business process has zero tolerance for downtime. The honest answer is rarely "accept the risk" and rarely "rip it out next quarter." It is to reduce likelihood — remove internet reachability, isolate the asset, deny egress, virtual-patch what you can, and constrain who can reach it. Compensating controls decay: firewall rules drift, "temporary" exceptions become permanent, and vendor support tunnels quietly reopen paths you closed. A control validated at design time is not a control you still have. Finding volume keeps climbing, and automated — increasingly AI-assisted — reports make queues noisier without adding risk context, so a validation gate matters as much as coverage.

What this is

"Unpatchable" is not a synonym for "end of life," although EOL gear is the classic case. In practice, an asset is unpatchable when a business, vendor, or physical constraint blocks the normal remediation path:

• The vendor's software only runs on an operating system the vendor no longer supports.
• The hardware is certified, validated, or physically embedded and cannot be touched.
• The business process has no maintenance window — payment runs, check printing, trading systems, assembly lines.
• The system is locked into a vendor contract with no supported upgrade or no workable alternative.

A compensating control is a safeguard that reduces the likelihood or impact of exploitation instead of, or alongside, remediation. The categories that matter most in exposure management:

• Network: isolation, deny-by-default egress, microsegmentation, ACLs, no internet reachability.
• Application: WAF virtual patching, input filtering, disabling vulnerable features.
• Identity: least privilege, MFA, dedicated jump hosts, session recording, no shared service accounts.
• Endpoint: application allowlisting, EDR in block mode, restricted admin rights.
• Detection: flow logs, DNS telemetry, firewall denies, file integrity monitoring.

Compensating control risk management is the discipline of treating those controls as risk-reducing assets that must be verified continuously — each with a named owner, a documented business justification, a reproducible verification test, and a review or expiry date. In CTEM terms, you apply the same loop you use everywhere else — discover, validate, prioritize, mobilize, measure — to the exception set specifically. The exception register stops being an audit artifact and becomes a live exposure inventory.

Why it matters

Patch volume has outrun patch capacity. Vendors publish advisories faster than most teams can test and deploy them, and exploited-in-the-wild deadlines keep shrinking. Every prioritization model eventually reaches the same conclusion for a subset of systems: you will not patch this in time, or at all. The Talos Threat Source newsletter recently captured this with a story about check-printing systems that could not be upgraded — the software ran only on obsolete operating systems, the printer interface cards needed hardware ports that no longer existed, and there was no alternative to deploy. The security team's answer was not a patch. It was isolation: no inbound or outbound internet access, plus a lower chance of being surfaced during an adversary's internal reconnaissance. "Do what you can to make sure the checks still get printed" is a fair summary of the constraint most security teams actually operate under.

The exposure is the access path, not just the vulnerability. A recent breach of Denmark's national civil registration database reportedly began with abuse of a company's lawful search access to the system. No zero-day required. If your risk model only counts CVEs, you miss the legitimate identity and reachable interface carrying the risk.

Automation is inflating the queue on both sides. Google recently narrowed an open-source bug bounty program to stop accepting product vulnerability submissions after a wave of invalid automated reports — a reminder that more findings is not more risk. At the same time, Cisco Talos disclosed "A3" (AI-analysis evasion), where malware authors embed natural-language instructions in code to steer AI-assisted analysis. Two lessons follow: plaintext imperative language addressed to an analysis system is a stable detection surface, and any text extracted from an untrusted source must be treated as evidence, never as a directive — including inside your exposure-triage tooling.

How it works

1. Discovery favors the exposed. External recon is cheap: port and service discovery, banner grabbing, certificate transparency, technology fingerprinting. An internet-reachable legacy host is found by scanning at scale. The same host inside a deny-egress segment must be found from inside, after an attacker already has a foothold — precisely the step that segmentation removes.

2. Edge appliances give you no patch window. When a pre-auth memory corruption or denial-of-service flaw lands in an internet-facing appliance, the vendor's patch may not exist yet and your change window may be days away. Your only immediate levers are reducing reachability and hardening the management plane.

3. Controls decay along predictable paths. Isolation fails in recognizable ways: the "temporary" allow rule nobody removed; an IPv6 path not mirrored into the v4 ruleset; the vendor remote-support tunnel re-established during maintenance; the monitoring or backup agent that needs outbound access; the dual-homed admin laptop; the jump host with broader access than the asset itself. Each one converts a compensating control into theater.

4. Legitimate access gets abused. Stolen credentials and over-scoped service accounts produce the same outcome as exploitation with less noise. Identity constraints are compensating controls too.

5. AI-assisted analysis is now an attack surface. In A3-style evasion, the payload carries instructions aimed at the analyst's LLM pipeline. Reported effectiveness is partial — steering verdicts roughly a third of the time — but the technique is spreading across malware families and is paired with serious capabilities such as abusing vulnerable drivers to disable EDR from kernel space. The architectural takeaway is blunt: extracted text is data, never instructions.

Detection and response

Hypothesis: an unpatchable asset's compensating control has silently decayed, so the asset is reachable or egressing when it should not be. You cannot manage a compensating control you cannot see. Good telemetry for the unpatchable set looks like this:

• An authoritative inventory of exception assets: hostname, owner, the business process it supports, why it cannot be patched, the control in place, verification method, and review date.
• Continuous reachability telemetry: is the asset reachable from the internet, from the corporate network, from partner or guest segments? Answer on a schedule, not once.
• Egress telemetry: a deny-all segment should produce near-zero egress events. Any event is a control failure worth an alert, not a dashboard metric.
• Drift telemetry on the controls themselves: firewall policy changes, new listening ports, new DNS records, new certificates, re-established vendor tunnels, new outbound destinations.
• Exploitability context, not just severity: pre-auth and remote conditions, KEV membership, EPSS, public exploit references — the difference between "we'll get to it" and "this changes the plan."
• Alert quality metrics: percentage of alerts mapped to an owned asset with a documented control, and mean time to verify a control. A queue that cannot tell you which alerts touch an unpatchable asset is not actionable.
• A3-style signal detection: plaintext imperative strings addressed to analysis systems inside binaries, with extraction pipelines sandboxed and treated as evidence only.

Evidence that confirms the hypothesis: an exposed asset that should be isolated, a reachable service on a deny-all segment, a response difference between the intended control state and the observed state, or a match against an advisory for the frozen version. Evidence that rejects it: zero egress events, no inbound reachability from untrusted zones, and a control assertion that passes on schedule.

What to do

1. Build a real exception register. Asset, owner, business justification, control, verification method, expiry. "Accepted risk" with no control is a decision, not a mitigation — and it should be signed by someone who owns the business process.
2. Reduce reachability before arguing about severity. Off the internet, inbound denied from untrusted zones, egress denied by default. Most legacy compromise stories end at "it was reachable."
3. Write controls as testable assertions. "No inbound TCP/443 from the internet to this host" is verifiable. "Isolated environment" is a vibe.
4. Layer at least three controls. Segmentation plus allowlisting plus constrained service accounts plus a jump host with MFA and session recording. Single-layer isolation fails on the first exception.
5. Virtual patch where the vendor offers it. WAF rules, IPS signatures, configuration toggles, and feature disablement buy real time when the binary is frozen.
6. Instrument the segment, not only the host. Flow, DNS, and firewall-deny logs catch the discovery phase host telemetry never sees.
7. Verify control state continuously. Weekly for internet-facing controls, after every network change, and after every vendor maintenance window — those are exactly when isolation quietly breaks.
8. Prioritize by exploitability and reachability. A medium-severity pre-auth remote flaw on a reachable host outranks forty informational findings on an isolated one.
9. Give every exception an exit plan. Replace, re-platform, or deliberately re-accept with a date. Compensating controls are a bridge; some bridges last years, but they should be inspected.
10. Treat untrusted text as evidence, never as instructions across AI-assisted triage, malware analysis, and exposure enrichment pipelines.
11. Report outcomes, not activity. How many unpatchable assets, how many controls verified this quarter, exposure regression trend, and time to verify a control.

FAQ

What makes an asset truly unpatchable? Any constraint that blocks the normal remediation path: an unsupported OS the vendor software depends on, certified or embedded hardware, a process with no maintenance window, or a vendor lock with no viable alternative. The patch exists somewhere — you just cannot apply it in time or at all.

Is network isolation enough as a compensating control? Alone, no. Isolation fails silently through rule drift, alternate paths, and vendor maintenance tunnels. Treat it as one layer, verify it continuously, and pair it with allowlisting, constrained identity, and segment-level telemetry.

How often should compensating controls be validated? At minimum weekly for internet-facing controls, after every network or firewall change, and after every vendor maintenance window. Annual validation is a compliance ritual, not a control.

Does compensating control management replace patching? No. It buys time and reduces likelihood where patching is blocked. Every exception should still carry an exit plan — replace, re-platform, or formally re-accept with a review date.

Is CTEM just vulnerability scanning? No. Scanning produces findings; CTEM is the operating loop around them — discovering and maintaining the asset inventory, validating which findings represent real exposure, prioritizing by exploitability and business context, gating what reaches the SOC queue, and measuring whether exposure actually went down. A scanner can tell you an asset is unpatched; it will not tell you whether the control around it still holds.

How do we measure whether a compensating control actually works? Define a testable assertion, then measure it repeatedly: attempted inbound connections that were denied, egress events from a deny-all segment, drift events in firewall policy, and mean time to verify. If you cannot produce a number, you have a narrative, not a control.

Where does AI change this picture? On both sides. Attackers are embedding natural-language instructions in malware to steer AI-assisted analysis, and defenders increasingly use AI for triage. The invariant is the same: text from an untrusted source is evidence, never a system directive. Teams should also alert on imperative language addressed to analysis systems.

How do we satisfy auditors who want a patch date? Give them the exception register instead: the business justification, the compensating control, the verification evidence, the owner, and the review date. Documented, verified, time-bound risk acceptance is a defensible position; an undated "accepted risk" line is not.

Where this fits in a program

Compensating controls only hold if you keep checking them. An attack surface inventory finds the legacy hosts and orphaned services that never made it into the CMDB, and validation ensures a scanner hit is not proof of exposure. API surface testing and deeper web application testing matter most when the business-critical app is the one you cannot take offline. Trusteed supports that loop with continuous re-checks of exception assets.

Sources

• Trusteed CTEM — platform overview and product capabilities: https://trusteed.io
• Trusteed app — live dashboards, findings, and reporting: https://app.trusteed.io
• Trusteed blog — CTEM program design, prioritization, and vulnerability intelligence narratives: https://trusteed.io/blog
• Cisco Talos Threat Source — "Making sure the checks get printed": https://blog.talosintelligence.com/making-sure-the-checks-get-printed/
• NIST SP 800-40 Rev. 4 — Enterprise Patch Management Planning: https://csrc.nist.gov/pubs/sp/800/40/r4/final
• NIST SP 800-53 Rev. 5 — Access Control (AC), System and Communications Protection (SC), and Configuration Management (CM) control families: https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• OWASP Top 10 for LLM Applications — LLM01 Prompt Injection: https://genai.owasp.org/llm-top-10/