Common Cyber Essentials failures and how to avoid them

For many UK SMEs, Cyber Essentials is less about chasing perfection and more about proving that the basics are in place and working consistently. That is the right way to think about it. The scheme is designed to reduce exposure to common attack paths, not to turn every organisation into a security specialist.

In practice, the organisations that struggle most are often not the ones with the weakest intent. They are the ones where everyday IT changes outpace control ownership. A laptop is added, a user is given admin rights for convenience, a legacy application is left running, or patching slips for a few weeks. Individually, these issues can seem minor. Together, they create the sort of gaps that cause avoidable failures.

This article focuses on the recurring problems we see in small and medium-sized businesses, and the practical steps that help prevent them. The aim is not to overcomplicate the process. It is to make the control set easier to manage in the real world.

What Cyber Essentials is trying to achieve for UK SMEs

Why the scheme focuses on common attack paths

Cyber Essentials is built around the controls that most directly reduce the chance of common, opportunistic attacks. That means it places emphasis on areas such as secure configuration, access control, patching, boundary protection, and malware defence. These are not abstract policy ideas. They are the practical settings and habits that stop everyday weaknesses from becoming easy entry points.

For SMEs, this matters because most businesses do not have unlimited time or budget. A baseline approach helps you prioritise the controls that deliver the most value first. If those controls are inconsistent, the rest of the security programme becomes harder to trust.

How to use the standard as a practical baseline rather than a box-ticking exercise

The most successful organisations treat the standard as a working baseline. They ask simple questions: which devices are in scope, who has admin access, how quickly are updates applied, and where do remote connections enter the network? Those questions are useful because they connect the control requirements to day-to-day operations.

That mindset also helps when you are preparing evidence. Instead of trying to assemble a last-minute folder of screenshots, you can show that the controls are part of normal administration. That is usually easier to maintain and easier to explain internally.

The most common reasons applications fail

Incomplete asset visibility and missing devices

One of the most common causes of failure is not knowing exactly what is in scope. If a device is connected to the business network, used to access business data, or managed as part of the organisation’s IT estate, it needs to be accounted for properly. Missing devices are a problem because they often become the place where controls are weakest.

This happens in SMEs more often than people expect. A director’s laptop may be managed differently from staff devices. A contractor’s machine may be overlooked. A spare device may still have access to email or cloud services. If you cannot see it, you cannot confidently say it is protected.

A practical way to reduce this risk is to keep a simple asset register. It does not need to be complex. Record the device type, owner, operating system, whether it is company-managed, and whether it is allowed to access business services. Review it whenever a device is issued, replaced, or retired.

Weak account management and poor password controls

Account management failures are another frequent issue. These include shared accounts, dormant accounts that were never removed, and accounts with more access than they need. Password problems often sit alongside them, especially where staff reuse passwords or where controls are inconsistent across different systems.

From a business perspective, the issue is not just technical. Poor account management makes it harder to understand who can access what, and it increases the chance that an old or unnecessary account becomes a route into the environment.

To avoid this, keep account administration tied to HR and leaver processes. Remove access promptly when people leave or change role. Avoid shared admin logins where possible. Where stronger authentication is available, use it consistently for remote access and important services. The goal is to make account control routine, not exceptional.

Configuration mistakes that often cause problems

Unmanaged admin rights and unnecessary software

Admin rights are a common source of avoidable weakness. If users have local administrator access on their laptops without a clear reason, they can install software, change security settings, and bypass safeguards that should remain in place. That makes it harder to keep devices in a known-good state.

Unnecessary software creates a similar problem. Every extra application increases the amount of software that needs patching, monitoring, and support. It also increases the chance that something old, unmaintained, or poorly configured remains on the device.

A sensible approach is to give admin rights only where they are genuinely needed, and to review software regularly. If a tool is not required for the business, remove it. If a user needs elevated access for a specific task, consider time-limited or supervised access rather than permanent rights.

Security settings that drift after rollout

Another common failure is configuration drift. This is when a device or service starts in a secure state, but settings change over time through exceptions, upgrades, or ad hoc troubleshooting. A setting may be relaxed to fix a problem and never restored. A new device may be built differently from the standard build. A cloud service may be configured by a different team with different assumptions.

Drift is especially common in smaller organisations because responsibilities are often shared. The person who set up the device may no longer be the person supporting it. The original build notes may be incomplete. As a result, the environment slowly becomes inconsistent.

The best defence is a standard build and a short list of approved exceptions. Keep a record of what should be applied to every device, and review deviations regularly. If you do not have a formal endpoint management platform, even a simple checklist can help keep the estate aligned.

Patch management gaps

Delayed updates on operating systems and applications

Patching failures are among the most common and most avoidable issues. The problem is rarely that updates do not exist. It is that they are delayed, missed, or applied unevenly. In some businesses, updates are postponed because staff are worried about disruption. In others, there is no clear owner for patching, so it becomes a background task that slips.

Cyber Essentials expects updates to be applied in a timely way. For SMEs, the practical answer is to define who is responsible, how updates are monitored, and what happens if a device repeatedly misses them. That may sound basic, but basic controls only work when someone owns them.

It also helps to distinguish between operating system updates and application updates. Many businesses focus on Windows or macOS patching but forget browsers, PDF readers, collaboration tools, and remote access software. Those applications are often just as important.

Why unsupported software creates avoidable risk

Unsupported software is a recurring issue because it is easy to overlook. A system may still work, so it stays in place. But if the vendor no longer provides security updates, the business is left carrying the risk. That is particularly problematic where the software is internet-facing, used for remote access, or installed on multiple endpoints.

Unsupported software is not always easy to remove immediately, especially if it supports a business-critical process. In those cases, the right response is to document the dependency, reduce exposure, and plan a replacement. That might mean isolating the system, limiting access, or moving the function to a supported platform.

The key point is that unsupported software should not be treated as a normal state. If it remains in use, it needs active management, not passive acceptance.

Firewall and network boundary issues

Overly permissive rules and exposed services

Firewall problems often come down to rules that are broader than necessary. A service may be exposed to the internet when it only needs to be available to a small group. A rule may allow traffic from anywhere when it should be restricted to known addresses. Over time, temporary exceptions can become permanent.

For SMEs, the challenge is usually not a lack of firewall technology. It is a lack of regular review. Rules are added to solve a business problem, but nobody revisits whether they are still needed. That is how the network boundary becomes looser than intended.

A useful habit is to review firewall rules against actual business need. Ask whether the service still exists, who uses it, and whether the source and destination can be narrowed. If a rule is no longer required, remove it. If it is required, document why.

Remote access that is not tightly controlled

Remote access is another area where small mistakes can have outsized impact. If remote access is available without strong authentication, if old VPN accounts remain active, or if access is open to more users than necessary, the control is weaker than it appears.

Remote access should be treated as a privileged route into the business. That means it needs the same level of attention as any other sensitive access path. Keep the user list small, review it regularly, and make sure the service is configured to the minimum level needed for the business.

Where possible, avoid leaving remote access enabled for convenience alone. If a user no longer needs it, remove it. If a supplier needs temporary access, time-limit it and review it afterwards.

Malware protection and endpoint hygiene

Missing or inconsistent protection across devices

Endpoint protection is only useful if it is actually present and working on the devices that matter. A common failure is inconsistency. Some laptops have the right protection, others do not. One device is excluded from monitoring because it is “special”. Another is not enrolled properly after replacement. The result is a patchwork of controls rather than a dependable baseline.

This is where visibility matters again. You need to know which devices are protected, which are not, and why. If you rely on a central management tool, check that devices are reporting correctly. If you do not, use a manual review process and keep it up to date.

It is also worth checking that protection is not merely installed, but active and maintained. Security software that is out of date, disabled, or bypassed by local exceptions does not provide the same level of assurance.

Local exceptions that weaken the overall control set

Exceptions are sometimes necessary, but they should be controlled. A local exclusion added to solve a compatibility issue can weaken the whole endpoint if it is too broad. Similarly, if users can disable protection without oversight, the control is less reliable than it looks on paper.

The practical answer is to keep exceptions rare, documented, and time-bound where possible. Review them regularly and remove them once the underlying issue is resolved. If a business process depends on repeated exceptions, that is usually a sign that the process or software needs a better fix.

How to prepare before you submit

Build a simple internal checklist

Before submitting, it helps to work through a short internal checklist. Confirm the in-scope devices. Check that admin rights are justified. Review patch status. Look at firewall rules and remote access. Confirm endpoint protection is active across the estate. Verify that unsupported software has been identified and managed.

This does not need to become a large project. In many SMEs, a one-page checklist is enough to surface the issues that matter most. The value is in consistency. If the same checks are repeated each time, you are less likely to miss something obvious.

Assign ownership for evidence and remediation

One of the easiest ways to avoid repeat failures is to make ownership explicit. Someone should be responsible for each control area, even if the business is small. That person does not need to be a full-time security specialist. They do need to know what good looks like and what to do when something drifts.

It also helps to separate evidence gathering from remediation. If the same person is doing both, small issues can be left unresolved because the focus shifts to submission. A clearer split makes it easier to fix problems before they become recurring weaknesses.

A practical approach to avoiding repeat failures

Treat controls as ongoing maintenance

The businesses that do best are usually the ones that treat Cyber Essentials controls as maintenance, not a one-off event. Devices change. Staff change. Suppliers change. Software changes. If the control set is not reviewed as part of normal operations, it will drift.

That is why simple routines matter. Review new starters and leavers. Check device enrolment when hardware is issued. Confirm patching after major updates. Revisit firewall rules when services change. These are small tasks, but they prevent the control environment from slowly weakening.

Review changes after new devices, users, or suppliers are added

Every new device, user, or supplier is a chance for controls to slip. A new laptop may be built differently. A new starter may be given more access than intended. A supplier may need remote access that was never properly restricted. If these changes are not reviewed, they can undo otherwise solid work.

A simple change review process is often enough. Before something is added, ask what access it needs, what protection it requires, and who will own it afterwards. That keeps the business aligned with the control set instead of working around it.

For many UK SMEs, that is the real lesson behind Cyber Essentials. The scheme is not asking for perfection. It is asking for discipline in the basics. If you can keep visibility, access, patching, boundary controls, and endpoint protection under steady management, you reduce the chance of avoidable failure and make the whole process much easier to sustain.

If you would like help turning these checks into a practical plan for your organisation, speak to a consultant.

Speak to a consultant