Skip to content
FigTechnical Guides
Technical Guides

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

Jay Hopkins
Last reviewed: 18 April 2026
11 min read
Share:

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.

What the rule requires

The NCSC requirement under v3.3 is that every in-scope device is protected against malware by one of three approaches:

Approach A: Anti-malware software. Traditional endpoint antivirus or endpoint detection and response (EDR). Software runs on the device, scans files, and either quarantines or blocks malicious content.

Approach B: Application allow-listing. Only approved applications can run on the device; everything else is blocked by policy. No antivirus scanning is needed because unknown executables cannot execute in the first place.

Approach C: Sandboxing. Applications run in a sandbox that isolates them from the rest of the device. This is acceptable for specific use cases but is rarely the whole answer for a general-purpose device estate.

Most organisations use Approach A. Some larger organisations with tighter environments use Approach B. Approach C typically features as a supplement to A or B rather than as a standalone posture.

Does Windows Defender count for Cyber Essentials?

Yes, Windows Defender (now Microsoft Defender Antivirus) qualifies as malware protection for Cyber Essentials. It is built into Windows, is fully supported, updates automatically via Windows Update, and meets the scheme's functional requirements. The assessor will not reject it because it came with the OS.

What does matter is how it is configured:

  • Real-time protection enabled
  • Automatic definition updates enabled
  • Cloud-delivered protection enabled (this materially improves detection)
  • Tamper protection enabled (stops standard users or compromised processes from disabling it)
  • Not disabled or excluded via Group Policy "for performance"
  • If Windows Defender is configured properly on every Windows device, this control passes. Where applicants trip up is when a third-party antivirus was installed, the user uninstalled it, and now neither the third-party product nor Defender is actively protecting the device. Defender automatically re-enables when a third-party AV is removed, but only if the third-party properly deregisters itself — and several do not.

    The same logic applies to macOS built-in protections (XProtect, Gatekeeper, System Integrity Protection). For dedicated Cyber Essentials Plus audits, assessors will verify these are active and that Gatekeeper has not been disabled via `spctl --master-disable`.

    When is application allow-listing the better approach?

    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. For Cyber Essentials purposes, any of these is acceptable; the assessor is looking for a technical enforcement mechanism and a documented process for adding approved applications.

    What about "next-gen" antivirus and EDR?

    Products like CrowdStrike Falcon, SentinelOne, Microsoft Defender for Endpoint, Sophos Intercept X, Bitdefender GravityZone, and similar EDR tools all qualify. They are antivirus products with additional behavioural and response capabilities. Under Cyber Essentials, they meet Approach A provided they are configured with real-time protection and automatic updates — which is their normal operating mode.

    The fact that they cost more or do more than a consumer antivirus does not materially change how the scheme views them. It views them as antivirus. The practical benefit of EDR for Cyber Essentials is that most EDR products provide better reporting and coverage visibility, which makes the Plus technical audit much smoother because the assessor can verify deployment status easily.

    Does antivirus need to run on servers?

    Yes, if the server is in scope. The rule does not distinguish between workstations and servers. Every in-scope device needs malware protection via one of the three approaches.

    For Windows Servers, Microsoft Defender Antivirus is built in from Server 2016 onwards and qualifies. For Linux servers, the scheme accepts several postures: a Linux-capable antivirus (ClamAV, Sophos for Linux, CrowdStrike Falcon), application allow-listing (SELinux or AppArmor with a suitably restrictive policy), or a documented hardening approach that limits what can execute on the server combined with an EDR agent.

    What does not work is "the server doesn't need antivirus because it only runs our application". It does. Every in-scope device does.

    What about phones and tablets?

    Under v3.3, phones and tablets that are in scope (company-issued or BYOD that accesses organisational data) need malware protection. For most phones this is met by:

  • The mobile OS's built-in protections (iOS sandboxing and signed app model, Android's Google Play Protect)
  • Not enabling sideloading or developer mode on devices used for work
  • Keeping the OS version supported and patched
  • If a phone is managed via MDM (Intune, Jamf, Kandji) and policy prohibits sideloading and developer mode, the malware protection requirement for mobile is typically met without an explicit mobile antivirus product. If a phone is jailbroken or rooted, it cannot be in scope.

    The specific scenario assessors look for: BYOD Android devices where the user has enabled "Install unknown apps" for their personal use. On a BYOD device that accesses work email, this is a compliance gap unless MDM prevents the app store settings from being changed.

    What happens when malware is detected?

    The question set asks about your response process, not just your prevention posture. A passing answer includes:

  • 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
  • For self-assessed Cyber Essentials, the question can be answered at a high level. For Cyber Essentials Plus, the assessor may ask for evidence of a recent detection and your response to it.

    The five malware protection failures I see most often

    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. User-disableable protection. Windows Defender is deployed but tamper protection is off, so any user with local admin can disable it at will.

    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. "Our servers don't need antivirus" is a legacy sysadmin position that does not pass under v3.3. Every in-scope server needs coverage.

    Pre-submission malware protection checklist

    1. Inventory vs coverage. Can you reconcile your device inventory against your antivirus deployment report and show 100% coverage? If no, fix before submitting.

    2. Real-time protection. Is real-time protection enabled on every covered device, with no persistent disablements?

    3. Automatic updates. Are definition updates automatic and verified as working? Sample three devices — when did they last pull definitions?

    4. Tamper protection. Can a standard user disable the antivirus on their own device? If yes, turn on tamper protection.

    5. Server coverage. Every in-scope server has malware protection via antivirus, EDR, or a documented application allow-list / hardening posture.

    6. Mobile devices. BYOD and company phones prevented from sideloading via MDM or documented policy.

    Bottom line

    The malware protection question is not asking whether you have antivirus. It is asking whether antivirus (or its equivalent) is deployed, configured, updating, tamper-protected, and actively running on every single device in your scope. The submissions that pass first time answer with specifics — tool name, deployment percentage, tamper protection status, update mechanism. The submissions that get feedback answer with generalities.

    Windows Defender is fine. Bitdefender is fine. CrowdStrike is fine. ClamAV on Linux is fine. AppLocker is fine. Pick one, deploy it consistently, and be able to describe it in specifics.

    Check your readiness | View pricing | Talk to an assessor

    About the author

    Jay Hopkins

    Jay Hopkins

    Managing Director, Fig Group

    IASME-licensed Cyber Essentials AssessorIASME Cyber Assurance Assessor

    Jay Hopkins is the Managing Director of Fig Group and an IASME-licensed Cyber Essentials assessor. He was previously Head of Technology for a global regulated firm. He works with UK organisations across regulated sectors on baseline compliance, supply-chain assurance, and AI-augmented security tooling.

    Connect on LinkedIn

    Want to see how Fig handles this?

    Discover how Fig helps organisations prepare for security assessments and maintain ongoing compliance.

    Request a demo
    JH

    Jay Hopkins

    Managing Director, Fig Group

    Jay Hopkins is the Managing Director of Fig Group and an IASME-licensed Cyber Essentials assessor. He was previously Head of Technology for a global regulated firm. He works with UK organisations across regulated sectors on baseline compliance, supply-chain assurance, and AI-augmented security tooling.