Bring-Your-Own-Device Sampling on Cyber Essentials Plus

Net Sec Group is an IASME and NCSC certification body. BYOD on Cyber Essentials Plus is the territory where applicants most often find an unexpectedly large sample, an unexpectedly small sample, or an unexpectedly broken scope statement. The IASME rules treat personal devices differently from corporate-owned devices, and the difference is not always obvious from a reading of the test specification.

This article walks the BYOD scoping question and the BYOD sampling question end to end. It walks four typical UK BYOD shapes through the assessor's scoping logic. It explains what evidence the assessor accepts for a personally-owned device when the firm cannot install agents on it.

If you are scoping CE Plus and have any user accessing in-scope work from a personal device, this is the explainer.

What "BYOD" means in CE Plus

In the IASME Cyber Essentials Plus test specification, BYOD is any device the firm does not own that handles in-scope data. The classic shapes are:

The test specification's question is not "who owns the device" but "does the device handle in-scope data". Ownership is a proxy. The substantive scoping question is the data-handling.

A device that handles in-scope data is in scope. A device that does not is out of scope. The middle category, where the device touches in-scope data only via documented technical controls that prevent local persistence (Conditional Access app-protection, Mobile Application Management policies, browser-only access with MAM), is the territory where most BYOD scoping debates happen.

The four scoping outcomes

For any BYOD device, the assessor's scoping logic produces one of four outcomes:

  1. In scope, full sampling: the device handles in-scope data, the firm has documented controls (typically MDM enrolment), the device is in the sample population for its build, the sample size formula applies as for corporate-owned devices
  2. In scope, partial sampling: the device handles in-scope data, the firm has documented Mobile Application Management or app-protection controls, the device is sampled for the controls the application-layer protection covers (anti-malware on the work app, MFA, data isolation), but not for OS-level controls the firm cannot reach
  3. Out of scope, documented: the device does not handle in-scope data, or the firm has scoped the device out via technical controls (Conditional Access blocks the device class, no in-scope data ever reaches the device), and the firm can produce documentation. Not in the sample
  4. Disputed: the device touches in-scope data in a way that is neither cleanly in nor cleanly out, and the assessor and applicant work through the specifics during scoping

Outcome 4 is more common than applicants expect. The first three outcomes are the clean cases.

The four typical UK BYOD shapes

These are four anonymised cases drawn from our 800+ assessment history. Each ends with a clear scoping outcome.

Shape A: personal smartphone with corporate Office 365 mailbox

The user has their personal iPhone. They have configured the Outlook iOS app with their corporate Office 365 account. The firm has not enrolled the device in MDM. The user can read corporate email on the personal phone and reply to it.

Scoping outcome: in scope. The personal phone handles in-scope data (the corporate email contents) without documented technical controls preventing local persistence. The phone is in the sample population for iOS as a build.

Sample contribution: the phone counts toward the iOS build's device count. If the firm has 8 personal phones running iOS 18, the iOS 18 build sample is 3 (per the IASME table from Cyber Essentials Plus Sample-Size Rules Explained).

Evidence the assessor accepts: the assessor cannot install agents on the personal phones. Acceptable evidence is:

The fix if no controls exist: deploy Conditional Access app-protection (Microsoft Intune App Protection Policies) targeting the corporate-data-handling apps on personal devices. The applicant deploys the policy at the tenant level; the user opts in by signing into the corporate apps. This is the scoping move that often shifts personal phones from "no controls, in scope" to "controlled in scope" and reduces the sampling burden.

Shape B: personal laptop with full MDM enrolment

The user has their personal MacBook. The firm has fully enrolled the device into Jamf as part of a "bring-your-own with management" policy. The user accepted the enrolment in exchange for a £20 monthly stipend. The Mac runs the firm's standard build, with all the same controls as a corporate-owned Mac.

Scoping outcome: in scope, full sampling. From a technical perspective the device is indistinguishable from a corporate-owned Mac. The fact that the user owns it does not change the sampling.

Sample contribution: the Mac counts toward the macOS build's sample like any corporate-owned Mac.

Evidence the assessor accepts: identical to a corporate-owned Mac. Jamf configuration profile exports, MDM policy exports, live screen-share verification on the sampled device.

The applicant's lever: this is the cleanest BYOD model from a CE Plus perspective. The user owns the hardware, the firm controls the configuration and the data, the assessor's tooling sees a managed estate. The administrative cost is the MDM stipend or equivalent commercial arrangement.

Shape C: personal phone with Outlook Web Access only

The user has their personal Android phone. The firm has Conditional Access policies in place that allow Office 365 access only via the browser, not via native apps. The user can read corporate email by signing into outlook.office.com on the phone's browser; the user cannot install the Outlook Android app and configure it with the corporate account.

Scoping outcome: out of scope, documented. The Conditional Access policy prevents the personal device from holding in-scope data locally; the email content lives in the browser session, not in a downloaded mailbox. With the Conditional Access policy and a documented scoping statement, the assessor accepts the device as out of scope.

Sample contribution: zero.

Evidence the assessor accepts: the Conditional Access policy export showing the policy applies to non-managed devices and restricts to browser-only, plus a tenant report showing personal devices that signed in did so via the browser path only.

The applicant's lever: this scoping move ("browser-only access for unmanaged devices") is the cleanest way to keep personal smartphones out of CE Plus scope. The administrative cost is the Conditional Access policy maintenance and the user-experience hit (no native app on personal devices).

Shape D: contractor laptop on a corporate VPN

The user is a contractor. They use their own laptop. They access the firm's network via the firm's corporate VPN. The contractor has admin rights on the firm's tenant. The contractor's laptop is not enrolled in the firm's MDM.

Scoping outcome: in scope, the assessor wants documented technical controls. The contractor's laptop handles in-scope data (the firm's tenant) and the contractor has admin access to the firm's cloud admin console. With no MDM enrolment and no Conditional Access app-protection, the laptop is fully in scope without any of the management controls that would let the assessor verify the in-scope controls.

Sample contribution: the laptop is in the sample population for its build. If the contractor's laptop is the only one on its OS version, the build's count is 1 and the sample is 1 device, but that 1 device has to satisfy the full set of controls.

Evidence the assessor accepts: in this configuration, the contractor's laptop has to satisfy the same controls as a managed in-scope device. The assessor walks the contractor through screen-share verification of: software firewall on, MDM-equivalent management state (or compensating controls), MFA on the corporate tenant, anti-malware reporting state, patching state, screen-lock state. The contractor's personal data is not part of the test; only the in-scope work surface is.

The fix: three options. (1) Enrol the contractor's laptop in a contractor MDM tier (Intune contractor-policy is one common pattern). (2) Deploy Conditional Access app-protection that constrains the contractor's tenant access to managed apps. (3) Issue the contractor a corporate-managed device for the in-scope work, scoping the personal laptop out via an explicit data-handling rule.

For deeper coverage of contractor BYOD policy implementation, see BYOD Cyber Essentials Policy Implementation Guide on netsecgroup.io. For the device-classification framework that decides which path to take, see Cyber Essentials BYOD Device Classification.

How the sample size formula applies to BYOD

The IASME sample-size table from the test specification applies to BYOD devices the same way it applies to corporate-owned devices, with one practical adjustment: the build distinction.

Personal devices fragment into more builds than corporate-owned devices because the firm does not control the operating system version. A 50-person workforce with personal iPhones can have iOS 16, iOS 17, and iOS 18 represented across the BYOD population, where a corporate-managed fleet might be on a single iOS version.

The sampling effect is real. A 30-device personal-phone BYOD population on three iOS versions is three builds, sampled at 3 + 3 + 3 = 9, where the same 30 devices on a single iOS version would sample at 4.

The applicant's lever: a documented BYOD policy that requires personal devices to be on a current iOS or Android version (as a Conditional Access compliance check) collapses BYOD builds into the current major version, reducing the sample.

For the broader sample-size methodology, see Cyber Essentials Plus Sample-Size Rules Explained. For the case where a sampled device fails and a second sample is triggered, see The CE Plus second-sample rule.

What evidence the assessor accepts for a BYOD device

The constraint on BYOD evidence is that the assessor cannot install agents on a personal device. The evidence formats that pass on a corporate-managed device adapt to BYOD as follows:

| Control | Corporate-managed evidence | BYOD-equivalent evidence | |---|---|---| | Software firewall | MDM configuration profile + live verification | OS-default firewall state + Conditional Access app-protection enforcing managed-app posture | | Secure configuration | Build standard + MDM verification | Conditional Access compliance policy + screen-share showing OS state | | User Access Control | Local admin group export + MFA policy | Conditional Access app-protection + corporate-tenant MFA enforcement | | Anti-malware | Management console showing agent reporting | OS-level sandboxing (iOS, Android, modern macOS Gatekeeper) + the corporate apps' built-in protections | | Patching | Patch-management tooling export | Conditional Access compliance policy requiring a current OS version + screen-share showing version |

The shape of the BYOD evidence is "what the firm controls plus the OS's built-in protections". The assessor accepts that the personal device is not a managed estate device; the evidence has to demonstrate the in-scope work surface is controlled, not that the entire device is.

For per-control evidence formats including the BYOD adaptations, see The evidence the CE Plus assessor accepts.

MFA on BYOD: the most failed BYOD control

The single most common BYOD control failure is MFA on the corporate tenant when accessed from a personal device. The pattern usually surfaces as a Conditional Access policy that exempts personal devices from MFA "for usability". The exemption defeats the control.

The fix is the same Conditional Access policy that enforces MFA across the administrative population, with no device-class exception. Personal devices satisfy the MFA challenge via the same authenticator app or hardware token used on corporate devices.

For the deeper drill on MFA failure cases including the BYOD-specific exception patterns, see The CE Plus MFA failure cases.

Pre-engagement BYOD checklist

If you are scoping a CE Plus engagement and have any BYOD population, run through this checklist before the assessor confirms the sample:

  1. Identify every user who accesses in-scope work from a personal device. The list usually starts with senior leadership, contractors, and field-based staff
  2. For each user, classify the access pattern: native app, browser only, MDM-enrolled personal device, no controls
  3. For each access pattern, decide the scoping outcome: in scope full sampling, in scope partial sampling, out of scope documented, disputed
  4. For "in scope" outcomes, document the controls (MDM enrolment policy, Conditional Access app-protection policy, contractor agreement). The assessor will need the documentation
  5. For "out of scope" outcomes, document the technical control that keeps the device out of scope (Conditional Access browser-only policy, Conditional Access blocking unmanaged devices). The assessor will verify the policy is in effect
  6. For "disputed" outcomes, schedule the discussion with the assessor before the engagement starts. Surfacing it during scoping is faster than surfacing it on the assessment day

Common questions

Does the assessor want to see the user's personal data on the device?

No. The assessor's screen-share is limited to the in-scope work surface. The user can hide personal apps, personal photos, personal messages, anything not related to the firm's in-scope data. The assessor verifies the corporate email app, the corporate Conditional Access posture, the OS-level controls. Personal content is not in the test.

What if a user refuses to share their personal device?

The user is not obligated to share a personal device for a CE Plus engagement. If the user refuses, the firm has two paths: (a) issue the user a corporate-managed device for the in-scope work and document that the personal device is no longer in scope, or (b) document the personal device as in scope and accept that the assessor cannot verify the in-scope controls without screen-share, which is likely to fail.

Is a contractor's laptop in scope if they have admin rights on our tenant?

Yes. The contractor's laptop handles in-scope data (the tenant) and the contractor has admin access. Without documented technical controls (MDM, Conditional Access app-protection, or a corporate-issued device for the in-scope work), the laptop is in scope and has to satisfy the controls.

Does using a Mobile Device Management policy mean the personal device is in scope?

A personal device with MDM is in scope, with the sampling depending on the level of management. Full MDM enrolment puts the device in the same sampling tier as a corporate-owned device of the same build. Mobile Application Management without full MDM enrolment puts the device in scope for the application-layer controls only.

How does the second-sample rule apply to BYOD?

The second-sample rule applies the same way to BYOD as to corporate-owned devices. If the first-sample internal vulnerability scan finds unpatched vulnerabilities on BYOD devices, the assessor can call for a second sample that includes BYOD devices selected randomly. For the second-sample rule, see The CE Plus second-sample rule.

What is the cleanest BYOD scoping pattern for CE Plus?

Conditional Access app-protection on personal smartphones (Shape A) plus Conditional Access browser-only restriction for unmanaged devices (Shape C) covers the smartphone and tablet population. Personal laptops doing in-scope work either get fully MDM-enrolled (Shape B) or get a corporate-managed device for the in-scope work. Contractor laptops follow the same pattern as Shape D with the MDM tier or app-protection route.

Next steps

For the deeper netsecgroup.io references:

When you are ready to scope a BYOD-heavy CE Plus engagement or want a pre-engagement BYOD review against your own population before booking, contact Net Sec Group or book a Cyber Essentials Plus assessment directly.