Mobile device management: configuration and proof

Device management supports security only for the devices and settings it actually covers. An MDM dashboard showing compliant devices needs a second question: which devices are missing? A third question follows: does “compliant” describe an effective configuration, or merely a policy assigned to an endpoint?

For a CTO, the task is to make those answers reproducible. Mobile device management should connect device ownership, configuration, application access, incident response and evidence. The objective is not a green dashboard. It is a defensible account of which endpoints can access business information, how they are protected, and what happens when protection fails.

What MDM controls—and what it does not

Mobile device management is the administration of endpoints through a central service and platform-supported management mechanisms. Depending on the product, operating system and enrollment mode, it can deploy configuration profiles, distribute applications, report device state, restrict selected functions and issue remote commands. Broader endpoint-management products may include laptops and desktops alongside phones and tablets.

These capabilities are not uniform. A fully managed corporate phone and a personally owned phone with a managed work profile expose different controls and telemetry. Some platforms use built-in management services; others require additional agents. Neither continuous connectivity nor immediate execution should be assumed.

MDM also does not replace identity management, endpoint detection, vulnerability management or information classification. It can configure or supply signals to those controls, but their operation needs separate verification. A managed device can still have excessive application permissions, an unrevoked session or a vulnerable application.

Before selecting settings, define the control claim. For example: “Company laptops accessing the production administration environment must be enrolled, encrypted, supported and recently assessed.” That statement identifies a population, a resource and observable conditions. “All devices are secure” does not.

Connect endpoint management to the ISMS

ISO/IEC 27001 concerns a scoped information security management system, not the purchase of a particular endpoint tool. Its clauses 4–10 establish management-system requirements. Annex A provides a reference set of 93 controls whose applicability is considered through risk assessment and treatment; it is not a universal MDM configuration checklist.

The Statement of Applicability records necessary controls, inclusion rationale, implementation status and justification for excluding Annex A controls. An MDM deployment provides part of the implementation and evidence for relevant controls, rather than proving the whole ISMS.

Useful connections include:

These mappings describe contributions, not equivalence. For example, deploying a login configuration does not establish that privileged access is appropriately approved. Use our Annex A guide to connect endpoint measures to the broader ISMS rather than treating device compliance as an isolated score.

Define the population before measuring compliance

Start with devices that store, process or access information within the ISMS scope. Include company-owned and personally owned equipment, contractor endpoints, shared devices and temporary loan devices where relevant. Agree supported operating systems, enrollment rules and privacy boundaries.

Build the inventory around stable identifiers rather than display names alone. Useful fields include asset identifier, management identifier, assigned user, ownership, platform, enrollment mode, business purpose, enrollment date, last contact and retirement status. Record shared-device custodians explicitly.

Reconcile the MDM inventory against independent sources. Asset purchasing records reveal equipment that was never enrolled. Identity sign-in records and application access logs can reveal endpoints absent from management. Endpoint-protection records can expose duplicate agents or devices managed elsewhere. Check which identifiers each source actually provides before attempting a join.

Classify discrepancies instead of silently excluding them:

• In-scope and enrolled: assess configuration and freshness.
• In-scope but unmanaged: enroll, restrict access or approve a bounded exception.
• Retired but still active: investigate and revoke residual access.
• Duplicate or rebuilt: reconcile records without losing historical evidence.
• Out of scope: document the reason and the boundary preventing relevant access.

The denominator matters. “98% compliant” among enrolled devices can conceal a substantial unmanaged population. Report coverage separately from configuration compliance, and retain the reconciliation date and unresolved records.

Build a baseline that can be tested

An endpoint baseline should translate risk decisions into settings and verification criteria. It should distinguish platforms and ownership models instead of pretending that every setting works everywhere.

The following is a practical starting point, not a universal statutory or ISO-mandated checklist:

Define what “unknown” means. An endpoint that has not reported encryption status is not proven encrypted. Treat missing or stale telemetry as a separate state with a clear response, rather than converting it to a pass.

Update windows should reflect vulnerability severity, exposure, available mitigations and operational constraints. Document emergency handling for actively exploited vulnerabilities and a process for updates that break essential applications. MDM deployment reports help establish installation state; they do not, by themselves, explain whether unresolved vulnerability risk is acceptable.

For applications, distinguish distribution from control. Installing an approved application does not prevent users from installing alternatives unless the platform and configuration support that restriction. Define who may approve software, what requires assessment, and how obsolete or prohibited applications are removed.

Every baseline exception needs an owner, affected devices, business reason, risk assessment, compensating measures, approval and expiry. An unsupported operating system with unrestricted sensitive-data access should not remain indefinitely under a generic “business requirement” note.

Roll out configuration without confusing assignment with success

Use a pilot group representing each important platform, ownership mode and business use case. Test normal work, travel, offline behavior and recovery—not just successful enrollment on an administrator’s desk.

Before broad deployment, establish the management prerequisites: administrator roles, enrollment permissions, required certificates or service credentials, and renewal ownership. A management service can lose effectiveness when a certificate expires even though its policy documents remain unchanged.

Track configuration through distinct states: targeted, delivered, applied, assessed and effective. Where the platform exposes fewer stages, document that limitation and add a safe verification method. Inspect conflicting profiles, stale agents, unsupported settings and user actions that prevent completion.

Use staged deployment with an approved rollback or recovery path. Record the baseline version, targeted groups, pilot results, approval and rollout failures. A screenshot of a policy editor proves intended settings; device reports and tests establish whether those settings operated.

Protect the management plane itself. Use named administrator accounts, appropriate strong authentication, least-privilege roles and logging. Limit bulk wipe and configuration-changing privileges. Review administrators and service credentials because compromise of the management service can affect many endpoints at once.

Verify encryption and recovery separately

For laptops, check the implemented storage protection, not merely an “enable encryption” policy. For phones and tablets, understand the operating system’s encryption model, lock-state behavior and management visibility. Encryption at rest and encrypted network transport are separate claims.

Decide which local storage is covered, whether removable media is permitted and how business information can leave managed applications. A protected system disk does not automatically protect an exported file on an unencrypted external drive.

Recovery arrangements need their own control design. Determine where recovery material is held, who can retrieve it, how retrieval is authorized and logged, and when rotation or replacement is required. Do not put recovery secrets into general audit evidence or help-desk tickets.

Test recovery on a designated test endpoint using an approved procedure. Preserve the authorization and outcome, not the secret. A console field showing that a key exists does not prove that authorized staff can recover the device when needed.

Network protection also depends on application and service configuration. MDM may distribute certificates or network settings, but it cannot establish that every application uses appropriately configured encrypted connections. For the wider lifecycle, see encryption and key management.

Connect device status to access decisions

A compliance signal has limited value if noncompliant endpoints retain unrestricted access. Where supported, connect device trust or compliance information to identity and application access controls. Establish precisely which resources enforce the condition and which access paths bypass it.

Test browser access, native applications, remote administration, legacy authentication and existing sessions where applicable. An unmanaged browser may be blocked while a previously authorized client continues working. Session revocation behavior and signal freshness require explicit testing.

Use risk-based restrictions. Sensitive administrative systems may require stronger endpoint conditions than low-risk collaboration resources. Define emergency access and recovery procedures so a failed compliance service does not produce undocumented permanent bypasses.

Device unlock authentication is not the same as application authentication. Screen locking protects an unattended endpoint; multi-factor authentication and authorization protect resource access. MDM can support configuration, but identity-provider and application evidence must substantiate those separate claims.

Handle personal devices, loss and departure deliberately

For personally owned devices, decide whether management is full-device, work-profile, application-only or unavailable. Explain what administrators can see, what they can change, what business information is collected and what can be removed. Do not assume location tracking or personal application visibility is necessary or available.

Where employee device telemetry involves personal data, assess applicable privacy obligations. The GDPR requires a lawful basis and relevant processing principles; Article 32 takes a risk-based approach to security rather than imposing blanket encryption for every circumstance. Employee consent should not be assumed sufficient. Obtain appropriate privacy and employment-law review for monitoring and removal procedures.

Separate selective removal of business data from full-device wipe. Confirm the supported behavior for each enrollment mode and communicate it before enrollment. A work-profile removal may leave personal data untouched, while a full wipe has materially different consequences.

For a lost device, the response should identify the endpoint and user, assess exposure, restrict access, revoke relevant sessions or credentials, issue supported lock or wipe commands, and record results. Remote wipe depends on connectivity and platform capabilities. “Command queued” is not “data removed.”

Departure procedures should address both device return and information access. Revoke access independently of whether a device is recovered. Remove business profiles when appropriate, preserve information subject to retention requirements, and retire inventory records only after the required checks. Test these processes within a safe scope using test accounts and devices.

Preserve evidence that supports a bounded claim

An evidence package should let a reviewer reconstruct what was protected during a stated period. Preserve dated exports, population counts, exception decisions and remediation records. Include enough context to distinguish a point-in-time assessment from evidence of ongoing operation.

Useful deliverables include:

• Scope and inventory reconciliation, including unresolved unmanaged devices.
• Approved baseline versions and platform-specific settings.
• Device-state exports showing identifiers, enrollment, last contact and effective configuration.
• Exception approvals with expiry dates and compensating measures.
• Deployment failures, remediation tickets and closure verification.
• Recovery, access-denial, lost-device and departure test records.
• Periodic review decisions and assigned follow-up actions.

Document export filters, collection time and interpretation of status fields. Protect exports appropriately because they may contain personal identifiers or sensitive infrastructure details. Screenshots can explain configuration, but searchable exports are usually more useful for population analysis.

Sample across risk and failure modes, not only healthy devices. Include different platforms, recent enrollments, privileged users, stale endpoints and approved exceptions. A current report cannot reconstruct a previous review period unless historical records were retained.

Periodic coverage reviews should include newly onboarded devices and changing access patterns. Useful operational measures include enrollment coverage, assessed-baseline compliance, stale reporting, expired exceptions and remediation age. Define each denominator and threshold. Continuous controls monitoring provides further context for distinguishing signals from reviewed conclusions.

Worked example: a mixed fleet review

The following figures and thresholds are illustrative assumptions, not industry benchmarks.

A company identifies 120 corporate laptops and 30 personal phones authorized for work email. Its laptop baseline requires enrollment, encryption, a supported operating system, screen locking and a successful assessment within seven days. Personal phones require a managed work profile and supported software; full-device management is outside the approved privacy boundary.

The MDM console contains 116 laptops. Of those, 108 meet the baseline, four report overdue updates, two have stale assessments and two show encryption failures. The remaining four laptops are absent from management.

Reporting only the console result gives 108 out of 116, approximately 93% baseline compliance. Against the established laptop population, 108 out of 120—90%—are demonstrated to meet the baseline. Enrollment coverage is approximately 97%. These are different measures, and none proves the personal-phone controls.

Identity records show that two unmanaged laptops accessed a sensitive application. The team restricts that access, investigates ownership and enrolls the devices. The other two are confirmed retired; evidence of revocation and disposal supports their removal from the active population.

For the phones, three users have email access without the required work profile. Their access is restricted until enrollment or an approved alternative is completed. A test phone confirms that selective removal deletes the work profile without wiping personal content.

The review record retains the original population, reconciliation changes, failures, access restrictions and verified remediation. It does not replace the initial failed assessment with a later clean screenshot.

Make the next review easier

The common mistakes are operational: counting only enrolled endpoints, trusting policy assignment, accepting stale telemetry, leaving exceptions open and treating remote commands as completed actions. Each can be addressed through a defined population, explicit state handling and dated verification.

Secani can organize this work around the relevant systems, requirements, owners and evidence. Upload baseline documents, dated MDM exports and test records; connect them to the controls or decisions they support; and turn missing evidence or unresolved failures into assigned tasks. Preserve human review, approval and source context for material conclusions. MDM remains the operational endpoint-management tool; the compliance workspace preserves implementation context and review decisions.

A practical next step is to select one sensitive application and reconcile every endpoint accessing it against management records. Test one healthy endpoint, one unmanaged endpoint and one stale endpoint. Record the access outcomes and configuration evidence, then assign every unexplained discrepancy to an owner. That small exercise tests coverage, enforcement and proof together.