Laptops, phones and remote work inside a CMMC boundary

Every remote connection is part of your boundary

A laptop that leaves the building, a phone that gets work email and an engineer at a kitchen table are all inside the question CMMC asks: where does CUI go, and what protects it there? NIST SP 800-171 Revision 2, the version DoD holds contractors to, answers with a group of specific requirements, and several of them carry the highest point values in the scoring method.

The good news for a small firm is that a design decision can remove much of the burden. Keep CUI off most devices and most of these requirements get easier or apply to fewer places.

The remote access requirements

Four requirements in the access control family govern connections from outside. Point values come from 32 CFR 170.24 and the DoD Assessment Methodology.

Requirement	What it says	Points
3.1.12	Monitor and control remote access sessions	5
3.1.13	Employ cryptographic mechanisms to protect the confidentiality of remote access sessions	5
3.1.14	Route remote access via managed access control points	1
3.1.15	Authorize remote execution of privileged commands and remote access to security-relevant information	1

Put plainly: know who is connected, encrypt the session, force it through a small number of gateways you manage, and decide in advance who may run administrator commands from outside. Multifactor authentication under 3.5.3 applies to this path as well, because remote access is a type of network access.

A firm that allows no remote access does not lose points on 3.1.12, but the DoD methodology says it should also have a policy and procedure in place so the capability is not enabled inadvertently.

Split tunneling and meeting cameras

Two system and communications requirements catch remote setups by surprise. Requirement 3.13.7 says to prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks, which is split tunneling.

Requirement 3.13.12 prohibits remote activation of collaborative computing devices and requires an indication to users present at the device. Check the default configuration of your conference room hardware and meeting software. Each of these two is worth 1 point, and each is usually a setting in a VPN client or a meeting policy.

Mobile devices under 3.1.18 and 3.1.19

Requirement 3.1.18, "Control connection of mobile devices," is worth 5 points. Requirement 3.1.19, "Encrypt CUI on mobile devices and mobile computing platforms," is worth 3. NIST's footnote includes smartphones and tablets, and its discussion allows either full-device encryption or container-based encryption.

In practice, control means device management: enrollment, an inventory, a passcode requirement, remote wipe, and a rule about what can connect. Containers can work well on a phone because they protect only the work data and leave the rest of the device alone. If you have no mobile access at all, the methodology's point about a policy applies here too.

FIPS-validated cryptography is a module question

Requirement 3.13.11 says to employ FIPS-validated cryptography when it is used to protect the confidentiality of CUI. The DoD methodology is plain on what that means: "Simply using an approved algorithm (e.g., FIPS 197 for AES) is not sufficient - the module (software and/or hardware) used to implement the algorithm must be separately validated under FIPS 140."

So "encrypted" on a vendor's data sheet does not settle it. You need the module and its certificate. The scoring rule subtracts 5 points when encryption is not employed and 3 points when it is employed but not FIPS-validated, and that 3-point case is the one exception that can sit on a plan of action.

Two related items often get missed. A system patch can move a product off its validated version, and the CMMC rule offers that situation as an example of a temporary deficiency to track in your operational plan of action. Also, NIST's Cryptographic Module Validation Program set September 2026 as the point when FIPS 140-2 validations move to its historical list. When you buy or renew, ask vendors for the certificate number and whether a FIPS 140-3 module is available.

Ask three questions about every product that encrypts CUI: which module does it use, what is the certificate number, and is the version running in your environment the version that was validated. Record the answers in your system security plan, and check them again after major updates.

Laptops, data at rest and removable media

Requirement 3.13.16 protects the confidentiality of CUI at rest, and 3.13.8 addresses cryptographic protection of CUI during transmission, worth 3 points. On a laptop that leaves the building, that means full-disk encryption through a FIPS-validated module, plus transport encryption for everything in flight.

Requirement 3.8.7, control the use of removable media on system components, is worth 5 points. Requirement 3.8.6 requires cryptographic protection of CUI on digital media during transport unless other physical safeguards apply. If your people carry CUI on USB drives between home and work, fix that first. It is the most expensive habit on this page.

Alternate work sites

Requirement 3.10.6 says to enforce safeguarding measures for CUI at alternate work sites, and NIST's discussion names private residences of employees as an example. It is worth 1 point, and it is still the requirement that decides what a home office looks like.

A short written standard handles most of it: a space where others cannot read the screen, a locked screen when stepping away, no printing CUI at home unless the firm has approved a way to store and shred it, and a signed acknowledgment from each remote worker. Your home office rule is only as good as the record that each person agreed to it.

Your home office rule is only as good as the record that each person agreed to it.

Personal devices are external systems

NIST treats personally owned devices as external systems under 3.1.20, which requires verifying and controlling connections to and use of external systems. That requirement cannot be placed on a plan of action for a conditional status. Requirement 3.1.21 also limits the use of portable storage devices on external systems.

You can allow personal devices with terms and verified controls, and NIST's discussion says so. For most small firms it is simpler to decide that CUI never lands on one. The cost of a few company tablets or phones is usually less than the effort of proving control over equipment you do not own.

Three designs that keep the scope small

Design	How it works	Watch for
Virtual desktop	People reach CUI only inside a remote desktop. The rule treats an endpoint running a VDI client configured to allow nothing beyond keyboard, video and mouse as out of scope.	The configuration has to really block clipboard, drive and printer redirection; the virtual environment itself remains in scope
Managed, encrypted laptops only	Company-owned devices, encrypted, enrolled and able to reach CUI through managed gateways	Every device is in scope, so inventory and patching must keep up
No CUI on phones	Phones get approved apps for sign-in and calendar only. CUI mail and files stay on managed computers.	A policy alone will not hold; block mail sync and downloads technically

These combine well. A 25-person engineering firm might give its design staff virtual desktops, keep a few managed laptops for travel, and keep CUI off phones entirely. Each choice removes devices from the list of things that have to be proven.

Travel adds one more case. A laptop that goes to a customer site or a hotel needs the same encryption, the same managed connection and the same rule about screens and printing. Tell people what to do when one is lost or stolen, whom to call and how quickly, because a missing device with CUI on it may be an incident you have to report.

Evidence for remote work

• VPN or gateway configuration showing encryption, session logging and split-tunnel settings
• Device management export listing each laptop, tablet and phone, with its encryption status
• FIPS certificate numbers for the modules protecting CUI, recorded in the system security plan
• The remote work standard and signed acknowledgments
• Session logs from a recent period, to show remote access is actually monitored
• The rule for personal devices and the technical control that enforces it

Ways remote setups go wrong

• Calling a device out of scope while its users still sync CUI to it
• Trusting "AES-256" on a data sheet as proof of FIPS validation
• Forgetting the printers at home, where a paper copy of a drawing is still CUI
• Leaving a remote support tool outside the managed gateway because it came with the IT contract

Frequently asked questions