The starting point
“We can't patch it” is the start of the decision—not the end
Legacy technology can remain in service for legitimate operational reasons: a specialist application, embedded or monitoring equipment, an old database dependency, supplier restrictions or a replacement that could disrupt an important service.
Those constraints explain why normal remediation may not be possible today. They do not remove the vulnerability, reduce an attacker's opportunity or transfer accountability away from the organisation.
When the ideal control cannot be implemented, do not pretend the risk disappeared. Contain it, evidence it, govern it and keep working towards removal.
Choose safeguards that can be implemented and sustained now instead of leaving an infeasible action untreated.
Reduce reachability and potential impact when the underlying weakness cannot yet be removed.
Define the problem
Legacy risk is broader than an old operating system
A legacy asset may be unsupported, unable to receive security fixes, dependent on obsolete protocols, incompatible with current security tooling or too operationally constrained to meet the normal protection baseline.
Unsupported workstation
A device needed for a specialist workflow cannot run a supported operating system or modern endpoint agent.
Legacy server dependency
An essential application or database cannot be upgraded immediately without supplier, compatibility or migration work.
Embedded or specialist equipment
A device has a long operational life, limited security capability and a vendor-controlled update route.
Older remote pathway
A necessary dependency remains during migration but cannot meet the intended identity or network baseline.
A practical treatment method
Move through seven explicit decisions
- 01
Identify it
Record exactly what the asset is, what service it supports, where it is, who administers it and what depends on it.
Output:Known asset, dependency and accountable service owner. - 02
Understand why normal remediation is infeasible
Document the vendor, compatibility, hardware, cost or service constraint. Replace “we have always left it alone” with a current, reviewable reason.
Output:Evidence-based constraint and attempted options. - 03
Understand the exposure
Determine what can reach the asset, what it can reach, whether it faces the internet, which identities use it and which credible vulnerabilities or attack paths matter.
Output:Reachability, consequence and confidence assessment. - 04
Reduce the attack surface
Remove unnecessary services, software, accounts, protocols, administrative access and network paths wherever the system still permits change.
Output:A smaller set of required functions and trust relationships. - 05
Apply compensating controls
Use feasible safeguards such as segmentation, restrictive firewall rules, controlled administration, upstream filtering, stronger identity checks or application allow-listing.
Output:A defensible containment design linked to the identified risk. - 06
Monitor and evidence the boundary
Review firewall activity, authentication, vulnerability findings and relevant logs. Demonstrate that “isolated” is an operating control rather than an assumption.
Output:Current evidence, alert route and known visibility gaps. - 07
Govern the remaining risk and exit
Record the residual risk, decision owner, controls and approval. Set a replacement or retirement target where possible—or a firm next review date when the route is not yet known.
Output:Approved continued operation with a dated decision point.
Defence in depth
Compensating controls should address the same risk—not merely add activity
A useful compensating control reduces the likelihood or impact of the credible attack path created by the missing primary control. More than one layer may be needed.
Restrict network reachability
Place the asset in an appropriate zone and allow only documented sources, destinations, ports and services.
Control administration
Limit privileged access, use a managed administration route and remove shared, stale or unnecessary identities.
Remove what is not required
Disable vulnerable features, services, protocols and software that the essential workflow does not need.
Protect upstream
Use supported gateways, proxies, email controls or application boundaries to reduce malicious input reaching the asset.
Monitor meaningful signals
Collect usable boundary, authentication and system evidence with an owned route for investigation and response.
Prepare for compromise or failure
Maintain tested recovery options, known configurations, supplier contacts and proportionate incident actions.
Containment does not restore support
Compensating controls can reduce risk, but they do not make obsolete technology equivalent to a supported, patchable system. Keep replacement, redesign or retirement visible as the intended long-term treatment.
Evidence over assumption
Prove that the compensating controls operate
The asset, software, location, service dependency and owner remain current.
Required paths succeed and prohibited paths fail from representative network locations.
Firewall, identity, service and hardening settings match the approved containment design.
Relevant events are collected, reviewed and connected to a usable response route.
The organisation can restore the service, configuration or essential data within an understood tolerance.
The constraint, threat picture, control health and retirement options are reconsidered at the agreed trigger.
Lightweight governance
Keep a small legacy-risk record
The record should be concise enough to maintain but complete enough for someone outside the implementation team to understand the dependency, treatment and decision.
| Record | Question to answer |
|---|---|
| Asset or service | What exactly is the legacy dependency? |
| Business or service owner | Who depends on it and who owns the organisational consequence? |
| Reason remediation is infeasible | Why can it not currently be patched, upgraded, replaced or redesigned? |
| Exposure | What can reach it, what can it reach and which identities or data are involved? |
| Known risk | Which vulnerabilities, attack paths and service consequences matter? |
| Compensating controls | What reduces the likelihood or impact, and how does it address the identified risk? |
| Monitoring and evidence | How does the organisation know those controls are operating? |
| Residual risk | What remains after the treatment? |
| Decision and approval | Who has authorised continued operation, and within which tolerance? |
| Review or retirement target | When must the decision be revisited, and what events trigger an earlier review? |
Where continued operation creates material service, safeguarding, regulatory or business risk, the appropriate service owner or governance authority should make and record the decision.
The practical conclusion
Keep the treatment active until the dependency is removed
Patch, upgrade, replace or retire—then verify the exposure has reduced.
Contain, monitor, evidence and govern continued operation.
Reassess the treatment and accelerate replacement or stronger safeguards.
Revalidate the controls and retain the next review trigger.
What is the dependency? Why is remediation infeasible? Which attack path remains? Which controls contain it? What proves they work? Who owns the residual risk? When is the next decision?
A difficult replacement is a reason for deliberate risk treatment—not indefinite neglect.
Further guidance
Connect the treatment to recognised practice
- UK NCSC vulnerability-management guidance — segregate unsupported systems, apply appropriate controls, monitor proactively and capture remaining risk.
- NIST definition of compensating security controls — alternative management, operational or technical safeguards intended to provide equivalent or comparable protection.
- NIST SP 800-37 Rev. 2 — structured risk management, accountable authorisation and continuous monitoring through the system life cycle.
Research note: This treatment pattern develops the dissertation finding that infeasible preventive controls should lead to proportionate containment, detective safeguards and explicit residual-risk decisions—not untreated exceptions.
Voluntary support
Found this useful? Support Trends4You
Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they have helped you or your organisation, you can support the time and hosting that keeps them freely available.
Support is optional, handled securely by Stripe and does not provide additional access.