Upcoming changes to Cyber Essentials in April 2025 and their potential impact

A subtle amendment has been made to the terminology, replacing "plugins" with "extensions." This alteration could introduce a bit of confusion, as the terms "plugins" and "extensions" are often thought to be synonymous but do have distinct meanings. Typically, plugins are used to enhance or add specific functionalities within a software application, often dependent on external code or frameworks. On the other hand, extensions are usually employed to add features or customisation options to web browsers such as Chrome, Firefox, or Edge.

Currently, without further clarification from the NCSC or IASME, it seems reasonable to deduce that browser extensions are now considered within scope. This interpretation suggests that wherever the term "software" is used within a requirement, extensions should also be taken into account. For instance, requirement 3 on "security update management", which states “ensure that devices and software are not vulnerable to known security issues for which fixes are available,” would now implicitly include browser extensions under the definition of "software" that needs regular updating.

The first significant update pertains to requirement 3, “security update management,” and it considerably broadens its scope. Previously, this requirement mandated organisations to patch critical and high vulnerabilities as classified by the CVSSv3 base scoring system if an update/patch had been available for more than 14 days. The revised requirement now also encompasses similar scored vulnerabilities that are not addressed through traditional patches or updates but are resolved through other methods such as registry fixes, configuration changes, scripts, or any other mechanisms approved by the vendor to rectify a known vulnerability.

A relevant example includes the widely-recognised "winverifytrust signature validation" vulnerability, which necessitated modifications to the Windows Registry to rectify the issue. In a Cyber Essentials Plus (CE+) audit, this would typically be treated as an advisory, and though we would urge the applicant to address the issue owing to its direct impact on device security, failure to resolve it wouldn’t necessarily result in failing the audit. This enhancement to the requirements is a positive development, as misconfigurations scored as critical or high can considerably weaken an organisation's security posture. Prior to this change, focusing solely on patching left gaps in an organisation’s defences. This revision ensures more robust defences and upholds the integrity of the Cyber Essentials scheme.

Applicants are encouraged to begin preparations by conducting authenticated vulnerability scans on in-scope end user devices and servers continuously. Moreover, they should establish robust processes to address any identified critical and high vulnerabilities within a 14-day timeframe, thereby strengthening their security measures and compliance with updated standards.

Verified that the scope of the Cyber Essentials Plus assessment matches the scope described by the valid Cyber Essentials self-assessment certificate

Verified by technical means that the scope of the Cyber Essentials Plus assessment matches the networks and systems being assessed

A major change to the standard (not the testing) but an additional activity that will be performed as part of the audit. The assessor is now tasked at ensuring the scope of the CE+ audit matches what was provided on the self-assessment. Without any official guidance from IASME we are simply making assumptions here on how this will be performed, such as reviewing asset management systems such as Intune for device quantity and operating systems in use, any discrepancies may introduce what’s know as “scope creep” which means newly discovered devices or changes to the quantities provides may increase the sample size and require additional testing time. In preparation for this Claranet advises applicants to export asset registers from there management systems and upload these to the self-assessment, this way both parties have more assurance that there will be a lower chance of finding issues when the physical review of the management system is performed.

For the latter update the wording “by technical means” is used, here we can assume that the assessor will be tasked to verify that the networks and systems being assessed are true to the information that was provided to scope the engagement, this almost sounds close to the kind of activity that is performed during an internal penetration test where the tester will run network scans to determine visibility of networks and connected to systems, this may require the assessor to deploy a virtual machine into the applicants network to perform such tests, but at this point we don’t have any official guidance on the way this test will actually be performed.

We recommend that applicants begin reviewing their networks for “Shadow IT” that could potentially be discovered by the assessor during a real audit, if any originations are potentially worried about the impact of these additional tests Claranet recommends a discussion with one of our trained assessors and potentially a targeted gap analysis months before the renewal date.

This change provides additional integrity protection to the scheme and should help applicants identify any issues with asset management which is the fundamentals of cyber security as you cannot protect what you don’t have visibility over. Testing guidelines are usually provided closer to the release and Claranet should have updated methodologies for applicants to review before testing commences.

Another major change that doesn’t directly affect the test cases but a task that the assessor will need to perform with applicants that are not including their whole organisation in the scope of the assessment. Applicants that de-scope networks using VLAN configuration or boundary firewall will now be subject to test to verify that the segmentation is actually in place. Again without any additional guidance from the delivery partner IASME, we are just making assumptions on how this will be checked. We foresee this either being a manual review of the configuration via the admin console for firewall or switches being used to enforce the separation and could possibly include a physical test such as running an Nmap scan from both sides of the networks, any access controls lists may be reviewed where applicants are allowing certain traffic to cross between the border to ensure this is configured correctly, scanning could also occur to test the ability to connect to the devices that are whitelisted.

This welcome change again provides additional integrity to the scheme and should provide value to applicants by having their network segmentation controls reviewed by a security professional.

If applicants have any concerns with this new test, we recommend a review using internal resource or external to ensure the configuration is compliant before your audit, remediate if any issues are identified these may need to be remediated and applicants have 30 days only to perform this and re-test.

As discussed in the changes to the requirements document this update to include the definition of vulnerability fix now incorporates the following vulnerabilities if discovered during the authenticated check of patching: Vulnerability fixes include patches, updates, registry fixes, configuration changes, scripts or any other mechanism approved by the vendor to fix a known vulnerability.

Previously, this was an advisory for certain misconfigurations that required configuration changes to resolve the vulnerability, this will now become in-scope and applicants will be required to resolve all critical and high vulnerabilities identify as part of the scan if the vendor has provided a vulnerability fix.

We advise that applicants begin reviewing vulnerability scan reports for these types of issues. If vulnerability scanning is not currently occurring, organisations should look to integrate a suitable scanner, either one managed by the applicant or using a third-party, when selecting a scanner they should be chosen from the PCI ASV (Approved Scanner List) such as Tenable or Qualys.