16.1 Administer and Manage Mobile Devices
Key Takeaways
- SSCP knowledge area 7.3 (outline effective 1 October 2025) provisioning: COPE is company-owned with personal use allowed, so a full-device wipe is usually acceptable; BYOD is employee-owned and needs a work container plus selective wipe.
- Mobile device management enrolls the device or work profile and enforces posture, certificates, lock, and wipe. It is a control plane, not an ownership model, and it is not mobile application management.
- Containerization separates corporate mail and apps from personal photos so a lost-device action can destroy work data without factory-resetting a family phone.
- Device and container encryption protect cached mail when the phone is offline or in airplane mode; a queued remote wipe is not a substitute because the command never arrives.
- Mobile application management governs which apps may hold corporate data. An unmanaged personal mail client is not containerization.
Why mobile administration is a Domain 7 operations skill
Domain 7 of the ISC2 Systems Security Certified Practitioner (SSCP) exam — Systems and Application Security — is weighted at 15% under the outline effective 1 October 2025. Knowledge area 7.3 is Administer and manage mobile devices. The outline's bullets are provisioning techniques (corporate owned, personally enabled (COPE), Bring Your Own Device (BYOD), Mobile Device Management (MDM)), containerization, encryption, and mobile application management (MAM).
Knowledge area 7.2 already covered host tooling on laptops and workstations: host-based detection, allowlisting, full-disk encryption, Trusted Platform Module (TPM), and endpoint detection and response (EDR). Phones and tablets are still endpoints, but they fail differently. Users mix personal photos with member records, they leave the building every evening, and a wipe that erases someone's family album is how you lose the workforce and still fail an audit. Computerized Adaptive Testing (CAT) items will punish treating a personally owned phone as if it were a locked-down finance laptop.
Provisioning: COPE, BYOD, and MDM
Provisioning is how a device becomes a managed object: identity, policy, certificates, email, and the right to revoke access. The outline names two ownership models and the control plane that binds them.
| Model | Who owns the hardware | Personal use | Typical wipe | SSCP operations tell |
|---|---|---|---|---|
| COPE | Organization buys, issues, and retires the device; personal use is allowed | Work profile plus limited personal apps per policy | Full-device wipe is usually acceptable because the asset is corporate | Field tablet with a work profile; user may install a weather app; a lost device is remotely wiped |
| BYOD | Employee owns the device | Personal photos, messages, and apps are expected | Selective / container wipe of the work profile — not a factory reset of the family phone | Adjuster uses a personal iPhone for corporate mail inside a managed container |
| MDM | Not an ownership model — the management plane | Enforces policy on enrolled devices regardless of who paid for the hardware | Can trigger full or selective wipe, lock, locate where lawful, and retire | Enrollment profile, compliance posture, certificates, and the action you actually press at 02:00 |
Corporate owned, business only (COBO) and choose your own device (CYOD) appear in vendor literature. The SSCP outline's examples are COPE, BYOD, and MDM. If the stem says the company owns the phone and the user may keep a personal messaging app, that is COPE. If the stem says the employee bought the phone and will not accept a factory reset, that is BYOD plus a container — not refuse mobile email.
MDM enrolls the device or the work profile, pushes configuration (Wi-Fi, virtual private network (VPN), email, certificates), evaluates compliance (passcode, encryption, operating-system version, jailbreak or root), and executes actions: lock, selective wipe, full wipe, retire. MDM is not antivirus and it is not MAM. An unenrolled phone with a password is not a provisioned corporate endpoint.
Scenario (BYOD with corporate email in a container). You are the security administrator for a regional health clinic. A claims adjuster wants corporate email and the electronic health record (EHR) app on a personally owned phone so after-hours pages do not require a second device. Legal will not accept a full-device remote wipe of someone's personal photos. The correct 7.3 design is:
- Enroll the device in MDM with a work profile or managed Apple User Enrollment (or the equivalent on that platform), not unsupervised full-device control that pretends the phone is COPE.
- Deliver corporate email and the EHR app inside the container. Copy/paste, screenshots, and backup of that container follow policy (data loss prevention (DLP) on the work side).
- Personal photos, SMS, and the user's own mail stay outside the container. A lost-device action is selective wipe of the work profile plus certificate and token revocation — not a factory reset.
- If the user refuses enrollment, they do not get corporate email on that phone. Unmanaged Internet Message Access Protocol (IMAP) to a personal client is shadow mobile access, not BYOD.
Exam trap: answering that BYOD means the organization cannot manage the device, so encryption of the mailbox on the server is enough. Server encryption does not protect the cached mailbox, the screenshot, or the unmanaged forward.
Containerization
Containerization on mobile is a logical work vault on a device that also has a personal personality. It is not a Type 1 hypervisor and it is not a Docker host. Android work profiles, Samsung Knox-style dual persona, and iOS managed-app / User Enrollment boundaries are the usual implementations.
| Control | What it separates | What a selective wipe removes | What it does not do |
|---|---|---|---|
| Work container / profile | Corporate apps, mail, contacts, and files from personal apps | Corporate identity, certificates, managed apps, and cached work data | Does not encrypt the personal side; does not stop a rooted device from attacking the kernel |
| App-level container (MAM wrapping) | A single managed app's data | That app's sandbox and tokens | Does not enroll the whole device; a second unmanaged mail client can still leak |
| Full-device supervision | Almost nothing is personal from a policy view | Everything | Inappropriate for true BYOD unless the user agreed in writing that the phone is treated as corporate |
Copy/paste, Open-In, AirDrop, and personal cloud backup are the leak paths. Container policy should block work data from opening in an unmanaged app and block unmanaged backup of the work vault. Jailbreak and root detection belong here: a compromised kernel makes the container a policy fiction.
If the CAT stem says wipe corporate email without deleting the employee's photos, the answer is containerization (selective wipe), not full-device MDM wipe, and not we cannot use BYOD.
Encryption on mobile devices
Mobile encryption protects data at rest when the device is powered off, locked, or the storage is removed. Modern iOS encrypts by default; current Android uses file-based encryption with a lock-screen credential that unwraps keys. That is necessary and not sufficient.
- Device encryption protects the volume (or per-file keys) when the thief has the hardware and not the unlock secret. A stolen, unlocked phone is plaintext — the same rule as BitLocker on a logged-on laptop in knowledge area 7.2.
- Container encryption (or managed-app encryption) protects work data even when personal data uses a weaker posture, and it is what selective wipe destroys.
- Remote wipe is not a substitute for encryption. If the device is powered off, in airplane mode, or has the management profile removed, the wipe command never arrives. Encryption is what still holds on a pulled flash part.
- A personal identification number (PIN), passcode, or biometric is the unlocker of encryption keys. It is not encryption by itself. Requiring a PIN without device encryption is a lock screen, not 7.3 encryption.
Lost-device procedure that matches the outline: lock, selective or full wipe as ownership allows, revoke tokens and certificates, and rely on encryption for the hours the device is offline. Do not tell the exam that MDM locate-and-wipe makes encryption optional.
Mobile application management
Mobile application management (MAM) governs which applications may handle corporate data and how those apps behave: managed configuration, app wrapping, required versions, blocked sideloading, and the right to wipe the app without wiping the phone. MDM is device or profile enrollment and posture. You usually run both: MDM to enroll and measure compliance, MAM to keep member records out of a personal file-sync client.
| Tool | Primary object | Typical actions | Failure mode |
|---|---|---|---|
| MDM | Device or work profile | Enroll, configure, compliance, lock, selective or full wipe, retire | Enrolling then allowing unmanaged mail still leaks |
| MAM | Application and its data | Allow-list corporate apps, wrap or use managed-app configs, wipe the app, block Open-In | MAM-only on an unmanaged, jailbroken phone is a policy file the kernel can ignore |
| Containerization | Work persona on a mixed-use device | Boundary, copy/paste controls, selective wipe | Treating the container as a hypervisor |
Sideloading, unknown-source packages, and jailbreak or root are 7.3 application-management problems as much as 7.1 mobile-code problems. The catalog should be an enterprise store or managed public-store apps, not employees may install any PDF scanner.
Exam traps. Calling BYOD a reason to skip MDM. Full-wiping a personally owned phone as if it were COPE. Treating MAM as a hypervisor. Claiming encryption is unnecessary because remote wipe exists. Allowing corporate email in an unmanaged personal client and calling it containerization.
When a CAT item names 7.3, answer with the ownership model plus the control: COPE can full-wipe; BYOD needs a container and selective wipe; MDM enrolls and enforces; encryption protects the offline hours; MAM keeps work data inside approved apps.
A clinic claims adjuster wants corporate email and the electronic health record app on a personally owned phone. Legal will not accept a factory reset of personal photos. What is the correct SSCP knowledge area 7.3 design?
Which statement correctly distinguishes mobile device management from mobile application management in SSCP knowledge area 7.3?
A bring-your-own-device phone with a managed work container is stolen and immediately placed in airplane mode, so the mobile device management wipe command cannot reach it. What still protects the cached corporate mailbox?