Skip to content

Supply Chain & Resilience

Legacy and future resilience

What this is

Legacy estate risk management addresses systems that can no longer be patched, supported or safely changed, but which the organisation still depends on. It covers identifying what is genuinely unsupported, assessing what each system exposes, applying containment where replacement is not near-term, and sequencing a realistic route out.

The problem

Everyone knows which systems are the problem. Nobody has a defensible position on them.

Legacy risk is rarely a discovery problem. Ask any engineering team and they will name the systems immediately: the database on an unsupported version, the application whose vendor stopped shipping updates, the server that cannot be rebooted because nobody is sure it will come back. The knowledge exists.

What does not exist is a position. Replacing it is a multi-year programme that keeps losing to product work, which is a rational commercial decision and is not the same as a risk decision. So the system sits there, everyone is uneasy, and if an auditor asks, the answer is that it is on the roadmap.

The useful work is separating three things: what the system actually exposes today, what containment is achievable in weeks rather than years, and what the genuine sequence out looks like with dates and dependencies. That turns an uncomfortable known into a decided risk with compensating controls, which is defensible even while the system is still running.

Who this is for

  • Organisations carrying systems that cannot be patched and cannot be replaced quickly.
  • Companies whose auditors have raised legacy technology and received a roadmap reference in response.
  • Firms whose cyber insurance now asks specifically about unsupported software.
  • Teams facing Cyber Essentials, where unsupported software in scope is an outright fail.
  • Organisations holding data with a retention period long enough that the quantum transition is a real planning horizon.

Delivery

How the engagement actually runs

Sprints inside your engineering cycle, with findings arriving continuously rather than a report arriving at the end. Durations are elapsed time for a typical scope, and get re-scoped against your estate before anything is committed.

  1. 011-2 weeks

    Establish the real estate

    What is genuinely unsupported, from asset data and vendor lifecycle records rather than from impression.

  2. 022 weeks

    Assess exposure

    What each system actually exposes, so the risk conversation is specific instead of categorical anxiety about old technology.

  3. 032-4 weeks

    Contain

    Segmentation, access restriction and monitoring on the highest-exposure systems. This is where risk drops fastest and cheapest.

  4. 042 weeks

    Sequence the exit

    A dated plan with dependencies and cost, plus recorded acceptance for what stays in the meantime.

Deliverables

What you actually receive

Artefacts your team owns and can maintain after the engagement, not a report that ages the moment it lands.

Deliverables for Legacy and future resilience, with what each one contains and when it lands
DeliverableWhat it containsWhen
Unsupported estate inventoryWhat is genuinely out of support versus merely old, with vendor end-of-life dates and what each system actually does.Week 2
Exposure assessmentFor each legacy system: what it holds, what reaches it, what it reaches, and what an attacker gains by compromising it. Specific rather than categorical.Week 3-4
Containment planNetwork segmentation, access restriction, enhanced monitoring and compensating controls achievable in weeks - the interim position while the replacement runs.Week 4-5
Sequenced exit planThe genuine route out, with dependencies, dates and cost, sequenced so the highest-exposure systems go first rather than the easiest.Week 5-6
Recorded risk decisionsWhere a system stays for now, an explicit acceptance by a named person with an expiry and a review - which is what makes the position defensible to an auditor.Week 6
Cryptographic inventoryWhere long-lived data is protected by algorithms with a finite horizon, as the input to post-quantum planning.Optional extension

Frameworks this touches

FAQ

Questions people actually ask

What counts as legacy technology for security purposes?

The operative definition is not age, it is supportability. A system is legacy for security purposes when it no longer receives security updates from its vendor, cannot be patched without breaking a dependency, or cannot be safely changed because the knowledge to do so has left. A ten-year-old system under active support is not legacy in this sense; a three-year-old appliance whose vendor exited the market is.

What can be done about a system that cannot be patched?

Containment, in roughly this order of value: restrict network reachability so only what genuinely needs to talk to it can, reduce and monitor privileged access, put enhanced logging and alerting around it since it will not defend itself, remove or reduce the data it holds, and where possible put a maintained component in front of it to terminate untrusted input. None of this makes it safe; it makes the exposure smaller and the compromise louder.

Does unsupported software fail Cyber Essentials?

Yes. Any software in scope that is no longer receiving security updates from its vendor fails the assessment outright. This applies to operating systems, applications, browsers and firmware. The usual routes are removing it from scope through genuine network segregation, replacing it, or purchasing extended support where the vendor offers it. Arguing it is low risk is not a route.

Should we be planning for post-quantum cryptography now?

It depends on your data's shelf life. The relevant risk is harvest-now-decrypt-later: encrypted data captured today and decrypted once a cryptographically relevant quantum computer exists. If your data stops mattering within a few years, this is not yet a priority. If you hold data that must stay confidential into the 2030s and beyond - health records, financial agreements, legal files, state secrets - then building a cryptographic inventory now is reasonable, because you cannot plan a migration for algorithms you have not located.

More in Supply Chain & Resilience

Start

Three ways in, depending on how close the deadline is.

Or just email a human: hello@cloudgap.ai

We reply within24 hours