AC.L2-3.1.19 Encrypt CUI on mobile: evidence guide

AC.L2-3.1.19 asks you to encrypt CUI on every mobile device that holds it

AC.L2-3.1.19 requires you to identify every mobile device and mobile computing platform that processes, stores or transmits CUI, and to encrypt the CUI on each one. It is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.1.19, a derived requirement in the Access Control family that traces back to AC-19(5) (full device or container-based encryption) in SP 800-53 Rev. 4. The practical test is simple to state: if a laptop, phone, tablet or e-reader can open CUI, an assessor will expect to see that its contents are encrypted and that you can prove it. The requirement carries a 3-point weight under the CMMC Scoring Methodology, and because it is worth more than 1 point it cannot be placed on a POA&M. It must be MET before you can reach Conditional or Final Level 2 status.

The risk behind the requirement is ordinary and frequent: a laptop left on a train, a phone lost in a taxi, or a tablet taken from a site trailer. If the device is not encrypted, whoever recovers it can read the CUI stored on it or in cached mail and synced files. The hard part is rarely the encryption switch itself. It is knowing the inventory. Engineers often find devices that were never recorded, personal phones that receive company mail, and laptops where encryption was turned on years ago but nobody checked it after an operating system upgrade. Start by listing every device class in scope, then decide which ones are allowed to hold CUI at all. Mobile device access and connection controls under AC.L2-3.1.18 feed directly into this list.

Plan the evidence before the assessment, not during it. SP 800-171A lists mobile device access control procedures, encryption mechanisms with their configuration documentation, configuration settings and audit records as potential evidence, and assessors may test the encryption on a device themselves. Confirm with your assessor which artifacts they will accept, such as a management console export showing encryption status for each enrolled device, and make sure that export shows the encryption method. Also confirm that the cryptography meets the FIPS-validated standard that SC.L2-3.13.11 requires, since AC.L2-3.1.19 relies on it, and that key protection under SC.L2-3.13.10 is documented. Open-source tools such as osquery can report device state across a fleet on a schedule, which gives you current evidence rather than a snapshot taken on assessment day. Verify each capability against your own environment before you rely on it.

Which mobile devices and platforms fall under AC.L2-3.1.19

Scope decides how much encryption work AC.L2-3.1.19 creates. The requirement reaches any mobile device or platform that processes, stores or transmits CUI, so the first job is an inventory that separates devices holding CUI from devices that only view it. The cards below cover the decisions that change that inventory and the requirements that depend on it.

Laptops and mobile computing platforms

Laptops are the most common mobile platform that stores CUI, because files saved to local disks, synced folders or downloads persist after a session ends. Each laptop that holds CUI needs full-disk or device encryption using FIPS-validated cryptography, and the assessor will look for the configuration on the device itself. Check whether any laptop has a local copy of CUI, including cached mail attachments and browser downloads, before deciding it is out of scope. Treat any local CUI copy as in scope.

Smartphones, tablets and e-readers

Phones and tablets are in scope when they run mail clients, document viewers or sync apps that cache CUI, or when staff save CUI to them. E-readers are less common but still count if they store or transmit CUI. Confirm which applications write data to device storage, since a mail app with offline caching changes the answer. The assessment objectives for AC.L2-3.1.19 require you to identify these devices first, so an incomplete device list undermines every later test.

Personally owned devices used for CUI

Personally owned devices fall under AC.L2-3.1.19 whenever they process, store or transmit CUI, regardless of ownership. Bring-your-own-device programs need a written decision on whether the device is authorized under AC.L2-3.1.18 and whether the organization can enforce encryption on it. If the organization cannot enforce encryption, the practical choice is to block CUI from those devices, which also changes the AC.L2-3.1.20 external connection analysis. Ask every contractor whether personal devices touch CUI before the boundary is drawn.

Web-session-only access

A device that only reaches CUI through a browser session on a hosted system may not store CUI locally, but it still transmits it, so the scoping question shifts to what the browser caches, downloads or prints. Session-only access depends on the remote access controls in AC.L2-3.1.12 and the transmission protections in AC.L2-3.1.13. Document whether the browser policy blocks downloads and disk caching, and test that the configuration holds on a mobile browser as well as a desktop one.

Linked requirements that set the boundary

AC.L2-3.1.19 does not stand alone. It relies on SC.L2-3.13.11 for FIPS-validated cryptography and SC.L2-3.13.10 for key protection, and it extends MP.L2-3.8.1, MP.L2-3.8.2 and SC.L2-3.13.16 to mobile devices. The CMMC Assessment Guide states these dependencies, so a device that uses non-validated encryption fails 3.1.19 even if encryption appears enabled. Map each in-scope device to its cryptographic module and key storage before assessment preparation begins.

Phase II suspension and current obligations

The Department of War suspended CMMC Phase II in July 2026, so Level 2 certification is not yet required for most contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and those obligations still cover CUI on mobile devices. Scope decisions therefore matter for current contracts, not only for a future certification. Confirm with your contracting officer which clauses apply and keep the device inventory current, because the Department of War may revise its schedule.

How an assessor tests encryption on mobile devices

This table compares the two NIST SP 800-171A assessment objectives behind AC.L2-3.1.19, showing how each is tested, what evidence is requested and where findings usually occur. Read each row as a question the assessor will ask, then confirm the final test steps against the CMMC Assessment Guide Level 2 and 32 CFR Part 170.

Assessment element	Objective 1: identify mobile devices and platforms	Objective 2: employ encryption to protect CUI on them
What the assessor determines	Every mobile device and mobile platform that processes, stores or transmits CUI is identified and known to the organization.	CUI on those devices is protected by encryption that the organization has put in place and can show is working.
Test approach	Document review of the device inventory and access procedures, interviews with administrators, then comparison of the inventory against mobile device management or directory records.	Review of encryption configuration, interviews on how devices are enrolled, then sampling of devices to confirm encryption is enabled and enforced.
Evidence requested	Mobile device inventory, access control procedures for mobile devices, and records that link each device to its user and to the CUI it handles.	Encryption mechanism documentation, configuration settings showing encryption is enforced, and audit records of compliance checks.
Device sampling	Assessor selects devices from the inventory and checks whether they appear in the records and whether unlisted devices can connect to CUI resources.	Assessor selects devices from the inventory and checks encryption status directly on each sampled device, or through a management console the organization can demonstrate.
Common finding: unidentified devices	Personal or unmanaged phones, tablets or laptops reach CUI mail or file shares without appearing in any inventory.	Not applicable to this objective; unidentified devices cannot be sampled for encryption.
Common finding: encryption not enabled	Not applicable to this objective.	Encryption is disabled on sampled devices, or it was turned on for some devices but not enforced for new enrollments.
Common finding: FIPS-validated modules unproven	Not applicable to this objective.	The organization cannot show that the encryption modules used on mobile platforms are FIPS-validated, which AC.L2-3.1.19 relies on through SC.L2-3.13.11.
What to confirm before assessment	Final objective wording, sample size and the record types accepted, using the CMMC Assessment Guide Level 2 and 32 CFR Part 170.	Which mobile platforms are in the CUI boundary, how key protection under SC.L2-3.13.10 is evidenced, and the FIPS validation certificates for each module.

Implementing AC.L2-3.1.19 in ordered steps

This sequence moves from knowing which mobile devices and platforms hold CUI to a documented, tested encryption baseline that an assessor can check. Each step ends with an artifact the assessor can examine, so the organization can show that encryption is both configured and verified.

Inventory mobile devices and platforms that touch CUI
Start by listing every laptop, smartphone, tablet, e-reader and other mobile computing platform that processes, stores or transmits CUI, including personally owned devices if they are permitted to connect. Record the device type, operating system, owner, assigned user, unique identifier and the CUI data paths it touches. This work overlaps with the mobile device connection requirement, AC.L2-3.1.18, so one inventory can serve both. The output is a current device inventory that the organization can reconcile against its system security plan boundary. Confirm the inventory is complete by comparing it with directory, mobile device management and endpoint records, and note any gaps as open work before moving on.
Define the mobile authorization and encryption standard
Write a short procedure that states which device types and platforms are authorized for CUI, which operating system versions are acceptable, and what encryption must be active before a device can access CUI. The standard should name the FIPS-validated cryptography expected, cite the related requirements for cryptographic protection (SC.L2-3.13.11 and SC.L2-3.13.10) and state how exceptions are approved and recorded. The assessor will look for this document as the procedure that governs the configuration. Have the system owner approve it and keep the version history, because an undocumented or draft standard gives the assessor nothing to test against.
Enable device or full-disk encryption with FIPS-validated cryptography
Turn on full-disk or device-level encryption on every inventoried device, using the native mechanism of its platform or an approved management tool, and confirm that the cryptographic module in use is FIPS-validated and that the configuration is set to use it. Devices that cannot meet the standard should be removed from CUI access or restricted until they can. The output is a per-device or per-platform record showing encryption enabled, the module in use and the date it was verified. Ask the platform vendor or your integrator to confirm which FIPS validation certificate applies to the exact OS build in your fleet, since validation is tied to specific module versions.
Establish key protection and rotation
Define where encryption keys or recovery keys are held, who can access them, and how they are rotated or escrowed. For managed devices, key material should be protected by the platform and recovery keys should be stored in a controlled system rather than on the device itself. Where a self-hosted secrets service is used, its key management features, such as versioned keys and rotation, can support this step, but the organization must confirm what the chosen tool does before relying on it. The assessor will review the key management procedure and the access controls on the key store, so record both.
Configure, baseline and document settings
Push the encryption, lock and related settings through mobile device management or configuration baselines so they apply consistently, and capture the configuration as a baseline document or exported policy. Document which settings are enforced, which are user-controlled and how non-compliant devices are detected and blocked from CUI resources. Keep the configuration aligned with the configuration management practices in the CM family so changes go through review. The output is a configuration baseline and its export, which is the evidence the assessor uses to confirm the settings exist as described.
Verify encryption on sampled devices
Test a sample of devices from each platform and user group to confirm that encryption is active and that the configured settings match the baseline. Check the encryption status on the device, not only in the policy console, and record who tested, when, which devices were sampled and the result. Investigate and remediate any failures, then retest. The assessor may test the encryption mechanism on mobile devices directly, so the test record should show a repeatable method. Retain the test record in final form, not as a draft, because only final evidence supports a MET determination.
Capture audit records and monitor compliance
Set up logging so that enrollment, encryption state changes, policy failures and blocked access attempts are recorded and retained. Mobile device management consoles, endpoint query tools such as osquery, or log platforms can report encryption status across the fleet on a schedule, which gives ongoing proof rather than a single snapshot. Review the results on a defined cadence and document the review. The final output is a set of audit records and periodic compliance reports that show the encryption requirement holds over time, which an assessor can correlate with the baseline and test records.

Evidence that passes AC.L2-3.1.19 and how to keep it current

An assessor testing AC.L2-3.1.19 looks for proof that every mobile device touching CUI is known and that its encryption works as documented. The six artifacts below connect those two questions, and each one goes stale when devices join, leave or change configuration, so the evidence needs a refresh cycle between assessments.

Mobile device inventory with identifiers

A current register of every mobile device, laptop, tablet and e-reader that processes, stores or transmits CUI, with make, model, operating system version, owner, assignment and a unique identifier such as a serial number. This is the starting point for AC.L2-3.1.19 because the assessor must see which devices the encryption requirement covers. Check that the inventory matches the device management console and that retired devices are marked as removed with a date, not deleted.

Mobile access and encryption procedure

A written procedure that states which devices may hold CUI, how they are enrolled, which encryption method is required for each device type, and what happens when a device is lost or fails the encryption check. Assessors compare this document with actual device settings, so every rule in it should be enforced by a setting or a control that can be shown. Confirm the approval date and the owner, and make sure the version in use is the final one.

Encryption configuration documentation and settings exports

Documentation of the encryption mechanism on each device class, together with exported configuration settings that show full-device or container encryption is turned on. Exports from the mobile device management or endpoint tool are stronger than screenshots because they can be dated and compared over time. Look for a value in each export for the encryption state, the algorithm where the platform reports it, and any policy that prevents a user from disabling encryption.

FIPS validation statements for cryptographic modules

Documentation that the cryptographic modules protecting CUI on mobile devices carry FIPS validation, which supports the dependency on SC.L2-3.13.11 named in the CMMC Assessment Guide. Record the module name, the vendor's validation certificate reference and the platform version it applies to, and confirm that the validated mode is actually enabled. A certificate for a different module version than the one deployed is a common gap that assessors will raise.

Key management records

Records showing how encryption keys for mobile devices are generated, stored, escrowed, rotated and revoked, including the process for recovering access when a user forgets a passcode. The CMMC Assessment Guide ties this requirement to SC.L2-3.13.10 for key protection, so keys should not sit in plain text beside the devices they protect. Keep logs of key events and of who could approve a recovery, because assessors often ask how a lost-device key is revoked.

Audit and compliance reports over time

Periodic compliance reports from the management platform showing the encryption state of each enrolled device, the number of devices that failed the check, and the date each exception was closed. A single report proves little, so keep reports across the assessment window to show that encryption was enforced continuously and not only on the day of the review. Confirm that the reports are generated from the live system and that a device without encryption triggers an alert.

What meeting AC.L2-3.1.19 on mobile costs in money and effort

This table lists the cost components of encrypting CUI on mobile devices for CMMC Level 2, who is paid for each, whether it is one-time or recurring, and what drives it up or down. No fees are quoted because none were supplied; use it to build an itemized request for a fixed-scope quote. The main takeaway is that licenses are only one line, while configuration, evidence and key handling make up much of the effort.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Mobile device management or encryption tooling and licenses	Software vendor, or the organization if it already owns licenses	Usually recurring (subscription) plus any one-time setup	Fleet size, number of device types, existing licenses in Microsoft or other suite agreements
Engineering time to configure and verify device encryption	Internal IT staff or an implementation partner under a written scope	One-time, with periodic re-verification	Number of operating systems, personal device policy, how much enforcement is automated
FIPS-validated module selection and documentation	Internal security team or partner, plus any validation research	One-time, updated when modules or versions change	Number of cryptographic modules in use and whether their validation status is documented for each platform
Key management setup for device encryption keys	Internal IT or partner; key service vendor if purchased	One-time build, recurring operation	Whether keys are escrowed, rotated and recovered under documented procedures, and the number of key stores
Evidence upkeep (configuration exports, audit records, inventories)	Internal compliance or IT staff	Recurring	Frequency of exports, number of device groups, and whether evidence is collected automatically
External testing or review of sampled devices	Independent tester or reviewer, engaged by the organization	Recurring if repeated before each assessment	Sample size, device diversity and whether the review covers configuration only or also testing of encryption
Assessor time during certification, where applicable	Certified third-party assessor (C3PAO) paid by the organization	One-time per assessment cycle	Scope size, number of mobile device types in the assessment boundary, and current certification rules for the contract
Open-source tooling in place of some licenses	Internal staff or partner for deployment; no license fee for many open-source components	One-time deployment, recurring operation	Support model chosen, operator skills, and which platform capabilities must be built or confirmed

Open-source tools that support AC.L2-3.1.19 evidence

AC.L2-3.1.19 is judged on whether CUI on mobile devices is identified and encrypted, and on the configuration and key records that prove it. The four tools below can help produce parts of that record, from encryption at rest in a file store to key handling and fleet-wide device state. None of them replaces validated cryptography or the assessor's testing.

Nextcloud server-side encryption

Nextcloud's server-side encryption protects file contents at rest on local and external storage, with keys held on the server. Use it to show where CUI files are encrypted when they are synced to or stored on a platform that mobile clients reach. File names and folder structure are not encrypted, so document that metadata remains visible and decide whether it can hold CUI. Confirm the module's FIPS status with its vendor before citing it under SC.L2-3.13.11.

OpenBao transit key management

The OpenBao transit secrets engine encrypts and decrypts application data without storing that data, and keeps versioned encryption keys that can be rotated. This supports the key protection evidence an assessor expects under SC.L2-3.13.10 when mobile-related encryption depends on managed keys. Record key creation, rotation history and access policies as configuration evidence. Confirm which cryptographic modules OpenBao uses and whether they are FIPS-validated before relying on them.

osquery encryption state queries

osquery exposes host state as SQL tables, and its osqueryd daemon can schedule those queries across an entire fleet of hosts. Use scheduled queries to collect evidence that device encryption is enabled, with results recorded over time rather than from a single manual check. Confirm which tables are available for disk encryption on each operating system you manage, since coverage varies by platform. Its license is Apache-2.0 OR GPL-2.0-only, so choose the license option your legal team accepts.

Velociraptor endpoint hunts

Velociraptor collects forensic artifacts defined in VQL from endpoints and runs hunts across a group of systems. Hunts can schedule collection on offline machines when they reconnect, which helps close the gap for laptops and tablets that are not always on the network. Use hunts to gather encryption status and device inventory evidence for a sample or the full mobile fleet, then keep the notebooks as dated records. Its license is AGPL-3.0-only, which carries source disclosure duties for modified network-facing deployments, so review it with counsel.

Who encrypts mobile CUI: your team, a partner or the assessor

Your organization owns the control. Your team decides which phones, tablets, laptops and e-readers process, store or transmit CUI, whether each device is company-owned or personally owned, and what the mobile encryption standard will be. Your staff also approves the system security plan and holds the final evidence the assessor will review. A partner can configure devices, but the configuration is not compliant until your people have approved it and can show it working.

Device scope decisions: Decide which mobile devices and platforms fall inside the CUI boundary and which fall outside it, then record that decision in the system security plan.
Encryption standard: Choose the cryptographic modules and encryption settings that satisfy SC.L2-3.13.11, and confirm the FIPS validation status of each module yourself from the vendor's documentation.
Key and policy ownership: Assign a named owner for key protection under SC.L2-3.13.10, for passcode and wipe policy, and for lost or stolen device response.
Evidence acceptance: Review configuration exports, audit records and device inventories for completeness and accuracy before anything is labeled final.

Check that a named employee can explain every encryption setting in scope and produce its evidence without the partner in the room.

Where organizations fall short on mobile encryption

Most failures against AC.L2-3.1.19 come from a gap between what the policy says and what the fleet actually does. The cards below cover the places where that gap usually opens, and each one names the evidence that would expose it before an assessor does.

Mobile devices missing from the inventory

Assessors start with the question of which mobile devices process, store or transmit CUI. A phone that receives controlled drawings through a mail client but never appears in the asset list cannot be shown to be encrypted, because nobody has checked it. Reconcile the mobile device inventory against mail, collaboration and VPN enrollment records, and against the system security plan's description of the boundary. Ask whether tablets and e-readers used by engineers are on the list too.

Encryption enabled but never verified

A policy that requires device encryption proves little until someone confirms the setting on real hardware. Sampled devices often show encryption as enabled in a mobile management console while the local state differs, for example after an OS upgrade or a failed enrollment profile. Pull configuration and compliance reports from the management platform on a schedule, sample devices across models and OS versions, and keep the dated results as audit records.

Personal phones receiving CUI email

Employees often add a work mailbox to a personal phone to answer a quick question about a contract. That device sits outside company control, so it is hard to show encryption, remote wipe or device identification. Check mail and document sync logs for unmanaged devices, and decide whether such access is blocked, limited to a managed container, or formally authorized with the same encryption and identification evidence as company-owned devices.

No proof the cryptography is FIPS-validated

AC.L2-3.1.19 relies on FIPS-validated cryptography through SC.L2-3.13.11, so a device that is encrypted with an unvalidated module does not satisfy the requirement. Many teams cannot say which module their mobile platform uses or whether the mode in use is the validated one. Record the cryptographic module name, its validation certificate, and the configuration that enables the validated mode. Confirm these details with the device vendor, because the answer varies by platform and version.

Undocumented key management

Device encryption depends on keys that must be protected and recoverable, and SC.L2-3.13.10 expects documented key protection. Teams often rely on default vendor escrow without writing down who can recover a key, how recovery is logged, or what happens when a device is lost. Document the key lifecycle for each platform, state where escrowed keys are stored and who holds access, and keep the recovery and rotation logs assessors will ask to see.

Procedures that describe settings not enforced

A mobile procedure that requires a six-digit passcode, encryption and a wipe after failed attempts means little if the fleet does not enforce those settings. Assessors compare the written procedure with configuration settings and audit records, and a gap between the two is a finding. Map each procedural statement to a configuration profile or compliance rule, test that a non-compliant device is blocked or quarantined, and update the procedure whenever the policy engine changes.

Questions buyers ask about AC.L2-3.1.19

How much effort does AC.L2-3.1.19 take to meet?

The effort depends on how many devices process, store or transmit CUI and how many device types and operating systems are involved. No supplied fact gives a dollar figure or duration for this work, so treat any number you hear as unverified. The main cost components are the time to identify every mobile device and platform in scope, the time to configure and verify device or full-disk encryption on each one, the time to document the encryption mechanisms and their settings, and the time to collect audit records that show the controls operate. Most of this is one-time setup. Ongoing costs recur through enrolling new devices, reviewing encryption status and refreshing evidence before each assessment. Ask any partner to split the quote into discovery, configuration, evidence and recurring checks.

How long does AC.L2-3.1.19 work usually take?

The timeline scales mainly with fleet size, device diversity and how well the device inventory already exists. A contractor with a small, uniform fleet managed through one mobile device management tool has far less to configure than one with laptops, phones, tablets and e-readers across several operating systems and personally owned devices. Other drivers include whether encryption is already enabled, whether the organization has a documented mobile policy, and how many approval cycles are needed. Because no researched duration is available for this requirement, ask a partner to tie the schedule to a written scope with named deliverables, and to show which steps depend on your staff's availability.

What does AC.L2-3.1.19 need from our IT and security staff?

Your staff must own the decisions and supply the environment access. They need to confirm which devices and platforms process, store or transmit CUI, approve the encryption approach, and provide administrator access to device management, identity and logging systems. They also own the policy text, the approval records and the configuration baselines, because the organization is responsible for its controls. Expect time from the people who maintain the mobile fleet, the security lead who signs off on cryptographic choices, and whoever keeps the system security plan current. A partner can prepare configurations and evidence, but the organization must accept them and keep them up to date.

Can a small defense contractor meet AC.L2-3.1.19 in-house?

Yes, a small contractor can meet this requirement in-house if it has someone who understands device encryption, FIPS-validated cryptography and evidence collection. The requirement is achievable without outside help, but the work is easy to underestimate. The hard parts are not the toggles, they are the inventory of every mobile device touching CUI, the proof that encryption is actually enforced on each one, and evidence in final form that an assessor will accept. Consider outside help when nobody on staff has done this before, when the fleet is mixed, or when the timeline is fixed by a contract. Any consultant or partner must keep the assessor relationship independent, since only a C3PAO issues the Level 2 certification assessment result.

Can AC.L2-3.1.19 go on a POA&M?

No. AC.L2-3.1.19 is worth 3 points under the CMMC Scoring Methodology, and the CMMC rule does not allow requirements worth more than 1 point on a plan of action and milestones. The requirement must be MET to reach Conditional or Final Level 2 status. Plan the work so that every mobile device touching CUI is identified and encrypted before the assessment window, rather than assuming a remediation timeline will be accepted. Confirm the current scoring and POA&M rules against the eCFR text, because the rule set and program schedule have been changing.

Does the Phase II suspension change the work for AC.L2-3.1.19?

The suspension changes when certification may be required, but it does not remove the technical work. On 13 July 2026 the Department of War suspended CMMC Phase II, which had been scheduled to start 10 November 2026 and would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, and NIST SP 800-171 Rev. 2 is still enforced in the interim. Since AC.L2-3.1.19 is required for the self-assessment score, the encryption work still matters now. Check the DoW CIO About CMMC page for the current status, because it has described implementation as paused in Phase 1.

What should we ask a partner to include in a quote for AC.L2-3.1.19?

Ask for a written, fixed scope that names each deliverable. A useful quote should list:

The mobile devices and platforms in scope, with the discovery method used to identify them
The encryption mechanisms, the FIPS-validated cryptography relied on, and how key protection is handled
The configuration baselines, device management settings and verification steps for each device type
The evidence package, including documentation, configuration settings and audit records in final form
Recurring work such as enrolling new devices, reviewing encryption status and refreshing evidence
Who is responsible for each control, and what the organization must provide

DeployOpen plans and implements self-hosted open-source platforms inside your environment and prepares systems and evidence, but it does not issue assessment results or certifications. Confirm with any partner which parts are one-time and which recur.

How DeployOpen prepares AC.L2-3.1.19 evidence

DeployOpen plans and builds the mobile device encryption, device inventory and configuration records that AC.L2-3.1.19 Encrypt CUI on mobile depends on, inside your own infrastructure. The organization owns the control and its evidence, and only an independent assessor can issue a CMMC assessment result.

How we scope

Scope lists which mobile devices and mobile computing platforms process, store or transmit CUI.
Scope names the encryption mechanisms, key handling and management tools in the written agreement.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.

How we build

We configure device and platform encryption so CUI on mobile devices is protected with FIPS-validated cryptography.
We align key protection with the related SC.L2-3.13.10 and SC.L2-3.13.11 requirements, confirming each mechanism with the vendor.
We test encryption settings on sample devices and record the configuration baseline before handover.

How we hand over

Documentation covers the device inventory, encryption configuration, key procedures and the configuration settings assessors review.
Audit records showing encryption status and device identification are exported in a form your assessor can examine.
Evidence is delivered in final form, with each assessment objective of NIST SP 800-171A mapped to a named artifact.

How we support

Ongoing support, upgrades and continuous testing are available as retainers for devices added after handover.
We help you re-verify encryption when operating systems, devices or policies change.
Your organization decides which evidence is submitted and how, and your independent assessor reaches the final determination.