“We have not had a breach” is evidence about known history. It is not an assessment of current security.
A legacy platform can continue to serve users while carrying unsupported components, weak access, unmonitored integrations or recovery assumptions that have never been tested. Conversely, age alone does not make a platform insecure. The organisation needs an asset-level view of exposure, controls and consequence.
This article focuses on security assessment. Our separate end-of-life article covers lifecycle governance, support and migration decisions more broadly.
Start with the actual asset and attack surface
“The CMS” may include an application, framework, runtime, operating system, database, plugins, themes, custom code, hosting control plane, content delivery service, identity provider and integrations. One supported product name can conceal an obsolete dependency.
Create an inventory that records:
- component, version and owner;
- location and environment;
- vendor or maintainer support status;
- data processed and retained;
- users, roles and privileged access;
- internet and third-party exposure;
- dependencies and trust relationships;
- last update and current patch route;
- logging, monitoring, backup and recovery; and
- business service and possible client consequence.
Validate the inventory through discovery and configuration evidence where appropriate. A spreadsheet maintained only from memory can miss the forgotten plugin or test environment that creates the weakest route.
The NCSC’s vulnerability-management guidance on identifying assets says organisations should identify and monitor systems, services, cloud infrastructure, hardware and software, and categorise obsolete or extended-support products. Use the current guidance with the organisation’s own security framework and qualified specialists.
Understand what a CVE does and does not tell you
CVE, Common Vulnerabilities and Exposures, provides identifiers for publicly disclosed vulnerabilities. A CVE entry can help teams connect supplier advisories, security tools and remediation information.
Its presence does not prove that a specific system is exploitable. Version, configuration, reachability, prerequisite access and compensating controls all matter. Its absence does not prove safety; a weakness may be undisclosed, unassigned or specific to custom code and configuration.
For each relevant vulnerability, establish:
- whether the affected component and version are present;
- whether the vulnerable function is enabled and reachable;
- the possible confidentiality, integrity and availability effect;
- whether a supplier fix exists and has been applied;
- which temporary controls reduce likelihood or impact;
- how exploitation would be detected; and
- who accepts residual risk and until when.
Prioritisation should combine technical severity with service context. A lower-scored weakness on a public, privileged route may deserve faster action than a higher-scored issue in an isolated component.
Four areas commonly hidden by “working fine”
Patch and support reality
Check the last successful security update, current update channel and supplier lifecycle position for every component. Verify that automatic or scheduled processes actually completed.
Unsupported software may receive no vendor fix for a newly discovered weakness. Extended support can have limits. Custom backports may be possible and create their own assurance and maintenance burden.
The NCSC’s guidance on obsolete products explains that risk-reduction controls cannot create a risk-free way to continue using obsolete products. Where immediate migration is infeasible, reduce both the opportunity for compromise and the possible impact, with a long-term path away from the obsolete product.
Identity and privilege
Older platforms often accumulate accounts, shared credentials, broad administrative roles and integrations authenticated with long-lived secrets. These conditions may create more immediate risk than the platform version itself.
Review joiner, mover and leaver processes; administrator count; multi-factor authentication; service accounts; secret rotation; session handling; supplier access; and logging of privileged activity. Remove unused accounts through an approved process and test that essential automation does not depend on them.
Do not assume an external identity provider solves authorisation inside the application. Authentication confirms identity; the platform must still enforce appropriate permissions.
Integration and silent failure
Connections to forms, CRM, payment, email, analytics and identity systems expand the attack and failure surface. An integration can leak data, accept untrusted input or fail without a visible error to the user.
Map data direction, authentication, validation, encryption, retries, alerts and ownership. Test whether a successful front-end message corresponds to a successful downstream transaction. Monitor unusual volume and repeated failure as well as total outage.
Treat third-party changes as security events where they alter permissions, data flow or supported protocols. Release notes and supplier assurance need an owner.
Recovery assumptions
A backup is useful only if the organisation can restore the required service and data within its agreed needs. Legacy systems can depend on installers, licences, credentials or skills that are no longer readily available.
Test restoration in an appropriate environment. Confirm backup scope, integrity, isolation, retention, recovery sequence and responsibility. Include integrations and configuration, not only database content.
For important services, connect recovery testing to operational-resilience and business-continuity decisions. Security is also the ability to contain damage and return to a trusted state.
Check insurance without making assumptions
Cyber policies vary. Coverage, exclusions, warranties, conditions and disclosure duties must be interpreted by the organisation’s broker, insurer and legal advisers.
Ask specifically:
- what the proposal and policy say about supported software and patching;
- whether the current asset inventory matches statements made to the insurer;
- how known vulnerabilities and exceptions should be disclosed;
- which incident-response services and notification steps apply; and
- what evidence will be required following a claim.
Do not assume unsupported software automatically voids coverage or that modernisation will reduce the premium. Obtain written advice on the actual policy. Insurance transfers part of financial risk; it does not repair a vulnerability or satisfy the organisation’s duties.
Treat regulation as an assessment, not a threat
Where personal information is processed, the ICO’s system and network security audit framework includes assessing unsupported systems, maintaining software inventories, applying mitigating controls and following up vulnerabilities. The exact legal requirements and appropriate measures depend on the processing and risk.
Financial services, legal and other regulated firms may have additional obligations concerning resilience, confidentiality, governance, outsourcing, records or incident reporting. Qualified specialists should identify the rules that apply.
Avoid claiming that the existence of an unsupported component by itself proves a regulatory breach. Equally, avoid waiting for confirmed unauthorised access before governing a known weakness. Record the assessment, controls, residual risk and remediation plan.
Compare staying and moving on the same basis
Migration can introduce data loss, downtime, misconfiguration, access errors and new supplier dependence. Continued operation can preserve known processes while retaining vulnerabilities and concentration risk.
Compare scenarios:
- current-state controls and their tested effectiveness;
- additional containment required during deferral;
- migration and dual-running exposure;
- target-state architecture and operation;
- rollback and recovery;
- decommissioning of old assets; and
- the time for which each risk exists.
Do not assume the risk of staying rises at a fixed rate or that an emergency migration always costs a standard multiple of planned work. Use current vulnerability, supplier, incident and resource evidence.
Where immediate replacement is impossible, possible controls include reducing exposure, restricting data and privilege, segmenting systems, strengthening monitoring, removing vulnerable functions and isolating dependencies. Security specialists should determine suitability. Give each temporary control an owner, test and expiry.
Four questions for leadership
- Which components no longer receive routine security fixes, and how do we know?
- Which known weaknesses are relevant to our deployed configuration, and what is the current response?
- Can we detect, contain and recover from compromise of the service within our agreed needs?
- Who has accepted the residual risk, until what date and against which migration or retirement plan?
Add a fifth for insurance and regulation: which specialist has confirmed the current contractual and legal position?
The companion article on what happens when your only developer leaves addresses the knowledge-concentration risk that often accompanies legacy platforms.
Our legacy platform security risk checklist covers support, patching, insurance questions and lifecycle status. A traffic-light result is a prompt for investigation, not a security conclusion. Distinction also offers a 14-day platform security assessment and may benefit commercially from resulting migration work. Any security assessment should be led by appropriately qualified practitioners, define its scope and state what it has not tested.
The absence of a known incident is welcome. A defensible security posture comes from knowing the estate, testing controls, responding to relevant vulnerabilities and making the residual risk visible to the person authorised to carry it.
