CIS Controls mobile companion guide: BYOD, COPE and MDM

What the CIS Controls Mobile Companion Guide asks of phones and tablets

The CIS Controls v8 Mobile Companion Guide, published on May 18, 2021, maps each CIS Control to mobile use across phones, tablets and mobile applications on Android and iOS. Its central point is that who owns the data and who owns the device determine how a device can be secured, so the ownership and management model decides which Safeguards apply and how. If a customer, contract or regulator asks how your phones and tablets are secured under the CIS Controls, your first task is to state which model each device population follows: BYOD, COPE or fully managed. Each model gets a different answer.

The organization owns its controls and the decisions about them. An implementation partner can configure the mobile management stack, document the policies and collect the configuration exports that show a Safeguard is in place. Only an independent assessor or auditor can test the controls and issue any report or attestation. Before engaging anyone, confirm internally which devices are enrolled in your EMM or MDM platform, because the Companion Guide excludes unmanaged deployments from its analysis. Devices that reach corporate data without enrollment fall outside the guide's mapping, and CIS calls unmanaged access the most dangerous option, so that gap needs its own decision and its own risk record.

Ask your team to produce a short inventory that lists each mobile population, its ownership model, its management tool and whether corporate data reaches it. That inventory becomes the scope statement for every later step. Confirm with your assessor which evidence they will accept for each population, since a BYOD workspace and a fully managed corporate phone will generate different records. Note that the Companion Guide is a mapping and does not replace any regulatory or compliance scheme that already applies to you.

Which device model fits BYOD, COPE and fully managed use

In a bring-your-own-device model, the employee owns the phone or tablet and the organization controls only a separate, managed part of it. CIS describes BYOD devices as receiving the least access to enterprise resources, which is the correct starting point because the organization cannot wipe or configure the whole device. The usual pattern is a work profile on Android or a managed configuration on iOS that holds corporate email, calendar and approved apps, with the personal side left alone.

Limited access by default: Grant only the services the business needs, such as mail and approved collaboration apps, rather than full network access.
Work profile separation: Keep enterprise apps and data in a workspace separate from personal apps, using Android Work Profiles or Apple Configuration Profiles as CIS's examples describe under Safeguard 4.12.
Selective remote wipe: Confirm that your tooling can erase only the enterprise workspace, since Safeguard 4.11 asks for erase capability on devices the enterprise owns.
Lockout and encryption at the work layer: Apply the failed-attempt lockout threshold of Safeguard 4.10 and confirm how encryption of enterprise data is enforced where the device supports it.
Privacy and consent: Document what the organization can see and do on personal devices so employees understand the boundary.

Before relying on BYOD, confirm with your EMM or MDM vendor exactly which actions apply only to the work profile and which affect the whole device.

Which mobile Safeguards set lockout, remote wipe and work profiles

Four mobile Safeguards in CIS Controls v8 set how a phone or tablet behaves when it is lost, guessed at or shared with personal apps. Each one asks for a setting the organization can enforce, and each has a distinct assessment check and evidence trail, so they are best verified one at a time.

Automatic lockout after failed attempts

Safeguard 4.10 asks that portable end-user devices lock automatically after a set number of failed local authentication attempts, where the device supports it. The CIS limit is no more than 20 attempts for laptops and no more than 10 for tablets and smartphones. The assessment specification checks that the lockout threshold is configured and enforced, not just documented. Evidence is an MDM or EMM compliance report showing the applied passcode policy for each device group, plus a sample device configuration export. Confirm the threshold your MDM actually enforces on each OS version, since some platforms set their own lockout behavior.

Remote erase of enterprise data

Safeguard 4.11 asks that the enterprise can erase its data remotely from portable end-user devices it owns when warranted, such as after loss, theft or when a user stops supporting the enterprise. The assessment checks that the capability exists and has been tested, not only that a policy describes it. Evidence includes a documented wipe procedure, the MDM command log for a test or real wipe, and records showing who authorized it. For BYOD, remote wipe should be scoped to the work profile, so confirm the mechanism before relying on it.

Separate enterprise workspaces

Safeguard 4.12 asks that mobile devices keep enterprise apps and data in a workspace separate from personal apps and data, where the device supports it. CIS points to Apple Configuration Profiles and Android Work Profiles as examples. The assessment checks that the separation is enforced for managed apps and that data cannot move freely between the two spaces. Evidence is the deployed profile or work profile policy, a list of managed apps, and a test showing a work document cannot be copied into a personal app. Confirm which data-sharing restrictions your platform enforces.

Encryption of devices with sensitive data

Safeguard 3.6 requires data on end-user devices that hold sensitive data to be encrypted. For phones and tablets, native device encryption is usually enabled by default, but the assessment expects it to be verified and enforced for every device in scope. CIS cites BitLocker, FileVault and dm-crypt as example implementations for other endpoints. Evidence is an MDM report showing encryption status per device, the policy that requires it, and exceptions with approval. Ask how the team handles devices that cannot be encrypted, and whether they are blocked from accessing sensitive data.

Control 4 mobile device controls

Control 4 covers secure configuration of enterprise assets and software, and its mobile device controls tie the other Safeguards together under a documented baseline. The assessment looks for a defined configuration standard for each mobile platform, a process to apply and review it, and proof that devices outside that baseline are detected. Evidence is the written baseline, the MDM policy set mapped to each Safeguard, and periodic compliance reports. Ask whether the baseline is versioned and who approves exceptions, because the assessment checks the process as well as the settings.

What EMM, MDM, MAV and MTD each contribute and what they cannot prove alone

No single tool category satisfies the mobile Safeguards on its own. CIS names four tool categories for implementing the Controls on phones, tablets and apps: Enterprise Mobility Management (EMM), Mobile Device Management (MDM), Mobile Application Vetting (MAV) and Mobile Threat Defense (MTD). They can be used together, and each contributes something different. EMM and MDM are where the device-level settings live: lockout thresholds for Safeguard 4.10, remote wipe for Safeguard 4.11, and work profiles or Apple configuration profiles for Safeguard 4.12. MAV addresses which applications reach the enterprise and what they are permitted to access. MTD watches the device for malicious apps, network attacks and risky configurations, and feeds detections into the response process. Map each category to the Safeguard it supports before buying anything, because a product that does not configure a setting cannot evidence it.

Tool configuration has to be confirmed with each vendor. Whether a platform enforces a lockout threshold on iOS and Android, how it handles remote wipe for personally owned devices, and whether it can separate a work profile on a given OS version are questions for the vendor's current documentation and your own test devices, not for marketing material. Ask each vendor to show the exact policy name, the OS versions it applies to and the reporting it produces.

An assessor will not accept a product's brochure as evidence. What satisfies the assessment specification is the organization's own policy settings exported from the management console, enrollment reports showing which devices are in scope and compliant, and remediation records showing what happened when a device failed a check, was wiped or was removed from access. Keep these records on a schedule so they show the control operating over time, not only at the moment of an audit. Where the data sets disagree, for example when MDM shows a device enrolled but MTD shows it as unmanaged, the discrepancy and its resolution are themselves evidence worth keeping.

How to move from an unmanaged fleet to a mapped mobile baseline

This sequence turns a mix of phones and tablets with unknown ownership and settings into a documented fleet where each device is assigned an ownership model, configured against the mobile-relevant Safeguards and evidenced on a repeatable cycle. Timing depends on fleet size and access patterns, so confirm it with your own environment and any partner's written scope.

Inventory every mobile device touching enterprise data
Build a register of every phone and tablet that reaches email, file shares, collaboration tools, line-of-business apps or enterprise networks, including devices that users enrolled themselves and devices reached only through web access. Record the platform (Android or iOS), operating system version, owner, user group and whether the device is enrolled in any management tool. Mobile Device Management consoles, identity provider sign-in logs and mail gateway records are useful starting points, but expect gaps where access happens outside managed channels. The step is done when every known access path has a device record or a documented reason it is excluded.
Classify each device by ownership model
For each device, record who owns the hardware and who owns the data, then assign it to BYOD, COPE (corporate owned, personally enabled) or fully managed. CIS's guidance treats these two questions as the basis for how much control is possible, and it calls unmanaged access the most dangerous option, so any device that cannot be assigned to a model is flagged for remediation. The output is a classified register with a named owner for each exception. Compliance and HR should review whether the classification matches employment and contractor terms.
Decide the ownership model for each user group
Match each user group to a model based on data sensitivity, role and the personal use the organization is willing to allow. Executives handling sensitive material, field staff with regulated data and contractors with limited access usually need different answers, so write the decision per group rather than per device. The output is a short policy table naming the model, permitted apps and data, and the access each group receives. Legal and works council review may be needed in some jurisdictions before personal devices are brought into scope, and that timing should be confirmed with counsel.
Configure enrollment and the mobile Safeguards for each model
Set up enrollment and policy in the management platform for each model, then map the configuration to the mobile-relevant Safeguards: automatic lockout after failed authentication attempts on portable devices (Safeguard 4.10), remote wipe of enterprise data (Safeguard 4.11), separation of enterprise and personal workspaces where the device supports it (Safeguard 4.12) and encryption of end-user devices holding sensitive data (Safeguard 3.6). Use Apple Configuration Profiles or Android Work Profiles where those are the platform mechanisms. Lockout thresholds in the assessment specification differ for laptops and mobile devices, so configure to the mobile limit. The output is a tested policy set per model with a written record of which setting satisfies which Safeguard.
Add application vetting and threat defense where the model requires it
Decide which applications may touch enterprise data and how they are checked before approval, using Mobile Application Vetting, and decide whether Mobile Threat Defense is needed for higher-risk groups. CIS names these tools alongside EMM and MDM as usable together, but the right combination depends on the data the apps reach and the platforms in use. Document the approved app list, the vetting criteria and the response when a device reports a threat. Confirm with each vendor which platforms and controls its product covers, since capability differs across tools and versions.
Collect configuration and enforcement evidence
Export evidence that the settings are applied and enforced on real devices, not only in policy: compliance reports from the management console, screenshots or exports of profiles and work profile status, lockout and wipe configuration records, encryption status and a sample of test wipes or lockout tests with dated results. Keep the exports with the device register so an assessor can trace a Safeguard to a configuration and a device population. Where a device is not compliant, record the exception and the action. The step is done when a sample of devices from each model can be traced from the policy to the enforcement record.
Review exceptions on a set cycle
Set a recurring review of the device register, policy exceptions, departures and lost or replaced devices, with a named owner and a recorded outcome for each item. Check that leavers' devices were wiped or unenrolled, that new platform versions were assessed and that the classification still matches how people work. Review cadence should follow the organization's own risk assessment and any contractual or regulatory obligations, so confirm the interval with your environment and with any partner's written scope. The output is a dated review record that feeds the next inventory, closing the loop.

Where mobile Control projects stall and how to avoid it

Most mobile projects under the CIS Controls stall for the same few reasons: unmanaged devices touching business data, unsettled ownership, settings the platform does not enforce, and evidence gathered once. Each card below names one of these delays and a practical step to avoid it before the assessment or the next audit cycle.

Unmanaged devices reaching email and chat

Staff often read corporate email and chat on personal phones before any policy covers them. The Mobile Companion Guide treats unmanaged access as the most dangerous option, so the gap is usually discovered late. Before scoping, ask your email and collaboration administrators which accounts sync to unregistered devices, then decide whether those sessions are blocked, limited to a managed app, or moved into a managed model.

No agreed ownership model per group

Projects stall when HR, legal, IT and business units each assume a different owner for the phone and the data on it. The Guide says that who owns the data and who owns the device determines how a device can be secured. Before deployment, record for each user group whether the device is BYOD, COPE or fully managed, and get sign-off from HR and legal on what the organization may wipe, inspect or require.

Lockout and wipe settings not enforced

A written policy of ten failed unlock attempts and remote wipe means little if the platform does not enforce it on every device. Some lockout and wipe options differ by operating system and by enrollment type. Test each setting on a sample of iOS and Android devices in each ownership model, record the result, and confirm the thresholds for laptops and for tablets and smartphones match the Safeguard 4.10 limits.

Work profile gaps on personal devices

On BYOD and some COPE devices, enterprise apps can end up sharing storage or clipboard access with personal apps. The Guide expects enterprise apps and data to sit in a separate workspace where the device supports it, using Apple Configuration Profiles or Android Work Profiles as examples. Before rollout, check which apps run inside the workspace, whether copy and share controls block moving data out, and what happens to the workspace when a user leaves.

Evidence collected once, not continuously

Teams often screenshot the EMM console for an assessment and then stop collecting anything. Assessors look for evidence that the configuration held over the period under review. Schedule monthly exports of enrollment counts, compliance state, encryption status and wipe actions from the EMM, MDM and threat defense tools, store them with timestamps, and keep a short log of exceptions and how each was closed.

Encryption checked only at enrollment

Devices enrolled with encryption enabled can later fall out of compliance after an OS update, a reset or a policy change. The Safeguard 3.6 requirement covers sensitive data on end-user devices, so a one-time check misses drift. Build a recurring compliance report from the management platform that flags any device with encryption off or sensitive data present, and define who acts on each flag and how quickly.

Questions buyers ask about mobile CIS Controls work

Is the CIS Controls Mobile Companion Guide mandatory?

No. The Mobile Companion Guide is guidance that helps an organization apply the CIS Controls to phones, tablets and mobile apps, and nothing in it makes adoption compulsory. CIS states that the Controls do not replace any regulatory, compliance or authorization scheme. If a customer, contract or regulator requires a specific framework, that requirement sets the obligation, and the Mobile Companion Guide is a practical way to interpret the mobile parts of the Controls. Confirm with the requesting party exactly which framework and which evidence they expect, because the answer determines how much of the mobile work is in scope.

Can BYOD devices meet the CIS Controls?

Partly, and the answer depends on how much control the organization can actually enforce. The Mobile Companion Guide describes BYOD devices as receiving the least access to enterprise resources, and it excludes unmanaged deployments from its analysis. In practice, the organization can require enrollment in a management or workspace model, enforce lockout and encryption where the platform supports it, and separate work data from personal data. It cannot wipe or configure the whole personal device without the owner's consent. Ask which Safeguards the organization expects to meet on personal devices and which it will restrict through access conditions instead.

What drives the effort of a mobile CIS Controls program?

Effort rises and falls with four factors: the number of devices and users, the mix of ownership models, the state of any existing management platform, and how many applications touch sensitive data. Each ownership model (BYOD, COPE and fully managed) needs its own policy, enrollment path and evidence set, so a mixed fleet costs more to document than a single model. An existing Mobile Device Management or Enterprise Mobility Management deployment shortens configuration work, while a gap in asset inventory adds discovery work first. Ask any provider to break the scope down by these four factors in writing.

Who issues a report or certificate for mobile CIS Controls work?

An independent assessor or certification body issues any report or certificate, not the organization's implementation partner. An implementation partner configures the management platforms, prepares policies and collects technical evidence, but it cannot attest that the Controls are met. The organization owns its controls and decides which Safeguards to claim. If a third party must verify the result, confirm in advance which assessor the customer or regulator accepts and what evidence format that assessor expects, so the implementation work is shaped to produce it.

Can our own team implement the mobile Safeguards without outside help?

Often yes, provided the team has someone who understands device management and can write the supporting policies. The mobile Safeguards for lockout, remote wipe, work profiles and encryption are configured through the management platform, and many organizations already run such a platform for other purposes. The harder work is usually the inventory of devices and applications, the documented policy and the evidence trail that an assessor will test. Outside help is most useful when the team lacks capacity, when the device estate is fragmented, or when an independent review of the design is needed before an assessment.

How does mobile work connect to the IG1 starting point?

Mobile work sits inside the essential cyber hygiene set of the Controls, so it is a natural extension of IG1 rather than a separate project. IG1 contains 56 Safeguards that CIS describes as a minimum standard for every enterprise, and several of them apply directly to phones and tablets, including the device inventory, secure configuration and data protection Safeguards. The three Safeguards discussed in the Mobile Companion Guide (lockout, remote wipe and work profiles) fit alongside the IG1 device inventory. Start by confirming which mobile devices the organization already knows about, then add the mobile-specific Safeguards to the IG1 plan.

Which tools are typically used for mobile CIS Controls work?

CIS names Enterprise Mobility Management, Mobile Device Management, Mobile Application Vetting and Mobile Threat Defense as the main tool categories, and states that they can be used together. Management platforms enforce lockout, remote wipe and work profiles, while threat defense and application vetting address malicious apps and risky behavior. Open-source options exist for parts of this stack, but the coverage for iOS and Android varies by platform and vendor, so confirm each capability against the platform's own documentation before committing to a design.

What to confirm before hiring help for mobile device controls

Before signing with an implementation partner for mobile work, the first thing to pin down is a written scope that names the device models, operating systems and ownership groups in play. The Mobile Companion Guide treats BYOD, COPE and fully managed devices differently, so a scope that says only "employee phones" leaves the partner guessing which Safeguards apply to which devices. Ask the partner to list each group (BYOD, COPE, fully managed, and any shared tablets), the Android and iOS versions it will support, and which of Safeguards 4.10, 4.11, 4.12 and 3.6 apply to each group. Also confirm who owns the data and who owns the device for each group, because the guide ties both answers to how a device can be secured.

Next, separate what the partner will configure from what it will only recommend. EMM, MDM, Mobile Application Vetting and Mobile Threat Defense can be used together, but the scope should say which of these tools the partner will deploy in your tenant, which policies it will write (for example, failed-authentication lockout thresholds or work profile separation), and which decisions stay with your team, such as whether a threat defense product is purchased at all. Ask for the configuration baseline as a document, not a verbal summary, and confirm who holds the administrator credentials for each tool after handover.

Finally, agree on the evidence package before work starts. A useful package includes device inventory exports, policy configuration exports, test records for lockout and remote wipe on sample devices, and a list of exceptions with owners. Be clear that the partner prepares this evidence but does not issue assessment reports. Any report on your CIS Controls posture must come from an independent assessor. If a partner offers to certify you or describes its own work as an audit, treat that as a red flag. Also check whether the partner claims CIS Controls Accreditation. That accreditation applies to CIS SecureSuite members that provide implementation, auditing or assessment services, so confirm the partner's membership and accreditation status directly with CIS rather than relying on a logo or sales material.

How DeployOpen scopes mobile controls and prepares evidence

DeployOpen plans, implements, hardens and documents self-hosted open-source platforms inside the client's own infrastructure, so mobile controls are scoped to the organization's own ownership models, device management stack and evidence needs. We agree the scope in writing first, then prepare the systems and records an independent assessor would review.

How we scope

Confirm which ownership models (BYOD, COPE or fully managed) apply to each user group before any work starts.
Inventory the EMM, MDM, MAV and threat defense tools already in use and record which ones the written scope covers.
Agree in writing which Safeguards for phones, tablets and apps are in scope, with deliverables and timelines fixed before work begins.

How we build

Configure device lockout, remote wipe and work profile or workspace separation in the management tools the client runs.
Set up encryption, app vetting and threat defense policies, testing each setting on representative devices before rollout.
Integrate mobile management data with the client's identity, logging and asset inventory so the records stay consistent.

How we hand over

Document each configuration as a runbook that names the policy, the platform setting and the Safeguard it supports.
Provide sample evidence such as policy exports, compliance reports and test records for the client's own review.
Deliver a handover session so the client's own staff can operate, change and reproduce each mobile control.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after the fixed-scope work closes.
Re-check mobile configurations when the operating system, management platform or ownership model changes.
Prepare evidence for the client's own assessment. The client owns its controls, and only an independent assessor issues a report.

CIS Controls Mobile Companion Guide: phones, tablets and BYOD