04 Mobile Device Security: HITRUST domain and evidence

What HITRUST 04 Mobile Device Security asks for, and why it is hard

A phone or tablet that can reach in-scope data is part of your assessed environment, so HITRUST expects you to show that those devices are encrypted, centrally managed and gated before they get access. Domain 04 Mobile Device Security is one of the 19 assessment domains HITRUST uses to group requirement statements and score results in e1, i1 and r2 reports. In practice, your assessor will ask which mobile devices can open email, chat, admin consoles or applications that touch in-scope data, how each device is enrolled and configured, and what happens when a device is lost, stolen or no longer needed. Your answers need to be backed by evidence from the device management system and the access platform, not only by a written policy.

The domain is hard to evidence for three reasons. Devices leave the office and sit on networks you do not control, so you need to prove state at the moment of access rather than at an annual snapshot. Personal devices blur ownership, because a bring-your-own-device arrangement still has to show encryption, screen lock, remote wipe and conditional access without giving you control of the employee's whole phone. And the work spans HR (joiners and leavers), IT (enrollment and configuration) and security (policy, access rules and monitoring), so one team rarely owns every piece. HITRUST's 2025 Trust Report lists Mobile Device Security as 4.9% of the domains that caused submitted assessments to fail certification in 2024, which is a useful reminder that a gap here can block an otherwise complete assessment.

Start by asking three questions and confirming the answers with your own records: which mobile platforms and device types are in scope, which applications require a compliant device before access, and who approves exceptions for personal devices. Then check whether your device management and identity tools can produce a dated report of enrollment, encryption and compliance status for each device in scope, since that report is the evidence your assessor will sample. Where the cloud provider or SaaS vendor enforces part of the control, confirm the split in writing with that provider before you plan your evidence, because HITRUST treats mobile security as only slightly inheritable.

Which devices, teams and providers fall inside mobile device scope

Mobile device scope starts with a few decisions: which devices reach in-scope data, which applications they open, and who controls each safeguard. Those choices decide how much of the 04 Mobile Device Security work sits with your team and how much a provider can carry. Settle them in writing before the assessment scope is locked.

Corporate versus personal devices

Company-owned phones and tablets can be enrolled, configured and wiped centrally, so you can show the controls working on every device. Personal devices used under a bring-your-own-device policy are harder to evidence because you control only the work container, not the whole handset. Decide whether personal devices are in scope at all, and if they are, document which controls apply to them. Ask whether unmanaged devices can reach in-scope data through a browser session.

Phones, tablets and mobile-app laptops

Scope covers any device that reaches in-scope systems, not only phones. Tablets used by clinicians or field staff, and laptops that run mobile-style apps or sync mail and chat, can all open the same paths. Build a device inventory from identity provider records and mobile management data rather than from procurement lists. Then compare that inventory against the systems the assessment covers to find gaps before the assessor does.

In-scope applications reached from mobile

The applications a mobile device opens determine which controls matter. An email client that caches attachments on the device raises different questions from a read-only dashboard that holds nothing locally. List each mobile-accessible application, what data it caches, whether it supports app-level encryption or containers, and whether it can be restricted to managed devices. Those answers drive the evidence you will need.

Device as the control point or the cloud service

Some controls live on the device, such as encryption, screen lock and device compliance. Others live in the cloud service, such as session limits, sign-in risk checks and conditional access rules that block non-compliant devices. Decide for each in-scope application which layer is the control point, and record it. Where the device is the enforcement point, the device management records become your evidence; where the service is, the identity and access logs do.

Split responsibility with a cloud provider

HITRUST's inheritance example for Oracle Cloud Infrastructure shows the split. The customer keeps encryption, device management and conditional access on mobile devices, while the provider supplies multi-factor authentication and federated sign-in. Because the customer carries most of the mobile work, this domain is only slightly inheritable. Confirm in the provider's shared responsibility matrix exactly which mobile controls it covers before you claim any inherited result.

Who owns each mobile safeguard

Mobile scope usually crosses several teams: endpoint administrators run device management, identity engineers run conditional access, and application owners set data handling rules. Name one owner for each safeguard and record where the evidence is kept. An implementation partner can configure and document these controls, but the organization owns the policies and the operating evidence. Gaps tend to appear where two teams each assume the other holds the control.

How an assessor tests mobile device security in a validated assessment

This table sets out how an assessor typically tests the 04 Mobile Device Security domain, the evidence it asks for and the findings that most often appear. Read each row as a question the assessor will ask of your mobile estate, then check that your records answer it before fieldwork starts.

Test area	What the assessor does	Evidence requested	Common findings
Mobile device management policy	Inspects the MDM policy configuration for enrollment, passcode, encryption and OS update settings, and compares it with the organization's written requirements	Policy exports, configuration profiles and change history showing who approved each setting	Written mobile rules that do not match what the MDM console enforces
Device enrollment coverage	Samples enrolled devices and compares the MDM inventory with devices that have accessed in-scope applications or email	Enrollment reports, device inventories and access logs from identity or mail systems	Unenrolled phones or tablets reaching in-scope apps
Encryption on devices	Checks on a sample of enrolled devices that device encryption is active and that the MDM reports it as compliant	Device compliance reports with encryption status and timestamps for the sampled devices	Devices reported as compliant without verified encryption, or unencrypted devices outside MDM control
Conditional access	Tests a sample login from a managed and an unmanaged device to confirm that access to in-scope systems is blocked or limited as the policy states	Conditional access policy exports, sign-in logs and test results from the sampled logins	Policies that exist on paper but do not apply to all mobile sign-in paths
Remote wipe and lost device handling	Asks for the documented process for wiping or locking a lost or departing user's device, then looks for records of past cases	Written wipe procedure, ticket records of wipe requests and MDM action logs with dates	No documented wipe process, or no evidence that wipes were carried out and recorded
Exception approvals	Reviews each documented exception, such as an unmanaged device or a relaxed setting, for owner, rationale, expiry and approval	Signed exception records, risk acceptances and review dates	Exceptions that never expire or lack a named approver
Operating system and app currency	Checks whether enrolled devices meet the minimum OS version and whether managed apps are restricted to approved sources	Compliance reports on OS versions, app allow lists and blocked-app records	Devices running unsupported OS versions still allowed to connect
Monitoring and follow-up	Confirms that non-compliant devices are reviewed and that someone acts on the report	Review records, escalation tickets and evidence of follow-up on failing devices	Compliance dashboards that nobody reviews or that show failures with no action taken

How to implement mobile device controls before the assessment

This sequence turns mobile device access into evidence an assessor can test, moving from knowing which phones and tablets reach in-scope data to documented rules, enforced configuration and recorded exceptions.

Inventory devices and apps that reach scope
Identify every phone, tablet and other mobile device that can open email, file stores, admin consoles or applications holding in-scope data, along with the apps and accounts used on each. Assign an owner to each device and record its platform, operating system version and enrollment status. The output is a device inventory that matches the systems in your scope statement. You know the step is complete when a sample of in-scope applications can be traced back to a listed device or an approved access path.
Decide corporate and personal device rules
Set out which devices are organization-owned and which personal devices, if any, may access in-scope data. Define what the organization controls on each type, such as wiping work data, enforcing screen locks and restricting app installs. Management owns this decision, and legal and HR should review the personal device terms. The output is a written mobile policy approved by an accountable executive, with the ownership model stated for each device class. Your assessor will look for this policy and for evidence that staff were told about it.
Enroll devices in mobile device management
Bring every in-scope device under a mobile device management (MDM) product, either through full enrollment or a managed work profile for personal devices. Confirm the MDM can report device state, push configuration and remove organizational data. Your team or the MDM administrator owns the enrollment process, and unenrolled devices should be blocked from in-scope resources. The output is an enrollment report showing each device, its enrollment type and the date it was enrolled. Compare this report with the inventory from the first step to find gaps.
Enforce encryption and screen lock
Configure the MDM to require device encryption, a screen lock with a defined passcode standard, an idle timeout and protection against disabling these settings. For personal devices in a work profile, confirm the encryption and lock settings that apply to the managed container and the rest of the device. The output is an exported MDM configuration showing these settings as enforced policies, not recommendations. Test a sample of devices to confirm that noncompliant devices are flagged, and keep the export and test results for the assessor.
Set conditional access on device compliance
Create access rules in your identity provider that grant access to in-scope applications only when the device is enrolled, compliant with the MDM policy and running a supported operating system. Include a block or step-up response for noncompliant devices. The identity team owns the rules, and the MDM supplies the compliance signal. The output is an exported conditional access rule set with each rule's conditions and outcomes. Test one blocked and one allowed sign-in and keep the logs, since they show the rule working as written.
Define remote wipe and lost-device procedures
Write the steps for reporting a lost or stolen device, revoking its sessions and tokens, and issuing a remote wipe through the MDM. Include who may trigger a wipe, how personal devices are limited to organizational data, and how the user is notified. Staff should be trained on the reporting path. The output is a tested procedure, supported by a record of at least one exercise or real event showing the MDM action and the session revocation. Keep the timestamps, since assessors compare them against the stated procedure.
Document and approve exceptions
List every device, app or user that falls outside the standard controls, such as legacy operating systems or devices that cannot be enrolled. For each exception, record the business reason, the compensating control, the owner, the approver and a review date. Risk management or the security leadership should approve the register, and exceptions should be reviewed on a set schedule. The output is an exception register that ties each open gap to a documented decision. An assessor will test whether exceptions are approved and reviewed, so an empty register needs its own supporting evidence.

Which evidence shows mobile device controls are working

An assessor testing the mobile device domain looks for proof that controls operated over the review period, not just that they were configured once. The artifacts below connect policy, device state, sign-in activity and exceptions, and each one should be exported or reviewed on a schedule so the evidence stays current between assessments.

Approved mobile device policy

The written policy states which devices may reach in-scope systems, which operating system versions are acceptable, how devices enroll, and what happens to unmanaged devices. Keep the document version history, the approval record from the accountable owner, and the date of the last review. Check that the policy matches what the device management tool actually enforces, because assessors compare the two. Schedule an annual review and log any change that happens between cycles.

MDM enrollment and compliance reports

Mobile device management reports show which devices are enrolled, which pass the compliance checks and which fail. The failing list matters as much as the passing list, because it shows the organization detects drift and acts on it. Export the enrollment and compliance status on a fixed schedule, such as weekly, and keep the dated exports together. Confirm that the tool can report the history, not only the current state, since a single screenshot cannot show control operation across a period.

Encryption and passcode configuration exports

Exports of device configuration prove that storage encryption and passcode requirements are enforced on each managed device, such as minimum length and lock timeout. Pull these settings from the management platform rather than from a configuration document, and compare the export against the policy baseline. Store each export with its date so the record shows settings held throughout the period. Any device that does not meet the baseline should appear in the exception register or the remediation ticket trail.

Conditional access rules and sign-in logs

Conditional access rules decide whether a device that is not compliant can reach email, file shares or applications in scope. Keep the rule definitions with their change history, and retain sign-in logs that show blocked and allowed attempts tied to device state. Confirm the identity provider records device compliance in each sign-in event. Review a sample of blocked sign-ins each cycle to show that the rule is enforced in practice and that someone investigates the denials.

Remote wipe and lost-device tickets

Records of lost, stolen or retired devices show that the organization can revoke access and wipe data when needed. Each ticket should capture the report time, the wipe or account revocation time, who approved it and the confirmation from the management platform. Track the elapsed time between report and action so the reviewer can see whether the process runs as written. Keep these tickets with the incident records where a device loss affects data in scope.

Exception register with review dates

An exception register lists each device or user that falls outside the standard, such as an older operating system used for a vendor application, along with the business reason, compensating measures and an expiry date. Assessors look for named approvers and proof that exceptions are reviewed on time. Set a review date for every entry and keep the prior versions so the record shows exceptions closing or being renewed. An empty register is rarely credible, so confirm the process captures real cases.

What meeting mobile device security costs in money and effort

This table lists the cost components behind mobile device security for a HITRUST scope, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a quote request so that licenses, engineering, evidence upkeep and assessor work can be compared line by line. No prices are stated, because the figures depend on your device count, identity stack and written scope.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up and how to keep it down
MDM or device management licenses	Software vendor, or no license cost for self-hosted open source	Recurring when commercial, usually per device or per user	Device count and BYOD share raise it. Self-hosted open-source MDM options can reduce license spend, but confirm device platform coverage and support terms.
Conditional access and identity licensing	Identity provider the customer already owns	Recurring, often bundled with existing licenses	Number of identity integrations and whether mobile sign-in needs premium tiers. Ask which features are already licensed before buying more.
Engineering time to configure policies and integrations	Internal platform team or an implementation partner under a written scope	One-time build, plus periodic changes	Number of apps reached from mobile and number of identity integrations. Fixed-scope work with agreed deliverables keeps this predictable.
Endpoint compliance queries and monitoring setup	Internal security engineering or implementation partner	One-time build, then recurring monitoring	Number of device platforms and policy count. Open-source query-based policy tools can show pass or fail status per device.
Policy writing and user training	Internal policy owner, HR and training staff	One-time for drafting, recurring for annual refresh and new joiners	BYOD share and the number of user groups with mobile access. Reusing one mobile policy across scopes lowers effort.
Evidence upkeep	Internal control owners, sometimes supported by a partner	Recurring across the certification period	Frequency of device exports, screenshots and change records. Automating exports from management tools reduces manual collection.
External readiness review	Independent consultant or readiness reviewer	One-time per readiness cycle	Scope size, maturity of existing controls and number of mobile gaps found. Ask for the review scope and deliverables in writing.
Auditor sampling and assessment fieldwork	Authorized external assessor, paid by the organization	One-time per validated assessment	Number of devices and mobile-reachable systems sampled. Keep device inventories current so sampling does not expand.

Which open-source tools support mobile and endpoint evidence

Mobile Device Security is largely a customer-side obligation, so the evidence has to come from the devices and services the organization runs itself. The four tools below each produce a different kind of evidence, from device posture to encryption of stored files and application data. Before relying on any of them for mobile devices, confirm platform coverage with the vendor.

Fleet device policy queries

Fleet (MIT) lets you write yes or no policies as osquery queries and asks each enrolled device to answer them, such as whether disk encryption is on or a screen lock is set. The policies page shows which devices in each fleet pass or fail each policy, which gives you a dated record of device posture for the 04 Mobile Device Security domain. The license is permissive, but licensing does not settle coverage: confirm with the Fleet vendor which mobile operating systems and device types its agents and queries support, and whether a phone you need to assess can be enrolled at all.

Wazuh configuration assessment

Wazuh's Security Configuration Assessment checks monitored endpoints against YAML policies, most of them based on CIS benchmarks, and reports the result with remediation advice. It checks files, directories, registry keys and running processes, so it fits managed laptops and workstations that connect to the scope. Wazuh is licensed under GPL-2.0-only, so distributing modified agents or code carries copyleft obligations that legal counsel should review. Confirm with Wazuh which mobile platforms its agent supports before counting phones in the assessment.

Nextcloud server-side encryption

When staff reach files through Nextcloud clients, server-side encryption protects file contents at rest on local and external storage, with keys held on the server. It does not encrypt file names or folder structure, so the evidence should say that plainly rather than claim full protection. Nextcloud is licensed under AGPL-3.0-only, which applies to modifications offered over a network, so confirm the obligations with counsel if you alter the server. Ask the Nextcloud vendor or your own testing how the feature behaves with the mobile client on each device type in scope.

OpenBao transit encryption

The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, signs and verifies content, and supports versioned keys with rotation. Used with mobile-facing back-end services, it can produce evidence of centrally managed key rotation and separation between applications and key material. OpenBao is licensed under MPL-2.0, a file-level copyleft license, so modified OpenBao source files must remain available under that license. OpenBao does not manage devices, so confirm with the OpenBao project and your own design how it fits any device-side key storage you rely on.

Who owns mobile device controls, who helps, and who assesses

Your organization owns every mobile device control in the assessed scope. That means a named policy owner, an IT group that runs mobile device management and conditional access day to day, HR processes that trigger enrollment and removal, and a security function that decides who may be granted an exception. No outside party can accept that accountability on your behalf, and an assessor will test whether these roles are real, documented and exercised.

Policy owner: approves the mobile device standard, sets which devices and apps may reach in-scope systems, and reviews it on a defined cycle.
IT administration: configures device encryption, passcode rules, remote wipe and conditional access, and keeps the device inventory current.
HR joiners and leavers: triggers enrollment at onboarding and revocation or wipe at offboarding, with dated records of each action.
Security exception approval: records, justifies and time-limits any device that falls outside the standard, such as an unmanaged personal phone.
Ownership of evidence: keeps the exported compliance reports and exception logs that the assessor will sample.

Check that each role has a named person, a written procedure and a recent example of the procedure being carried out.

Where mobile device programs usually fall short

Most mobile device gaps in a HITRUST assessment are not missing tools. They are enrollment, enforcement and paperwork gaps that let a device reach in-scope data without anyone noticing. Each card names one gap, how to close it and the evidence an assessor would expect to see.

Personal devices reaching email unenrolled

Staff often add personal phones to corporate email or chat apps without enrollment, so the organization has no record of which devices can reach in-scope data. Close this by blocking mail and app access for unmanaged devices and requiring enrollment before access is granted. Evidence is the access policy, a device inventory that matches enrolled devices to accounts, and a sample of blocked attempts from unenrolled devices. Ask whether unenrolled devices are blocked or only discouraged.

Enrolled devices without conditional access

An MDM can hold a device in a managed state, yet nothing stops a non-compliant device from signing in. Conditional access ties sign-in to device health, such as encryption status, OS currency and screen lock. Evidence includes the conditional access rules, the compliance criteria they reference and sign-in logs showing non-compliant devices denied. Confirm which identity platform enforces the rule, since MDM alone does not gate access.

Encryption verified once, never again

A device passes an encryption check at enrollment and then drifts, through a disabled policy, a factory reset or a rooted device. Treat encryption as a continuing condition, reported on a schedule and acted on when it fails. Evidence is recurring compliance reports for encryption status, the remediation tickets raised for failing devices and the policy that blocks access until the device is fixed.

Leavers' devices not wiped

When someone leaves, a company phone or a personal device with corporate apps can keep its data and access. Closing this requires the offboarding process to trigger a remote wipe for corporate-owned devices and an app-level wipe for personal devices enrolled for work use, and to revoke tokens. Evidence includes the offboarding checklist, wipe commands with timestamps tied to termination dates and a reconciliation showing that leavers' devices left the inventory.

Exceptions granted without expiry

A device that cannot meet a requirement, such as an older OS used by a field team, often gets a waiver that is never revisited. Each exception should name the device, the requirement waived, a compensating control, an owner and an expiry date after which access lapses. Evidence is the exception register, approval records and a report showing expired exceptions were closed or removed.

Policies that do not match MDM settings

The mobile policy may promise a six-digit PIN, a wipe after failed attempts and blocked jailbroken devices, while the MDM is configured differently. An assessor compares the written policy with the live configuration, so any mismatch becomes a finding. Reconcile the two by mapping each policy statement to a named MDM profile or compliance rule, then export the configuration as evidence. Review the mapping after every MDM change.

Questions buyers ask about mobile device security cost, effort and scope

How much effort does mobile device security add to a HITRUST validated assessment?

Mobile Device Security is one of 19 assessment domains, so it adds a defined slice of scored work rather than a separate project. The effort depends on how many phones and tablets reach the in-scope systems, whether they are company-owned or personal, and whether the device management, encryption and conditional access controls already exist and produce evidence. Most of the effort comes from building the controls and collecting consistent evidence over time, not from the assessor's fieldwork itself. Ask a partner to break the work down by control area and by device population in the written scope, so you can see which parts are configuration and which are recurring operations.

Can mobile device security be inherited from a cloud provider?

Only slightly. In HITRUST's inheritance example for Oracle Cloud Infrastructure, the customer keeps responsibility for securing its mobile devices with encryption, mobile device management and conditional access, while the provider supplies multi-factor authentication and federated sign-in. That means a cloud provider's certification rarely covers the devices your staff use to reach the environment. Your own assessment must show how those devices are managed, even when the provider's platform controls are inherited. Check the provider's shared responsibility matrix line by line before assuming any part of this domain is covered.

Can our own team implement and evidence mobile device security in-house?

Often yes, provided the team has someone who owns device management, can configure encryption and conditional access policies, and can keep evidence current. The work is mostly administrative: defining device requirements, enrolling devices, enforcing settings, removing noncompliant devices and reviewing exceptions. The harder part is knowing what an assessor will sample and whether the records hold up over the assessment period. Internal staff who have not been through a validated assessment often underestimate that evidence burden. A partner can review your setup against the requirement statements before fieldwork, which is a readiness task that does not replace your own ownership of the controls.

What does mobile device security need from HR and IT?

It needs decisions from both functions. HR must confirm which staff are authorized to use mobile devices against in-scope data, which device types are permitted, and how joiners, movers and leavers are handled, including wiping or unenrolling devices when someone departs. IT must own enrollment, encryption settings, conditional access rules, remote wipe and the process for reviewing noncompliant devices. Agree on the policy text, the approval path for exceptions and who signs off on device records before the assessment starts. Without HR's offboarding inputs, device evidence tends to show stale accounts, which is a common reason evidence is questioned.

How far back must mobile device evidence go?

The evidence must show the controls operated across the period the assessment covers, not only on the day of review. Assessors normally sample records from that period, so a device that was compliant last month but has no history will raise questions. Confirm the exact evidence window and sampling approach with your assessor and in the HITRUST Assessment Handbook, because the rules differ by assessment type and by whether an incubation period applies. Keep device inventories, compliance reports, enforcement logs and exception approvals in a form that can be exported for a sample at any point in the window.

What should we ask a partner for in a quote for this domain?

Ask for a written scope that names the device population, the platforms and management tools in use, the control areas covered, and what is delivered for each. A useful quote separates one-time work (design, configuration, policy documentation, evidence templates and readiness review) from recurring work (monitoring, evidence collection, exception reviews and support). Ask which items depend on your environment, such as the number of devices or the state of existing tooling, and what changes the price or timeline. Confirm who is responsible for each deliverable and that the independent assessor, not the partner, issues any report. DeployOpen does not publish prices and provides a quote from the written scope.

How DeployOpen prepares mobile device controls and evidence

DeployOpen plans, implements and documents the self-hosted open-source platforms that support mobile device controls inside your own infrastructure. The organization still owns its controls, and only an independent HITRUST External Assessor can perform the validated assessment and HITRUST can issue a report.

How we scope

Agree in writing which mobile devices, operating systems and data classes fall inside the assessed environment.
Map which mobile controls your organization owns and which a cloud or identity provider supplies.
Confirm the evidence the assessor will request for encryption, device management and conditional access before work starts.

How we build

Deploy and configure device management and compliance policies inside your own cloud account or data center.
Set up device compliance checks that report which enrolled devices pass or fail each mobile policy.
Configure access conditions so only compliant, enrolled devices reach in-scope systems and data.

How we hand over

Deliver configuration records, policy exports and device compliance reports that show the controls operating over time.
Document the procedure for enrolling, retiring and wiping lost or departed devices, with named owners.
Provide a control-to-evidence map so your assessor can trace each mobile requirement to its supporting record.

How we support

Offer ongoing support, upgrades and testing of the mobile management platform as a retainer.
Review device compliance results with your team and help prepare corrective actions for failing devices.
Update configurations when operating systems, policies or the assessed scope change.