Malware Protection for Cyber Essentials: What Qualifies and What Does Not

"We have antivirus" is not an answer to the Cyber Essentials malware protection question. It is a starting point, but the question set asks specifically how malware protection is configured, which devices it covers, whether it updates automatically, and what happens when it detects something.

This guide walks through what actually passes - including the option to use application allow-listing instead of traditional antivirus - and the mistakes that most often trigger feedback during the assessor review.

The NCSC v3.3 requirements, pages 23-24, offer two routes. A mechanism must be active on every in-scope device, kept up to date according to its vendor and configured for the chosen route.

Anti-malware software: Windows and macOS devices, including servers. It must prevent malware running, prevent malicious-code execution and prevent connections to malicious websites, with updates in line with vendor recommendations.

Application allow-listing: all device types. Actively approve applications before deployment, maintain a current approved list and restrict execution through code signing. Users must not be able to install unsigned applications or those with invalid signatures.

Sandboxing can strengthen a design but is not a third independent scheme route. A product label, containment policy or Linux antivirus package alone does not demonstrate the required application approval and code-signing controls.

Microsoft Defender Antivirus can form part of a compliant Windows anti-malware configuration; a built-in product is not disqualified because it comes with the OS. Verify the actual functions and settings rather than treating its name as an automatic pass.

Check active prevention, current updates and protection against connections to malicious websites. Use the supported Microsoft controls appropriate to the device and licence. If a third-party product replaces Defender, verify which protection is actually active and that removing it has not left a gap.

Cloud-delivered protection and tamper protection are useful hardening settings. They are not separately named universal Cyber Essentials pass criteria. Standard users and normal daily activity should not undermine the required controls.

For macOS, check the effective combination of malware/code prevention and malicious-website blocking, or implement the approved code-signed application route. Naming XProtect, Gatekeeper and System Integrity Protection alone does not establish every required function.

Application allow-listing is stronger than traditional antivirus because it blocks unknown executables by default, not just known-bad ones. The scheme explicitly allows it as an alternative to antivirus.

The circumstances where it makes sense:

• Fixed-purpose workstations where the software set is small and stable (point of sale, manufacturing controls, kiosk machines)
• Highly regulated environments where unauthorised software installation is a compliance issue in its own right
• Organisations with mature IT that are comfortable maintaining an allow-list

For most UK SMEs, traditional antivirus (or EDR) is more practical. Allow-listing requires someone to maintain the list, approve legitimate new software, and manage the exceptions that come up during business-as-usual work. It is not a "set and forget" approach.

Tools that deliver Approach B at enterprise scale include Microsoft AppLocker, Windows Defender Application Control (WDAC), and third-party products like ThreatLocker and Airlock Digital. Verify the actual configuration: active approval before deployment, a maintained list, code-signing restrictions and prevention of unsigned or invalidly signed application installation. Not every policy available in these products meets that route.

EDR products can provide useful behavioural detection, response and estate reporting. Their product category alone does not establish Cyber Essentials coverage. Check the purchased edition and deployed settings against the anti-malware functions: vendor-aligned updates, prevention of malware and malicious code, and blocking connections to malicious websites. Where another control supplies a required function, explain the combination.

Keep additional detection, investigation and response features distinct from the minimum prevention controls.

In-scope servers need a qualifying malware protection mechanism. Windows and macOS servers can use the anti-malware route or the approved code-signed application route. The published anti-malware option is for Windows and macOS; do not assert a blanket Linux antivirus or hardening equivalence.

For Linux and other platforms, demonstrate the application approval, maintained list and code-signing restrictions of the all-device allow-listing option. SELinux or AppArmor containment alone is not evidence of those controls. Discuss practical implementation with the certification body before assuming a package name or restrictive policy is sufficient.

Phones and tablets accessing organisational data or services need applicable malware protection. For the application route, explain how apps are approved before deployment, how the approved list is maintained and how signing restrictions prevent unsigned or invalidly signed applications being installed.

The OS app-store/signing model can support this, but not every installed app is automatically approved by your organisation. Review sideloading and exceptions against the actual control. MDM can help enforce the policy; it is not a universal scheme requirement, and developer mode alone is not the published pass/fail test.

Beyond the scheme prevention baseline, we recommend a response process including:

• Notification. The IT team is notified automatically when a detection occurs (EDR tools handle this out of the box; consumer antivirus often does not)
• Triage. Someone looks at the alert rather than letting them pile up in an inbox
• Containment. The infected device is isolated (disconnected from the network, disabled in Entra) while the detection is investigated
• Remediation. The detected malware is removed, the device is re-imaged if needed, and the vector is identified

These incident-response steps are good practice; they are not a universal four-step Cyber Essentials certification condition. Plus follows the applicable technical test specification rather than requiring a recent real incident in every organisation.

1. Coverage gaps. Antivirus deployed to 90% of devices but three laptops missed during imaging. The CIO's laptop, the CEO's personal-use-but-also-work-email MacBook, the shared reception PC. Picked up in the Plus audit when the asset inventory does not match the deployment report.

2. Disabled real-time scanning. Someone turned off real-time protection for a specific reason and never re-enabled it. Often traced back to a software installer that flagged false positives two years ago.

3. Ineffective protection. Required prevention is disabled or undermined in normal use. Tamper protection can help harden the setup; its checkbox alone is not a universal scheme pass/fail test.

4. Third-party AV that is not updating. A subscription expired, a renewal was missed, definitions are six months old, and the product is silently failing to update. The device still reports "protected" in its own UI but has not pulled definitions since the licence lapsed.

5. Servers excluded from coverage. Every in-scope server needs a qualifying route. Check Windows/macOS anti-malware functions or the all-device approved code-signed application route; a Linux hardening narrative alone is insufficient.

1. Inventory and route. Reconcile every in-scope device with its applicable qualifying mechanism.

2. Anti-malware prevention. For the Windows/macOS route, verify malware and malicious-code prevention is active.

3. Website blocking. Verify prevention of connections to malicious websites; antivirus installation alone does not prove this.

4. Updates. Check that protection is current and updates follow vendor recommendations.

5. Approved applications. For the alternative route, evidence active approval, the current list and code-signing restrictions, including unsigned/invalid-signature installation prevention.

6. Optional hardening. Review tamper/cloud-delivered settings and response procedures separately from the scheme minimum.

Describe the qualifying mechanism on each platform and show that its required functions are active. Built-in controls can be suitable; product names, EDR labels, sandboxing and deployment percentages alone do not prove coverage.

Check your readiness | View pricing | Talk to an assessor