The April 2026 update to Cyber Essentials went live for new applications on the 26th of last month. Two of the changes will land hardest on businesses with older software in their estate. Multi-factor authentication, the practice of requiring a second login step such as a phone code or a security key alongside the password, now has to be enabled wherever it is available, not only for administrators. Cloud services can no longer be scoped out of an assessment. For a London SME that has been running on the same finance system for eight years and the same customer portal for five, the practical question is whether each of those systems can be defended at audit, or whether the conversation that has been postponed for a couple of years now has a date attached to it.
What actually changed in v3.3
The headline change is MFA. Under the previous version, requiring MFA only for administrators was acceptable. Under v3.3, if MFA is available on a service and not enabled, the assessment fails. That single sentence will rule out a number of older line-of-business apps that support MFA only via a paid add-on, or that support it for the cloud frontend but not for the locally hosted admin tools.
The second change matters for any business that has moved part of its workload to a SaaS or IaaS provider. Cloud services in scope can no longer be excluded by argument; they sit in scope by default. That removes a manoeuvre several London SMEs have been using to keep certification cost down: certify the on-prem footprint, leave the marketing-stack SaaS off-piste.
The web applications section has been renamed application development and now references the UK Government’s Software Security Code of Practice. The scoping section has been tightened so any exclusion now needs an explicit, defensible justification. Backups have been moved earlier in the document. None of these are radical, but together they make a thinner case for putting off a legacy review.
What the legacy estate looks like in a typical London SME
The picture is rarely dramatic. There is usually a CRM that was the right call in 2019 and has been drifting since. A finance package whose support contract was let lapse two years ago because the renewal cost was hard to justify against actual usage. A customer-facing portal sitting on a framework that the original developer recommended at the time and has since stopped recommending. None of these systems are broken in a way that anyone has had time to fix.
The DSIT central-government data shows 28% of government IT systems are now classified as legacy, with a quarter of those rated red risk. The number for SMEs is harder to pin down, but the Cyber Security Breaches Survey 2025 puts the share of UK businesses that have suffered a breach in the last twelve months at 43%. Many directors of London SMEs already know that legacy software is uncomfortable to live with. What April’s update has changed is the cost of postponing a decision about it, because the certification that customers and procurement teams ask about has moved.
Each system in the estate sits in a different place on the modernise vs maintain spectrum, and applying a single rule across the whole estate usually leaves money on the table somewhere. Retire-and-replace is the right call for a finance package whose support contract has lapsed. The CRM may need nothing more than a six-month rehost onto something supported. With a customer-facing portal, the cleanest path is a refactor that keeps the underlying data model intact and rewrites only the layer the customer sees.
Modernise, replace, or retire
The honest first cut is which systems should still exist at all. Some legacy software is being kept alive because nobody has owned the question of whether it is needed. Once that pile is removed, the rest splits roughly into three. Some systems are fit for purpose but living on infrastructure that needs lifting onto something supported. Some have valuable data and the right workflow, but the technology underneath has aged out. The third group should be replaced outright.
What April’s update has added is a fourth set: systems that work fine in operational terms but cannot be made to satisfy MFA-everywhere or scoped-out cloud. Those are the ones that get pulled forward. The question for these systems has moved from “should we modernise this in the next eighteen months” to “what is the smallest defensible move we can make before the next certification cycle”.
When the engineers need to be in the room
A Cyber Essentials remediation that touches legacy software is rarely a desk exercise. The MFA story for an older line-of-business app depends on host configuration, an integration point with the directory service, and a couple of historic authentication decisions that nobody wrote down at the time. Mapping what can be switched on safely, and what needs replacing because the supplier has no MFA roadmap, is the kind of work that calls for a senior engineer with the system in front of them and an IT lead sitting alongside.
For directors planning the next certification cycle, bespoke software development in London offers the option of bringing that engineering capability physically into the building. Senior engineers can walk the legacy estate with the IT team, separate the systems that can have MFA enabled this quarter from the ones that need replacing, and put a fixed-price number against any rebuilds before the budget paper goes to the board. Every project is fixed-price, so the cost of the remediation is settled before the work begins; if the build takes longer than expected, Red Eagle Tech absorbs the difference. The system the business owns at the end is documented, supported, and built by senior engineers who stay engaged after launch rather than handing it off once the audit is signed.
Where to start this quarter
Three first moves cover most of the work. List every system in the business that authenticates users, in or out of cloud. Mark each one for whether MFA is available and currently enabled, available and not enabled, or unavailable. The systems in the middle column are the ones that decide whether the next certification cycle is straightforward or expensive.
Once that list exists, the question of what to modernise stops being abstract. The systems that have to move are the ones with available MFA that has not been turned on, or the ones where MFA is not on the supplier’s roadmap. Everything else can wait. That is enough to take to a conversation about scope and budget without committing to a transformation programme that the business does not need.
