The complete reference

Your directory is not your authorization list.

Your directory is the service that holds user accounts, such as Microsoft Entra ID or Active Directory. An export from it shows who has access, not who is supposed to have it. An account an attacker creates would count as authorized by that logic. Objective [a] needs an authorization record kept outside the system itself. A spreadsheet is enough, with the person's name, the reason they need access, and the date the entry was last validated. Compare the directory against that list. The comparison is what shows access is limited under [d].

Cover all three populations: users, processes, and devices.

Objectives [a] through [c] identify authorized users, processes acting on their behalf, and devices. [d] through [f] limit access to what was identified. Service accounts, the accounts that applications run under rather than people, are the population people miss. Inventory each one with what it does and the ticket or record that authorized it. Capture its permissions from the directory as the evidence for [b] and [e]. A web server running under its own account belongs on that inventory.

Device authorization needs its own mechanism, not just user logon.

For [c] and [f], keep a list of devices allowed to connect, and put something behind the list that enforces it. Conditional access, the sign-in rules in Microsoft Entra ID, can require a compliant or registered device. A firewall allowlist of MAC or IP addresses works too, as does port-based network authentication. A small organization can pair the device list with a recurring network scan. Compare what is on the network against what is approved, and remove anything that should not be there.

Authorize in writing, before access is granted.

An assessor cannot validate an approval given verbally in a meeting nobody documented. Tie every account and device to a request and an approval: a ticket, an email, or a signed row in the authorization list. The question each entry answers is how IT knew to create it in the first place.

Write the system security plan by asset category, not per device.

Your system security plan is the document that describes how your system meets each requirement. Describe how all laptops, all servers, and all security protection assets are limited, rather than writing an entry per machine. Per-asset write-ups produce redundancy without adding evidence.

Objective [a] is a document you write, not a setting.

List the user types in your system, such as standard user, administrator, and finance, and the transactions and functions each may execute. Create, read, update, and delete per system or application is the level of granularity the assessment guide uses. A one-page matrix satisfies [a].

Objective [b] is the enforcement of that matrix.

Show the roles and groups that implement it: Microsoft 365 role assignments, file share permissions, application roles, or an application control tool. Present the configuration next to the matrix so the assessor can see that what is defined is what is enforced.

You do not need a directory service to meet this.

A four-person shop can use local Windows standard versus administrator accounts and application allowlisting, which blocks unapproved programs. Confine CUI, the controlled unclassified information your contract requires you to protect, to specific application accounts. Define the split and enforce it with what you have. An answer scaled to your size is enough.

Personal use is yours to define, not yours to ban.

Nothing in the requirement forbids web mail or music streaming on a NIST SP 800-171 system. What it requires is that you define the limits and keep personal applications and accounts away from CUI and official duties. A wide personal-use allowance creates work elsewhere, in CM.L2-3.4.7 for least functionality and AC.L2-3.1.20 for external connections. The more personal use you allow, the more you have to control elsewhere.

AC.L2-3.1.1 covers who gets access. This requirement covers what they can do once they have it.

Keep the two answers distinct in your system security plan. Account authorization and inventories live under AC.L2-3.1.1. This requirement is where you show that a proposal writer cannot reach developer tools and a developer cannot reach the HR database.

Flow control is about where CUI travels, not who may access it.

CUI is the controlled unclassified information your contract requires you to protect. AC.L2-3.1.1 and AC.L2-3.1.2 govern access. This requirement asks you to name where CUI is allowed to move: between your enclave and the prime, between your sites, into and out of cloud services and subcontractors. You do not have to account for where all traffic goes, only where CUI goes, so there is no obligation to list every website your users visit.

A data flow diagram carries objective [c].

Draw every place CUI enters, lives, and leaves, the systems it sits in, and the channels between them, with a short explanation of each source and destination. That one artifact answers [c], and the rest of the requirement refers back to it.

Objectives [a], [b], and [d] call for a policy. [e] asks for proof.

Write down how CUI is allowed to move, which methods and mechanisms enforce that movement, and who is authorized to move it. Then show the enforcement: access control lists on the CUI library, sharing restrictions, or a data loss prevention (DLP) rule. In a small shop, the signed policy and the training records that back it are the enforcement. Objective [e] is where the assessor checks that [a] through [d] are real.

Policy plus training is a legitimate enforcement mechanism for a small organization.

The assessment guide's own example meets the requirement with a written transmission policy, manager approval, encryption or a secure transfer utility for outbound CUI, and a disciplinary clause. As users, devices, and data volume grow, add technical enforcement such as sensitivity labels and DLP, because at scale a signature does not stop an upload.

Do not block the internet to pass this.

No objective requires blocking public web access, allowlisting inbound email senders, or banning personal email sites. Building an egress allowlist of every site your users may reach is a huge undertaking the requirement never asks for. Keep the controls pointed at the paths CUI actually takes.

You define which duties require separation, so define ones you can execute.

The requirement is silent on what must be separated, which hands you the power of definition. A general statement that duties are reasonably divided fails [a]. Name the specific pairs: change approval separated from change execution, log review separated from system administration, account creation separated from granting CUI access. CUI is the controlled unclassified information your contract requires you to protect. Never define a separation you cannot staff, because you will be assessed against your own definition.

Separate authorizing, doing, and auditing.

That three-way split is the pattern that satisfies [b] and [c] in nearly any structure. Whoever approves a change does not implement it, and whoever reviews the logs is not the only administrator generating them.

The purpose is visibility, not prevention.

Separation of duties does not stop a bad act so much as make it impossible to hide, because someone else sees the tracks. Aim the design at that: a second set of eyes on privileged activity beats an elaborate approval chain nobody follows.

A two- or three-person company can meet this without hiring.

Two administrators reviewing each other's activity meets the intent. Here is a three-person model that works. One person runs IT, a second approves changes, and a third reviews logs for everyone including the first. An outside consultant with even an hour a month of genuine log review creates real separation for the auditing leg.

Assigned authority must be real.

An assessor probes whether the person can exercise the duty, not just whether their name is on it. If the change approver says no and the change ships anyway, the separation exists on paper only. Show competence and authority: training records for the assigned duty, an example of a rejected change, log reviews signed by the reviewer.

Identify your privileged accounts before anything else.

Objective [a] is a list, and every environment has entries for it because somebody runs the IT. Claiming there are no privileged accounts earns a Not Met. You may define the category narrowly, domain admins and global administrators for example, but the list must exist, be written down, and match reality.

Give every administrator two accounts.

A daily account with no elevation and a separate admin account used only for administrative work is the pattern that answers [b] at any size. In a three-person company, two accounts per administrator is enough. A third tier adds ceremony without adding compliance.

Objective [c] wants your security functions named.

Establishing accounts, configuring access authorizations, setting events to be logged, and tuning intrusion detection are the guide's examples. List which of these exist in your environment and which roles reach them. Objective [d] then follows: restrict each function to the few people whose job requires it, and record that authorization.

Stop using the highest privilege for everything.

Running routine endpoint work with a domain admin account is the principle of most privilege, and one piece of malware in that session reaches everything the account reaches. Scope the credential to the task. Use a local admin credential for endpoint installs and narrow Microsoft Entra ID roles instead of Global Administrator. Where the platform offers it, use Privileged Identity Management, which grants admin rights just in time and takes them back after.

This requirement is policy and habit, built on the account separation from AC.L2-3.1.5.

AC.L2-3.1.7 technically blocks non-privileged users from privileged functions. This requirement points the other way: privileged people must use their non-privileged account for ordinary work. The implementation is a written rule, training that reinforces it, and the two-account pattern that makes following it possible.

Define nonsecurity functions as everything that is not a security function.

Objective [a] does not demand a second inventory. Identify your security functions under AC.L2-3.1.5, then state that all other functions are nonsecurity functions and must be accessed with non-privileged accounts or roles. Assessors accept that definition, and it stays correct as your systems change.

The rule in one sentence: do not read email or browse the web from a privileged session.

Put that sentence in the rules for administrators, train on it, and keep the acknowledgment. A compromised browser tab in an administrative context is the exact exposure this requirement exists to prevent, and it is the first thing an assessor asks administrators about in interviews.

Elevation models count as roles.

sudo on Linux and Privileged Identity Management in Microsoft Entra ID both fit the requirement: the user operates without privilege until a scoped, temporary elevation, then drops back. What fails is standing elevation, an account that carries administrator rights all day while being used for daily work.

Define privileged functions as categories, not a command inventory.

Objective [a] is satisfied by categories: establishing accounts, configuring access authorizations, setting events to be audited, patching, administering security tooling, and managing cryptographic keys. Enumerating every individual command produces an unmaintainable list and no additional compliance.

Objective [b] is one sentence, and [c] is your standard user build.

Define non-privileged users as everyone not on the privileged account list from AC.L2-3.1.5. Prevention under [c] is what a correctly configured standard account already does: no administrator rights, elevation prompts the user cannot satisfy, installs blocked. The evidence is the central configuration that builds those accounts, a group policy or a mobile device management profile, plus a demonstration that a standard user cannot execute an administrative action.

Objective [d] asks for capture, not review.

Configure logging so privileged operations land in the audit log, and be ready to say which events you capture and why. There is no mandated list of event IDs. A reasoned selection with a recorded rationale is sufficient. Keep the specific event IDs in your configuration baselines, not in policy, so the policy states the expectation and the baseline carries the detail. Reviewing what you captured belongs to the Audit and Accountability requirements, not here.

Log privileged use even where prevention is airtight.

Objective [d] covers the privileged users themselves, not just blocked attempts by everyone else. The guide's own example is an accidental privilege grant that surfaced only because privileged activity was being logged and an unexpected actor appeared in it.

Pick a threshold and a lockout behavior, write both down, and configure them.

Objective [a] wants the means defined: after a set number of consecutive failures the account locks, either for a fixed period or until an administrator releases it. Objective [b] wants that exact configuration present in the system. The number is yours to choose. There is no mandated value, and fewer permitted attempts means higher security.

Prefer a temporary lockout with automatic release.

A lockout that releases after a delay blunts password guessing without turning failed logons into a denial of service or a standing help desk queue. The guide's own example pairs a three-attempt lockout with a thirty-minute automatic release and an administrator override. Reserve permanent lockout for accounts where the risk justifies the friction.

Apply the limit at every logon surface.

Workstations, VPN gateways, and your identity provider, the service that checks user sign-ins, each present a logon, and each needs the defined limit. Windows account lockout policy, Microsoft Entra ID smart lockout, and the failure limit on your VPN are all implementations of the same defined means. List each surface and its setting so [b] is demonstrable everywhere someone can type a password.

A notice at initial logon carries this requirement.

Display the notice where human users log on, at or before authentication. A notice on every application and system behind that first logon is a risk-based choice, not a requirement. The underlying discussion says a secondary notification is something you consider, not something you owe. One well-placed banner beats twenty inconsistent ones.

Write your own text. Do not copy the DoD banner.

The standard DoD banner speaks for U.S. Government information systems and never mentions CUI, the controlled unclassified information your contract requires you to protect. Yours is a private system that handles government information. Cover the essentials: use may be monitored and recorded, use constitutes consent, unauthorized use is prohibited and carries penalties, and the system may contain CUI to be handled per your policy. Have counsel review it, because the banner's function is legal notice, not decoration.

A generic CUI statement is enough.

Objective [a] ties notices to CUI-specified rules, and few categories impose special notice requirements. Stating that the system may contain CUI and pointing to your handling policy satisfies the association. You do not need to enumerate CUI categories in the banner.

The display can take several forms.

A logon banner, a desktop background carrying the notice, a Terms of Use acknowledgment enforced at sign-in through conditional access, or printed notices posted where no screen exists all satisfy [b]. Pick what each platform supports, keep a screenshot of each, and note in the system security plan which form covers which system.

Define one number and let the operating system do the rest.

Objective [a] is the inactivity period, written in policy. Fifteen minutes is a common choice, and the requirement sets no value. Enforce the OS lock at that number through group policy or Intune and [b] follows. Every mainstream lock screen hides the desktop behind an image, a clock, or a blank display, which is all the pattern-hiding [c] asks for. Just confirm the locked screen itself cannot show CUI, the controlled unclassified information your contract requires you to protect.

Manage the setting centrally or prove users apply it themselves.

Central enforcement removes the question. For any machine outside central management, you need a documented required setting, users told to apply it, and a way to verify they did. That is a harder story to tell than one Intune policy, which is the argument for central management.

Web applications reachable from unmanaged devices need their own timeout.

OS session lock protects the machine it runs on. If a portal that touches CUI can be reached from a device you do not manage, the application or a gateway in front of it must enforce its own inactivity timeout. You cannot vouch for the lock on a device you do not control. When access only happens from managed endpoints with enforced lock, the OS answer covers the application too.

Session lock is not a substitute for logging off.

Lock covers the walk-away case. It does not replace ending sessions under AC.L2-3.1.11. Where a platform cannot lock a session, terminating it is the right lever instead, and the two requirements together cover the unattended session from both ends.

Define termination conditions you can actually execute.

Objective [a] leaves the conditions to you: user logoff, account disablement, a scheduled restart, a policy violation, a time-of-day cutoff. NIST SP 800-171 Revision 2 mandates no inactivity timeout for this requirement. Choose conditions your systems genuinely enforce and write them in the system security plan, because [b] is assessed against your own definition.

Simple definitions are defensible.

One complete answer defines two conditions: sessions end when the user logs off and when the account is disabled. A weekly forced restart is another: it terminates every session on a schedule and doubles as update hygiene. The trap is not modesty. It is defining a condition, such as a nightly logoff script, that turns out not to run everywhere you claimed.

This is the logical session, not the network connection.

SC.L2-3.13.9 handles terminating network connections. A VPN client disconnecting after twelve hours is a network event. This requirement is about ending the user's logical session, the thing that logoff, disablement, and restart end. Keeping the two straight avoids answering the wrong requirement with the right evidence.

Do not punish users with aggressive idle logoffs.

A short idle logoff on ordinary workstations disrupts work without a compliance payoff, since the requirement names no timeout. Save tight idle termination for virtual desktops (VDI), shared machines, and high-exposure systems where it earns its cost.

Answer four questions in one policy.

Objective [a] asks whether remote access is permitted. Objective [b] asks which types: VPN, access to cloud services over the internet, vendor support sessions. Objective [c] asks how each is controlled: managed devices only, multifactor authentication, conditional access, device health checks at connection. Objective [d] asks how each is monitored: which logs exist, who reviews them, how often. That document, with the configurations and review records behind it, is the whole requirement.

Define what counts as remote in your environment and defend it in writing.

Whether an established VPN session from a company-owned laptop is still remote access has no settled answer among assessors. Take the durable position. The tunnel is a type of permitted remote access, so list it under [b], then control and monitor it. If you then treat traffic inside the established tunnel as internal, document that treatment and its rationale. The requirement's own discussion says encrypted VPNs do not make access non-remote. They let you treat the connection like an internal network once controlled.

Cloud access is remote access for this requirement.

Sessions to Microsoft 365 or any internet-reached service matter when those services hold CUI, the controlled unclassified information your contract requires you to protect. TLS, the standard encryption on web connections, plus conditional access policies requiring compliant devices are your [c]. The identity provider's sign-in logs and their review are your [d]. A fully cloud organization with no office still has types to identify under [b]: name the TLS access paths and the gateway or conditional access layer that fronts them.

Monitoring means a person looks at the logs.

Collection is not monitoring. Write the review procedure for VPN and sign-in logs. Run it at a frequency matched to your risk. Keep the artifacts: a ticket closing the review, an alert and its disposition, an email summarizing findings. An assessor asks for the procedure and then asks for proof it ran.

No CUI over the remote link does not scope this requirement out.

Remote access used for system maintenance is still remote access to an in-scope system, and the requirement applies. The only way to scope it out is to prevent remote access entirely and have the policy and configuration that prove it.

Name the mechanism for every remote path, then show it running.

Objective [a] is the specific cryptography protecting each type of remote access you permitted under AC.L2-3.1.12: TLS on the VPN, TLS to each cloud service, SSH for administrative sessions. Objective [b] is the configuration evidence. Map each permitted type to its mechanism so no path is left uncovered, and the two objectives fall out of one table.

Sessions that carry CUI need a FIPS-validated module, not just an approved algorithm.

CUI is the controlled unclassified information your contract requires you to protect. The assessment guide is explicit that an approved algorithm alone is not sufficient. The module implementing it must be validated under FIPS 140, the federal standard for cryptographic modules. The validation requirement itself is SC.L2-3.13.11 territory. What belongs here is the mapping: which validated module protects each remote path over which CUI travels.

One validated layer is enough when encryption stacks.

A FIPS-mode TLS session riding inside a VPN whose own encryption is not validated still protects the session, because one layer end to end is validated. Decide which layer is your validated layer for each CUI-bearing path and write it down, rather than trying to make every layer validated at once.

A FedRAMP-authorized service can be the validated layer.

FedRAMP is the federal cloud authorization program. When every CUI flow ends in GCC High, the government cloud version of Microsoft 365, or another service that provides FIPS-validated TLS, that service carries the cryptographic burden for those flows. Your VPN does not need to be FIPS for them. Confirm the coverage against your data flow work from AC.L2-3.1.3 before relying on it, because one overlooked CUI path to a file server changes the answer.

A policy forbidding remote CUI access does not remove this requirement.

The requirement protects remote access sessions, and sessions used for administration expose credentials and security-relevant configuration even when no CUI crosses them. Encrypt every remote session. Reserve the FIPS-validation question for the sessions that carry CUI.

Funnel every remote path through a small number of points you manage.

Objective [a] asks you to identify and implement the control points. [b] asks you to show that all remote access actually routes through them. A VPN concentrator, the device that terminates every VPN connection, behind the firewall is the classic answer: one auditable door instead of a dozen ad hoc paths. That simplifies both monitoring under AC.L2-3.1.12 and this requirement's evidence.

Cloud-only environments already have the control point.

Conditional access in Microsoft Entra ID is a gate every session passes through: it decides who connects, from which devices, under which conditions, and it logs the decision. Document it as your managed access control point. You do not need to bolt a VPN onto a cloud-native architecture to satisfy this requirement.

A network diagram is the cleanest evidence.

Mark each access control point and show that no remote path bypasses them. For a hybrid shop that is the VPN gateway for network access and the conditional access layer for cloud services, on one page.

A managed point does more than pass traffic.

Managed means the point enforces policy and leaves a record: it authenticates against your identity provider, logs connections into your log tooling, and applies inspection or health checks where feasible. A port forward on an unmanaged router is a hole, not an access control point.

This requirement governs remote administration, and it is answered with authorization lists.

Identify which privileged commands may be executed remotely [a] and which security-relevant information may be reached remotely [b], then show both are authorized [c] and [d]. If administrators can do administrative work from outside the boundary, write down what they may do, from where, and under whose approval. Avoiding remote privilege entirely is the strongest position. Where the business needs it, the documentation is the control.

Authorize by role, not by command inventory.

Enumerating individual commands produces a list nobody can maintain. State instead that the commands granted by your named administrator roles in Microsoft Entra ID or Active Directory are authorized for remote execution by the people holding those roles. An assessor who wants the command list gets the role definitions that bound it, a better answer than a stale spreadsheet.

If privilege requires being inside the boundary first, say exactly that.

A clean posture for VPN-centric environments: no privileged commands are authorized for remote execution. Administrators must first establish an approved remote access session under AC.L2-3.1.12 and AC.L2-3.1.14, and administration then happens inside the controlled boundary. Write it that way in the system security plan and enforce it. The statement converts four objectives into one architectural fact.

Inventory your remote execution vectors.

Intune script deployment, remote monitoring and management (RMM) agents, PowerShell remoting, SSH, and patch management platforms all execute privileged commands on machines the operator is not sitting at. Each belongs under [a] with its authorized operators under [c]. These vectors are easy to forget precisely because they are routine.

Security-relevant information is yours to define.

Audit log configuration, security tool settings, firewall rule sets, and access control configuration are the core of it. Name what qualifies in your environment and who may reach it remotely, and [b] and [d] are complete. Browsing an admin portal from home is remote access to security-relevant information, so cover it with the same role-based authorization and conditional access controls.

Objective [a] is an inventory and [b] is an approval gate in front of it.

List the wireless access points and networks in scope, and require authorization before any user or device connects. Policy names who approves and what qualifies, and configuration enforces it. The pairing to show an assessor is the current access point list next to the mechanism that keeps unapproved devices off.

WPA2 with a pre-shared key, one WiFi password shared by everyone, clears this requirement.

Authentication and encryption at the access point are what matter here. Certificate-based onboarding and 802.1X, the per-user network logon standard, are stronger and serve IA.L2-3.5.2 well. They are not the bar for AC.L2-3.1.16, and building a RADIUS authentication server solely for this requirement is effort spent past the objective.

Provision the key so users never learn it.

IT joins devices to the wireless during setup, or the device management platform pushes the WiFi profile. Authorization and connection then become the same controlled event, and the pre-shared key stops circulating on whiteboards. Rotate a shared key whenever someone who knows it leaves, which is also the reason larger teams outgrow shared keys.

No wireless does not mean not applicable.

If wireless is disabled or was never deployed, write the requirement as met: policy prohibits wireless access and configuration enforces the prohibition. That answer is verifiable. A not-applicable claim invites a scoping argument you do not need.

One configuration answers both objectives.

WPA2 or WPA3 gives you authentication [a] through the key or enterprise logon and encryption [b] through AES in the same setting. Never run an open network in scope. Open authentication admits anyone and fails [a] outright.

Match the authentication mechanism to your size.

A pre-shared key works for a small, stable team, with rotation on every departure. WPA2 or WPA3 Enterprise against a RADIUS authentication server authenticates each user or device individually and scales past the point where a shared secret is manageable. Both are acceptable. Pick the one you will operate correctly.

Decide which layer protects CUI that crosses the air.

CUI is the controlled unclassified information your contract requires you to protect. Wireless traffic leaves your boundary, so CUI crossing it needs FIPS-validated encryption at some layer of the stack. If every CUI flow already rides a validated layer higher up, a FIPS-mode VPN or TLS to a FedRAMP-authorized service, the WiFi is transport and does not carry the CUI burden. If the wireless link is the only encryption between a laptop and a CUI file share, the WiFi inherits the FIPS question, and consumer-grade access points do not answer it. Trace your CUI data flows before deciding which case you are in. SC.L2-3.13.11 governs the validation itself.

Enterprise authentication does not answer the encryption question.

EAP-TLS, the certificate-based enterprise logon, strengthens how session keys are established, not the validation status of the encryption modules. Treat [a] and [b] as separate accounts: strong authentication on one side, and a deliberate answer on the other for where validated encryption lives.

Settle the definition first: phones and tablets, not laptops.

The guide defines a mobile device by small form factor, wireless operation, on-board storage, and a self-contained power source, and its examples are smart phones, e-readers, and tablets. Laptops are mobile computing platforms, addressed by AC.L2-3.1.19. An assessor may still ask about laptops here. Answer from the definition, and show laptops handled under the requirements that do govern them.

The three objectives are a list, a gate, and a log.

CUI is the controlled unclassified information your contract requires you to protect. Identify which mobile devices process, store, or transmit CUI [a], authorize connections before they happen [b], and monitor and log them [c]. A mobile device management or mobile application management platform delivers all three at once: enrollment is the identification and the authorization gate, and the console provides the monitoring and logging. Assign each device an identifier so the log entries tie back to the inventory.

Application-level management works for bring-your-own-device.

App protection policies through Intune contain CUI inside managed applications on personal phones. The container is policy-controlled, connections are authorized per app, and the platform logs them. Run the pattern from the tenant that matches your data. It satisfies the objectives from a GCC or GCC High tenant, and the personal device around the container stays out of the CUI boundary.

Prohibition is a valid answer written as met, not as not applicable.

Blocking mobile devices entirely satisfies the requirement when conditional access, the sign-in rules in your tenant, actually enforces the block. Describe the enforcement in the system security plan. A not-applicable claim asserts the situation cannot arise, which is not true of a policy that a phone can violate.

A phone that holds CUI is a CUI asset.

Management software does not demote it to a lesser asset category. If the device itself stores or processes CUI, it carries a CUI asset's obligations, which is the argument for containing CUI inside managed apps or keeping it off phones entirely.

The requirement names two device classes. Cover both.

Mobile devices are phones and tablets. Mobile computing platforms are laptops. CUI is the controlled unclassified information your contract requires you to protect. Objective [a] is one inventory of everything in either class that processes, stores, or transmits CUI, and [b] is encryption on every entry. The phone-and-tablet list from AC.L2-3.1.18 plus your laptop inventory is the starting point.

Laptops get full-disk encryption with escrowed keys.

BitLocker or FileVault on every in-scope laptop, with recovery keys escrowed, stored centrally through Intune or your directory, covers [b]. It produces its own evidence, because the escrow report is the encryption status list. Run the platform in FIPS mode where the guide's discussion applies, and leave the module validation details to SC.L2-3.13.11. Linux laptops need full-disk encryption chosen at build time, because retrofitting practically means reinstalling. Plan for it rather than discovering it during remediation.

Phones and tablets get container or full-device encryption.

App protection policies encrypt CUI inside managed applications, which is the practical answer for personal devices. Full-device encryption enforced by the device management platform is the alternative for corporate-owned devices. Either way the enforcement policy, exported from the console, is the evidence for [b].

A laptop that never leaves the building is still a mobile computing platform.

The guide's own example encrypts all laptops with the operating system's full-disk encryption. Arguing that a docked laptop is really a desktop invites a finding and saves nothing, because the encryption it would exempt costs nothing to enable.

Devices with no path to CUI are outside this requirement's inventory.

When policy keeps CUI off a class of devices and no access path exists, those devices do not belong on the [a] list. No CUI mailbox, no SharePoint access, and no file sync means no path. You do not have to armor those devices against a spillage that is not your fault. Be ready to demonstrate the absence of the path, because the claim is only as good as its enforcement.

This requirement can never sit on a POA&M.

A POA&M is the plan of action that buys time for unfinished requirements, and 32 CFR 170.21(a)(2)(iii) excludes AC.L2-3.1.20 from Level 2 plans of action. A Not Met here blocks even a Conditional CMMC Status, regardless of your overall score. Treat it as day-one work, not cleanup.

Scope the list to systems that matter, not the whole internet.

Read literally, [a] could mean every connection from every system. Do not take the bait. The list that answers [a] and [b] has two parts. The first is the external services that receive your CUI or FCI. CUI is the controlled unclassified information your contract requires you to protect. FCI is the non-public information the government provides, or you generate for it, under your contract. The second is the connections that allow access back into your environment. Your cloud suite, file transfer services, a managed service provider's (MSP) tooling, and government portals are the usual entries. A dozen well-described entries is a normal answer. Hundreds of websites is a wrong turn that makes every later objective unmanageable.

Verification is recorded trust, per connection.

For [c] and [d], record why each listed system is fit for what you use it for. FedRAMP is the federal cloud authorization program. A cloud service's FedRAMP authorization and package identifier, the contract terms for a partner connection, or the configuration showing only expected devices connect all serve. A policy stating which systems are approved for FCI and CUI, paired against the list, is the verification of use.

Control and limit with the firewall and the policy together.

Objectives [e] and [f] split along the same line: firewall rules and content filtering control the connections, and a policy naming the approved systems and prohibiting all others limits the use. Remote laptops are the leak in this design, because their traffic can bypass the firewall. An always-on VPN or enforced endpoint firewall rules brings them back inside the controls.

Personal devices are external systems.

A personal phone or home computer touching company services is exactly what this requirement governs. Either block them or bring them under defined terms and verification. Conditional access that refuses unmanaged devices is the cleanest enforcement, because it makes the limit self-executing.

External can mean your own other network.

A lab, a commercial business unit, or any system outside the assessment scope is an external system from the enclave's perspective, even though your company owns it. Connections between the enclave and those environments belong on the list with the same verify-and-limit treatment as any vendor.

The scenario is your CUI thumb drive in somebody else's computer.

CUI is the controlled unclassified information your contract requires you to protect. External systems are the ones outside your control: hotel kiosks, personal machines, another company's laptops, and even systems inside your own company that sit outside the CUI boundary. The three objectives ask you to decide whether that use happens at all [a], set the limits [b], and keep to them [c].

Policy and training are the accepted mechanism.

No technical agent of yours runs on an external system, so administrative control is the honest answer: a written rule, training against it, and a signed acknowledgment. The simplest defensible limit is a prohibition: portable storage devices containing CUI are never used on external systems. If you prohibit, [a] and [b] are one sentence each and [c] is the training record.

If you allow it at all, run a check-out process.

Issue company-owned encrypted drives from IT for a named purpose, restrict them to named systems, and log them out and back in. The log is the identification and documentation [a] asks for, and the issuance conditions are the limits under [b].

Encryption does not answer this requirement.

An encrypted drive protects the data if the drive is lost. It does nothing to limit where the drive is used, and an authorized user can still unlock it on a personal machine. Device encryption lives in the Media Protection family. The limit here is about where, and it is behavioral.

This requirement can never sit on a POA&M.

A POA&M is the plan of action that buys time for unfinished requirements, and 32 CFR 170.21(a)(2)(iii) excludes AC.L2-3.1.22 from Level 2 plans of action. A missing review process blocks even a Conditional CMMC Status. The good news is that this is among the cheapest requirements in the family to meet.

An hour of procedure writing covers four of the five objectives.

Name who may post to the website and official social media [a]. Write the procedure that keeps CUI and FCI out of public systems [b]. CUI is the controlled unclassified information your contract requires you to protect. FCI is the non-public information the government provides, or you generate for it, under your contract. Require review before anything is posted [c], and define how improper postings get removed and reported [e]. One page in your media or acceptable use policy is a complete answer, and write it to cover CUI as well as the FCI the objectives name.

Objective [d] needs a recurring review of what is already public.

Pre-posting review alone does not answer it. Review the live site on a defined schedule, and record who reviewed and when. A dated sign-off in a spreadsheet is adequate. An annual review is a defensible floor for a static site. A change-detection alert that triggers review of modified pages is a sound supplement, not a substitute for the pre-posting step.

Company channels are in scope. Personal ones are not.

The company website and official social media accounts get the authorization and review process. Employees' personal accounts are not subject to pre-publication review, and no objective requires monitoring them. An employee posting FCI from a personal account is an incident to handle under [e] and a training matter under AT.L2-3.2.1, not a gap in this requirement.

Generic government awareness training does not satisfy this requirement on its own.

Objectives [b] and [d] are about your policies, standards, and procedures. A stock DoD Cyber Awareness module says nothing about where your CUI (Controlled Unclassified Information) lives, who your security contact is, or which documents govern your system. Use the stock module if you already own it, then add the part that is about your organization.

Objectives [a] and [b] are documents, not training.

Two of the four objectives are satisfied before anyone sits in a session. Write down the security risks tied to your CUI activities. List the policies, standards, and procedures people must follow, and where each one lives. Skip these and you fail [a] and [b] no matter how good the training is.

Attendance records prove delivery, not awareness.

A completion report shows a person opened the module. Pair it with the material itself and with an acknowledgment that names what was covered. A signed acceptable use policy, a signed handbook, a terms of use consent recorded by your identity provider, or an email requiring an affirmative reply all work. An assessor who interviews a user and hears them name the policy and where to find it has evidence for [d].

Serve all three audiences the requirement names.

Managers, system administrators, and users are called out separately in [c] and [d]. Administrators hold the most risk and get the least tailored material. If one deck serves everyone, say how it addresses each audience, or write a short supplement for administrators.

Do not build a learning management system for this.

A slide deck, a sign-in sheet, and a dated acknowledgment cover all four objectives. Three slides are enough if they say where the policies live, who the security contact is, and what the reader is signing. Buy a platform when headcount makes tracking hard, not before.

Repeat it annually.

The objectives say people are made aware. They do not name a frequency. One session at hire is defensible on the text and weak in practice, because policies change and people forget. An annual refresher with a fresh acknowledgment removes the question.

You define what the training is, and certifications are not required.

The requirement leaves the content to you. Vendor courses, conference sessions, a college class, or a written walkthrough of your own procedures all qualify, as long as they match the duty. So do the free modules from CDSE, the Defense Department's Center for Development of Security Excellence. For a small shop with no certified staff, name the vendor course for each system and record when it was completed.

The three objectives are a sequence: define, assign, track.

Objective [a] asks you to write down the security duties each role carries. Objective [b] asks you to tell named people that those duties are theirs. Objective [c] asks you to show they were trained for them. Do them in that order, because [b] and [c] have nothing to point at until [a] exists.

A role list can be three lines.

Person A administers the domain, the firewall, the VPN, and the GCC High tenant, the government cloud version of Microsoft 365. Person B reviews logs and manages backups. Both hold the incident response role. Point each line at the policy, the procedure, and the training material for that duty, and have each person sign that they received them.

General awareness training does not cover this requirement.

AT.L2-3.2.1 covers what every user needs. This requirement covers the duties that only some people hold: administration, log review, incident handling, backup, and physical security. If your only training is the all-hands module, you have no evidence for [c].

Keep the completion evidence simple and dated.

A PDF certificate, an email that says the course is done, a spreadsheet with material, person, and date, or an export from a learning system all work. The objectives ask whether people are trained, not whether a certificate exists. A record that ties a person to a duty, to a piece of training, and to a date is still the fastest way to answer [c].

The free CDSE course carries this requirement.

Insider Threat Awareness, course INT101 from the Center for Development of Security Excellence, is built for exactly this requirement. Assign it, keep the completion record, and most of the work is done. Unlike AT.L2-3.2.1, this requirement has no organization-specific policy component, so generic government training can carry it.

Train on this annually.

The requirement text names no frequency. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, and assessors apply that reading here. A single session at hire earns a Not Met.

Add the reporting path.

The course tells people what an indicator looks like. Your training has to tell them who to report it to in your organization. One slide or one paragraph with the name and the channel is enough, and it is the one part the generic course cannot supply.

Do not agonize over the list of indicators.

The objectives ask that indicators are identified and that people are trained on them. There is no required count. The CDSE list is a fine starting set.

Half of this requirement is writing, not configuration.

Objectives [a], [b], and [e] ask for decisions: which event types you log, what each record contains, and how long you keep records. Objectives [c], [d], and [f] ask for proof the systems match the decisions. Write the event list, the record content, and the retention period into your audit policy or system security plan, the document that describes how your system meets each requirement. Then configure systems to match, because an assessor checks the configuration against the document.

You decide which events are needed, so decide from an established baseline.

Objective [a] says the event types to be logged are specified, and you are the one specifying them. Start from a published audit baseline, such as the DISA STIG settings, the Defense Department's published audit configuration for your operating systems. Remove what you cannot use, and record why. A written selection you can defend beats an exhaustive one you cannot maintain.

Cloud tenant logging covers the tenant, not your endpoints.

If you run Microsoft 365, keep the unified audit log active and retain the Microsoft Entra ID sign-in and audit logs. Together they record account activity across the tenant, your organization's slice of the service. Your laptops and servers still need a Windows audit policy pushed by group policy or your device management tool. The default policy omits event types an investigation will want, such as removable media use.

Define retention in months and prove the platform honors it.

The assessment guide says the retention period must account for the weeks or months between a compromise and its discovery. A 30 day default is not a defensible answer for [e]. Define a retention period of at least a year, write it down, and capture the retention settings that enforce it as evidence for [f]. Where a platform caps retention below your defined period, export the logs to storage you control.

AU.L2-3.3.1 is a five point requirement with no POA&M path.

32 CFR 170.24 assigns it five points. 32 CFR 170.21 keeps a five point requirement off a POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Miss it and you are five points down with no conditional close-out available. Build logging early instead of treating it as cleanup.

Meet this requirement by pointing at work you already did for AU.L2-3.3.1.

Objective [a] asks you to define the record content that ties an action to a person, and [b] asks for records that contain it. When your AU.L2-3.3.1 record content already includes a user identifier, a time stamp, a source address, the action, and the outcome, name those fields as your traceability content. Show sample records. There is no separate logging system to build.

Shared accounts are how this requirement fails.

A record that names admin or scanner traces to no individual. Give every person a named account, and keep privileged accounts personal. Where a service account cannot be eliminated, restrict who can use it and log the use so a person can still be identified.

Evidence is a configuration plus a sample.

Show how the audit system is configured to capture user identity, then pull a sample record and point to the identity field. A policy that lists the required fields without records demonstrating them leaves [b] unproven.

In a cloud tenant the identity is already in every record.

The Microsoft 365 unified audit log and the Microsoft Entra ID sign-in log stamp each entry with the acting account. Your work is the mapping from account to person: one account per person, no sharing, and a record of who holds each privileged account.

This requirement is about the list of events you log, not about reading logs.

The assessment guide states that review of the audit records themselves belongs to AU.L2-3.3.5 and AU.L2-3.3.6. Here you review the logging configuration: whether the event types you chose under AU.L2-3.3.1 still cover your needs. Bring log review records to this requirement and you have answered a different question.

Define the trigger for the review in writing.

Objective [a] asks for a process that says when the review happens. Name a cadence and the events that force an early review: at least annually, after a security incident, and after a major system change. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, and an open ended cadence gives an assessor nothing to verify.

Hold the review and keep the artifact even when nothing changes.

Objective [b] wants evidence the process ran. Meeting minutes, a ticket, or a dated one page review all work. A review that concludes the current event set is sufficient still satisfies [b] when the conclusion is recorded.

The strongest evidence for [c] is one real change.

A change ticket that adds an event type after a review, such as enabling failed logon events or removable media logging once a gap surfaced, shows the loop closes. If an incident revealed activity you were not logging, the update you made afterward is exactly what [c] describes.

Fixed cloud logging does not make this requirement not applicable.

When a service such as Microsoft 365 controls what its audit log collects, review whether the collected set meets your needs and record the conclusion. Supplement with endpoint or network logging where it does not. Claiming N/A because you cannot change the vendor's event set earns a Not Met, because the review process is yours no matter who owns the settings.

An alert is something that arrives without anyone asking.

Objective [c] is met by a notification that reaches a named person or role on its own: an email, a text, a ticket. A procedure where someone checks whether logs arrived is monitoring, not alerting, and it fails the moment nobody checks.

The requirement has three parts, and the technical alert is only one of them.

Name who gets alerted for [a], write down which failure types generate an alert for [b], and prove delivery works for [c]. An alert rule with no documented recipient and no defined failure list covers one objective out of three.

Define failure as logs stopping, plus storage filling.

A log source that sends nothing for a defined window has failed, whatever the cause. Add capacity alerts as well, because the assessment guide names audit record storage capacity being reached as a failure type. A rule that fires when a source goes quiet and a rule that fires when the log store nears its limit cover the defined types.

Match the alert window to the device's duty cycle.

A firewall or server that goes silent for an hour is an incident. A laptop that goes silent over a weekend is a weekend. Set per source alerts for systems that run around the clock, and a multi-day reporting threshold for endpoints that power off. Write the distinction into your failure type definitions.

For SaaS platforms, the platform's internal logging is the provider's to keep running and yours to verify.

The audit logging Microsoft 365 performs inside the service is the provider's responsibility under FedRAMP, the federal cloud authorization program. Do not assume it. Obtain the provider's customer responsibility matrix, the document that splits security duties between the provider and you, and cite where it covers audit process failure. Alert on the parts you still own, such as the connector that pulls tenant logs into your own log store.

Correlate means the logs, the review, and the response work as one system.

Objective [a] asks you to define review, analysis, and reporting processes aimed at suspicious activity, and [b] asks that they connect instead of running independently. Cover both readings of connect. Collect logs into one place so events from different systems can be compared. Write the procedure that turns a suspicious finding into an incident under your incident response plan.

Central collection is what makes correlation demonstrable.

When tenant logs, endpoint logs, and firewall logs land in one log workspace, correlation is a query across sources. The assessment guide accepts manual correlation with well defined and managed procedures for small companies. A documented recurring review that compares sources also works. It is just harder to demonstrate than a query.

A year of zero findings undermines you.

A review process that never escalates anything looks like a process that does not run. Record triage outcomes even when they are benign: the sign-in alert that turned out to be a traveling employee is evidence the pipeline from log to review to decision works.

AU.L2-3.3.5 is a five point requirement with no POA&M path.

32 CFR 170.24 assigns it five points. 32 CFR 170.21 keeps a five point requirement off a POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Treat the link between logging and response as day one work.

Reduction is filtering, and a query interface is a reduction capability.

Objective [a] does not demand an analytics platform. It asks that a person can turn a mass of raw records into a focused view when needed. The search in your cloud audit portal, a log workspace query, or a script over exported logs each qualify when they reach the log sources you defined under AU.L2-3.3.1.

A report is a saved, shareable answer.

Objective [b] is met when you can produce output someone else can read: exported query results, a scheduled summary, a filtered view saved to a file. Prepare a few canned questions, such as everything one account did in a day, and be ready to run them live, because on demand includes during the assessment.

Keep CUI out of the logging pipeline.

Logs are metadata: who, what, when, outcome. Configure logging so file contents never land in a record. A log platform that ingests CUI, the controlled unclassified information you protect, pulls itself into your CUI scope. A platform kept clean of CUI protects the environment without expanding it.

Specify one authoritative time source and point everything at it.

Objective [b] says an authoritative source, singular. Systems split across unrelated time sources invite the question of whether their logs can be compared. Name the source in your system security plan, the document that describes how your system meets each requirement. Where a device cannot use it, record the deviation and show the clocks still agree.

Most of this already works. The job is naming it and proving it.

Domain joined Windows machines sync through the domain hierarchy, and cloud platforms sync their own infrastructure. Network gear takes an NTP setting, the standard network time protocol. Objective [c] wants the comparing and synchronizing shown, so capture the time service status from a server and the NTP configuration page from your firewall.

You cannot set the clock on a cloud service, so document it instead.

A provider's platform clocks are outside your control. Record in the system security plan that the provider synchronizes its own infrastructure. Review logs in UTC, coordinated universal time, so records from different systems line up without time zone arithmetic during an investigation.

Access control carries all six objectives.

Restrict who can read audit information for [a] and who can open the tools for [d]. Grant nobody modification rights for [b] and [e]. Confine deletion to the few who manage retention for [c] and [f]. The evidence is a role definition plus the list of people who hold the role.

Forward logs off the systems that generate them.

An administrator whose actions are being logged can clear a local log. A copy that ships to a central store as events occur means clearing the local log destroys nothing, and the clearing itself becomes an event in the central copy.

The tools and settings are protected, not just the data.

Objectives [d], [e], and [f] cover the audit configuration and tooling. Restrict who can change audit policy, who can reconfigure log collection, and who can administer the log platform. Keep that list aligned with the subset you define under AU.L2-3.3.9.

In a cloud tenant this is a role review.

List which directory roles can read, export, or purge audit data, and cut the list to the people who need it. Protect exported log archives with the same restraint, because an export anyone can read undoes [a] no matter how tight the portal is.

Define the subset in writing even when it is everyone in IT.

Objective [a] asks for a defined subset of privileged users who manage audit logging. In a two admin shop where both need coverage, both go on the list. What fails is not a small subset. It is the absence of a definition.

Separate audit management from general administration where headcount allows.

An administrator who is the subject of the logs and also controls them can hide their own tracks. Give routine administrators no rights over audit settings and put log management in fewer hands. In a cloud tenant, use a dedicated role for log management instead of handing out global administration.

When the same people must hold both, have them watch each other.

With one or two administrators, have them review each other's activity during log review and record that they did. The mutual review compensates for the separation you cannot achieve, and the record shows you saw the risk and addressed it.

A baseline says what a machine should be, not what it happens to be.

Exporting the current configuration of a workstation is a backup, not a baseline. Write down the operating system edition and version, the standard software with version minimums, and the security-relevant settings you have decided on, then compare machines against that document. Objective [a] asks for the decided state, and the comparison is how you maintain it under [c].

This requirement produces two artifacts, and the objectives split evenly between them.

Objectives [a] through [c] are the baseline configuration. [d] through [f] are the system inventory. Both must cover hardware, software, firmware, and documentation under [b] and [e]. Software and documentation are the two categories that get skipped: list the software on the machines, not just the machines, and point each hardware and software entry at its vendor documentation.

A spreadsheet is a compliant inventory for a small company.

Nothing in the objectives asks for an asset management platform. A spreadsheet with manufacturer, model, serial number, location, assigned owner, installed software, and firmware versions satisfies [d] and [e]. Buy tooling when the row count makes manual upkeep fail, not before.

Enforce the baseline with whatever pushes settings. The document is what the requirement asks for.

Group Policy, Intune, a standard image, or a written build procedure all work as the mechanism, and no tool is required by name. The test is two questions. Are assets of the same type configured the same? Can you produce the document that says how they are supposed to be configured? A tenant full of Intune policies with no written baseline fails the first half of that test.

Standardize before you document.

Every operating system, hardware brand, and one-off appliance you keep is another baseline to write and maintain. Fewer platforms means fewer baselines, and that is the biggest reduction in effort available under this requirement.

Maintained means reviewed on a schedule and updated on change.

Objectives [c] and [f] fail when the documents go stale. Update the baseline when your change process approves a change to it. Update the inventory when hardware or software enters or leaves. Put a recurring review on the calendar to catch what slipped through.

Finish this before assessment, because it cannot wait on a plan of action and milestones.

A plan of action and milestones is the corrective plan that lets certain gaps be closed after assessment. CM.L2-3.4.1 is a five-point basic security requirement under the scoring methodology in 32 CFR 170.24. Under 32 CFR 170.21, a Conditional status plan may only include requirements worth one point, with a single named exception that is not this one. A missing baseline or inventory is a five-point deduction with no deferral path.

Start from a published benchmark and remove what you do not need. Do not write settings from scratch.

The CIS Benchmarks and the DoD STIGs are published lists of recommended security settings, so you do not have to invent a hardening standard. Define your settings as the benchmark minus approved exceptions, document each exception with its reason, and objective [a] becomes a short document instead of a long one.

The tool that enforces the settings is not the document that establishes them.

Intune compliance policies, the settings catalog, and Group Policy Objects are enforcement under [b]. Objective [a] still needs a written statement of what the settings are supposed to be. A setting that exists only inside the tool cannot be compared against anything. Keep the written baseline and audit the tenant against it.

Every open port and every deviation gets a recorded reason.

A config line does not say why it exists or whether it is security relevant. Keep a firewall rules list with the business justification for each rule and the ticket or approval that created it. Record the rationale for each benchmark deviation. When someone asks in two years why a port is open, that comment is the only answer that exists.

Prove enforcement on samples, not with promises.

Objective [b] is tested against running systems. The Windows Resultant Set of Policy report from sampled machines shows the settings actually applied. Intune compliance reports do the same, and so does a SCAP scan, an automated check of a machine against your chosen benchmark. Pick whichever your stack produces. The requirement does not name a tool, and compliance scanning is not itself required.

Do not write baselines for software that cannot be configured.

Applications bundled with the operating system inherit its settings, and a suite needs one baseline, not one per app. Spend the effort on products with security settings worth controlling: operating systems, browsers, firewalls, and anything that touches CUI, the controlled unclassified information your contract requires you to protect.

One change record can carry all four objectives.

Tracked [a], reviewed [b], approved or disapproved [c], and logged [d] can all live in one change record: what changed, on which system, who proposed it, who reviewed it, the decision, the date, and the result. A ticket system does this. So does a spreadsheet.

Size the process to the headcount.

A three-person shop meets this with a standing meeting. The technical person presents proposed changes, the others hear the justification, and the log records date, attendees, decision, and security impact. A change advisory board is one way to do [b] and [c], not the requirement.

Tier your changes so the process survives contact with reality.

Routine patching and like-for-like replacements can be pre-approved as standard changes and reported in a periodic digest that the approver reviews. Significant changes go through review before implementation. Write the tiers into the procedure so an assessor sees a decision, not an omission.

Emergency changes are fixed first and approved after, when the procedure says so.

Define what counts as an emergency, who may act, and where the action is logged. A troubleshooting change recorded in the ticket that prompted it satisfies [d]. A fix that lives only in an administrator's memory fails [a] and [d].

The one-admin company still reviews.

When the person proposing the change is the only one who can evaluate it technically, the review is about need and impact, not code inspection. Have the owner or a manager hear the justification and record the approval. That satisfies [b] and [c] and creates a second set of eyes the objectives imply.

One field on the change record meets the single objective.

Objective [a] asks that security impact is analyzed before implementation. Add a security impact section to the CM.L2-3.4.3 change record that answers three questions. Does the change alter or create security configuration settings? Does it affect how CUI, controlled unclassified information, is protected? Does documentation need updating? A sentence or two per change is a real analysis.

The analyst needs enough knowledge to answer, not a title.

Whoever can weigh the change against the baseline and the system security plan, the document that describes how your system meets each requirement, performs the analysis. In a small company that is the administrator proposing the change plus whoever approves it. Record the conclusion, even when the conclusion is no impact.

Auto-update stays on. Feature updates wait.

Security patches remediate flaws and can flow automatically under a pre-approved standard change. Feature updates add functionality that deserves analysis before it lands. Defer feature updates with whatever your stack provides, such as Windows Update rings in Intune or Group Policy. Use the deferral window to read what is changing before it arrives.

Do the analysis before, not as archaeology after.

An analysis reconstructed at assessment time is visible as such. The dated impact field on the change record, filled in before the implementation date, is the evidence [a] asks for.

This requirement restricts who can make changes, not how changes are approved.

CM.L2-3.4.3 governs the change process. This one asks who can physically reach the equipment and who holds credentials that can alter it. The eight objectives are a grid: physical restrictions in [a] through [d] and logical restrictions in [e] through [h], each defined, documented, approved, and enforced.

Logical restriction is the short list of people with administrative rights.

Name the people authorized to change systems, give only them administrative credentials, and keep everyone else a standard user. Put the named list in the system security plan, the document that describes how your system meets each requirement, or in a procedure. That covers [e] and [f]. A manager's sign-off on the list covers [g], and the directory enforcing it covers [h].

Physical restriction is a locked room and a list of key holders.

Servers and network gear live behind a locked door, and you can name who holds the key or badge. That covers [a] through [d] for a small office. Badge logs where they exist. A documented key list and a sign-in sheet where they do not.

Let the change management process carry this when it names the restrictions.

State three things in the system security plan: changes follow the CM.L2-3.4.3 process, systems sit in access-controlled rooms, and only named administrators hold change credentials. That answers all eight objectives without a separate program.

Fully remote companies answer the physical half through inheritance and policy.

Infrastructure in a FedRAMP-authorized cloud, one the federal government has assessed and approved, inherits the provider's physical controls. Document the inheritance. Home offices are covered by a remote work policy: a locked door, the screen positioned against shoulder surfing, the laptop secured when not in use.

Define essential first, or nothing else in this requirement works.

Objective [a] asks what each system needs to do for its role: workstations edit documents and handle email, the file server serves files. Write those definitions down. Objective [b] is the configuration work of disabling what falls outside them.

The justification column turns your software inventory into evidence.

Add a column to the CM.L2-3.4.1 inventory stating why each application is present. Software with no reason gets removed. That one artifact answers [a] for software and shows the review behind [b].

Provisioning is where least functionality happens.

IT builds the machine from the baseline, strips what the role does not need, and delivers it. State that in the system security plan, the document that describes how your system meets each requirement. Name the tools that enforce it, such as Group Policy, Intune, or AppLocker. Do not paste every setting into the plan. The plan references the baseline, and the baseline holds the detail.

Factory defaults are your responsibility the moment the device is yours.

Preinstalled vendor utilities, trial software, and default-enabled services do not become acceptable by arriving preinstalled. Keep what has a documented purpose, such as a recovery tool, and remove the rest.

Combining roles on one server is allowed. Document what it does and disable what it does not.

A small company running DNS and domain services on one box is within the requirement, provided the combined role is defined and the unused capabilities are off. Keep high-exposure roles, especially anything internet-facing, on their own component where feasible.

Fifteen objectives collapse into three lists.

Programs are [a] through [c], functions are [d] through [f], and ports, protocols, and services are [g] through [o]. Treat ports, protocols, and services as one combined list, because a firewall rule that blocks a port blocks the protocol and the service behind it.

Classify in three tiers and the definitions write themselves.

Essential is what your requirements and business functions need. Restricted is allowed only through an approved, documented rule where everything else is blocked by default. Prohibited is the known-insecure set blocked outright, such as FTP, Telnet, and SMBv1, so that no future rule allows them by accident.

Defining nonessential as everything outside the essential list is a legitimate definition.

Objectives [b], [e], [h], [k], and [n] ask that nonessential use is defined. State in the procedure that anything outside the essential definitions is nonessential and is blocked, disabled, or removed on discovery. That sentence satisfies the definition objectives without an impossible enumeration.

Do not classify a hundred Windows services one by one.

Define essential at the level you control: the roles a machine serves, the applications on the approved list, the ports the firewall permits. Operating system services that support those roles are covered by the baseline, and the ones your CM.L2-3.4.2 benchmark says to disable get disabled there.

Functions are capabilities you can switch off, and naming a few is enough.

Reading, editing, and saving project documents is essential. Bluetooth file transfer, games, and music streaming are nonessential functions you restrict. The objectives ask for definitions and enforcement, not an exhaustive taxonomy.

One rules list serves this requirement and CM.L2-3.4.2.

The firewall export with a business justification per rule evidences established configuration settings there and essential port definitions here. Build it once and reference it from both.

Pick a policy, name it in writing, and the choice itself is objective [a].

The requirement accepts either deny-by-exception or deny-all, permit-by-exception. Objective [a] wants the written policy naming which one you run, [b] wants the list of software it governs, and [c] wants the mechanism enforcing it as specified.

Deny-by-exception is compliant under this requirement as written.

The requirement text offers it as an option, and a written deny list enforced by your endpoint tooling satisfies all three objectives. Populate the list deliberately: end-of-life software, unapproved remote access and VPN clients, keyloggers, games, alternatives to tools you have standardized, and products prohibited in federal contracting. Then use the CM.L2-3.4.1 software inventory to confirm nothing on the list is installed.

Allowlisting is the stronger policy, and the operating system already ships the tooling.

AppLocker and App Control for Business enforce permit-by-exception on Windows. Start by allowing digitally signed software from your approved publishers. Run in audit mode until you understand the noise. Then enforce, and extend the policy to scripts and libraries as you mature.

The installed-software inventory is not an allowlist.

When the list of allowed software is whatever is currently installed, anything anyone installs becomes authorized the moment it lands. The list under [b] is decided in advance. The inventory is what you reconcile against it.

This requirement governs execution. CM.L2-3.4.9 governs installation.

Blocking a program from running and controlling who installs software are separate requirements with separate evidence. An execution policy covers the first. Installation rights and monitoring cover the second, and the software inventory from CM.L2-3.4.1 feeds both.

The three objectives are a policy, a control, and a monitor, and removing admin rights is only the middle one.

Objective [a] wants a written policy on software installation by users, [b] wants the control that enforces it, and [c] wants monitoring that would catch what slipped through. Standard users without local administrator rights satisfy [b] and nothing else.

Monitoring is required even when installation is impossible.

The question to answer is how you know users installed nothing if you never look. A recurring software inventory report compared against the approved software list answers it, and an empty result is itself the evidence of monitoring under [c].

Reconcile discoveries against change control.

New software found by the inventory tool is either matched to an approval or investigated. Document what happens when unauthorized software appears: who investigates, how it is removed, and where the outcome is recorded.

Developers with local admin are a policy decision, not a violation.

Grant the exception in the policy. Source tools from controlled repositories where you can. Commit to tighter monitoring, with retroactive approval through change control for what gets added. Keep that arrangement off general-user machines, because a compromised developer endpoint is the worst place to find surprise software.

Three populations need identifiers: people, service accounts, and devices.

Objective [a] is every human user, [b] is processes acting on behalf of users, and [c] is devices. Your directory, the account system such as Active Directory or Microsoft Entra ID, covers [a] the day you stand it up. Objectives [b] and [c] are where the deliberate work lives.

A process acting on behalf of a user is a service account, not an application a person runs.

Word running under a signed-in user is that user's process and needs no identifier of its own. The backup job, the scanner uploading to a document library, and the integration service principal in Microsoft Entra ID are accounts that are not people but act like people. List each one with its purpose and owner, and [b] is met.

Ignore the operating system's built-in service identities.

SYSTEM, Local Service, Network Service, and TrustedInstaller are internal Windows machinery. If you document them at all, one line calling them native operating system accounts necessary for system function is enough.

Devices get identified by whatever your management stack already assigns.

Intune assigns each enrolled device its own device identifier. For equipment outside management, define the method in a procedure: MAC address, asset tag, or hostname convention. Objective [c] asks that a method exists and is applied, not that it be sophisticated.

Shared accounts survive this requirement only with traceability bolted on.

The assessment guide states that management of individual identifiers is not applicable to shared system accounts, but an account no one can trace to a person undermines everything downstream. Where a shared account is unavoidable, put its credential in a vault that logs who checked it out and rotates it after use.

Nothing gets access before proving what it is.

Users [a], processes acting on behalf of users [b], and devices [c] each authenticate before the system lets them in. For users and service accounts a modern directory does this by default. Your work is confirming that no path around it exists.

Hunt down default credentials before an assessor does.

Network gear, printers, cameras, and appliances ship with published usernames and passwords, and those credentials are easily found in a search. Change them at deployment, and put that step in the provisioning procedure so the practice is documented rather than remembered.

Devices authenticate through domain join or enrollment. Verification covers the fixed fleet.

The requirement says authenticated or verified. Devices joined to the domain or enrolled in Intune attest their identity when they connect, which satisfies [c]. A small office can verify instead, but the verification has to happen before access. Pair a maintained inventory of known devices with a gate that admits only inventoried devices, at fixed locations in a controlled area. Remote devices get real authentication, because no one can walk over and verify them.

Service accounts authenticate too, and the record of them is what you show.

A script or integration signs in with a credential, a certificate, or a token. Keep the IA.L2-3.5.1 service account list annotated with how each one authenticates. That record answers [b] and pays for itself again during log review and incident response.

Cloud-only does not remove the endpoints.

CUI (Controlled Unclassified Information) comes down from the cloud onto laptops for editing, printing, and building new documents. Those endpoints and their users authenticate like everything else. Moving the data to the cloud moves none of this requirement away.

Network access includes your office LAN. Get the definitions right before you scope anything.

The assessment guide defines local access as access obtained by direct connection without the use of networks, and network access as access obtained through network connections. A user signing into a domain workstation at a desk is network access. MFA (multifactor authentication) on the VPN and on Microsoft 365 while plain passwords open everything on the internal network is the classic failure of objective [d].

Objective [a] is a list you write before touching any technology.

Identify every privileged account: domain and Microsoft Entra ID administrator roles, firewall and switch administration, hypervisor and backup consoles, and your managed service provider's accounts in your environment. Privileged accounts then need MFA everywhere, including local access under [b]. Non-privileged accounts need it for network access under [d].

Factors are something you know, have, or are. Device attributes are not factors.

A compliant device, an allowed IP range, a MAC address, or a location is a policy condition, not a second factor. An authenticator app, a FIDO2 key, a smart card, or a time-based code is. Conditional Access policies in Microsoft Entra ID enforce MFA. They are not themselves MFA.

Password fallback quietly deletes your MFA.

Windows Hello for Business with a TPM (the trusted platform module chip) plus PIN or biometric is a defensible two-factor implementation, but only when enforced. If a user can pick other sign-in options and get in with just the password, the control is optional, and demonstrating your sign-in flow is a standard assessment step. Enforce the strong path and be ready to show both factors in use.

Local access to privileged accounts is the objective people forget.

Objective [b] covers the administrator at the console. An OS-level MFA agent on servers and admin workstations covers it directly. Vaulted credentials cover it another way. When the local administrator password sits in LAPS, Microsoft's Local Administrator Password Solution, or in a privileged access vault that itself demands MFA, retrieving the credential requires the second factor.

Phones do not need MFA to unlock. They need it to reach your systems.

The assessment guide states that multifactor authentication is not required for access to mobile devices such as smartphones or tablets. The session the phone opens to your email or files is network access to your system and prompts like any other client.

The scoring rule gives partial credit here and removes the deferral path.

32 CFR 170.24 subtracts three points when MFA covers only remote and privileged users, and five when it covers no one. This is one of only two Level 2 requirements scored with partial credit. A plan of action and milestones is the documented list of gaps you commit to close after assessment. Because the value exceeds one point either way, 32 CFR 170.21 keeps IA.L2-3.5.3 off a Conditional status plan. Finish it before assessment.

A current Windows and TLS stack already resists replay. Your job is turning off the parts that do not.

A replay attack captures sign-in traffic and sends it again to impersonate the original user. Kerberos, the sign-in protocol inside Windows domains, TLS on web applications, and time-based MFA codes all resist replay by design. Set NTLMv2 as the minimum authentication level, disable SMBv1, and retire services that still authenticate over cleartext protocols. The single objective [a] is then covered for privileged and non-privileged accounts alike.

Evidence is configuration, not packet captures.

Show the Group Policy or directory settings enforcing Kerberos and the NTLMv2 minimum, the TLS configuration on web services, and the MFA solution rejecting reused codes. The configuration itself is the demonstration. A packet capture adds nothing an assessor needs.

Your MFA deployment is doing double duty here.

The time-synchronous and challenge-response one-time mechanisms deployed for IA.L2-3.5.3 are exactly the replay-resistant techniques the requirement's discussion names. Where MFA covers network access, this requirement rides along with it.

Pick a period, write it down, and the hard half is done.

Objective [a] is satisfied by a sentence in your identifier policy: usernames and device identifiers are not reassigned to a different person or device for a defined period. A two-year period is a defensible choice. Objective [b] is whatever mechanism makes that sentence true.

Never deleting accounts is the cheapest prevention.

Disable departed users and keep the objects: a disabled-users organizational unit on premises, sign-in-blocked accounts in Microsoft Entra ID. While the object exists, the directory itself refuses to issue that identifier again, which enforces [b] with no extra machinery.

The same person can come back to the same identifier.

The assessment guide's discussion says preventing reuse means preventing previously used identifiers from going to different individuals, groups, roles, or devices. A rehired employee reclaiming their old username is not the risk this requirement targets. Write the allowance into the policy and reactivate the account.

Do not invent an obfuscation program.

Nothing here requires usernames that differ from email addresses or anonymized account names. Matching the sign-in name, the user principal name, to the mailbox is fine. The requirement is only that identifiers are not recycled onto someone new.

Define the inactivity window and make something actually enforce it.

Objective [a] is a number in your policy. The assessment guide's worked example uses 45 days. Objective [b] is the mechanism: a scheduled report of last sign-in dates with a documented disable step, or an automation that disables at the threshold.

Disabled is not deleted, and this requirement is why.

Disabling ends the risk of an unwatched active account while preserving the object, which also carries the identifier reuse prevention in IA.L2-3.5.5. Disable at the inactivity threshold. Delete on your own schedule or never.

Scope it to user accounts.

Computer objects, key cards, and every other identifier-bearing thing invite scope creep. Define the requirement's reach as user identifiers, and handle service accounts by deliberate review rather than automatic disabling, because an auto-disabled backup account is an outage. Write the definition into the procedure.

Plan the leave-of-absence path before it happens.

Extended leave trips any inactivity threshold. Suspend the account, keep the device on inventory, and re-enable through a defined step when the person returns. A documented exception process keeps [b] enforced without punishing parental leave.

This requirement asks for composition rules, so define composition rules.

Current NIST password guidance in SP 800-63B moved away from complexity requirements, but the requirement text and objectives here have not. Objectives [a] and [c] are defined and enforced complexity. [b] and [d] are defined and enforced change of characters. You are assessed against this text, not against the newer guidance, so meet the text in front of you.

You set the minimums, so set ones you can defend.

The objectives leave the numbers to you. A minimum length of twelve or more characters with three of the four character types is defensible and enforceable in Active Directory and Microsoft Entra ID. Choosing a longer minimum and citing the evolution of password guidance as the reason is equally defensible. Choosing eight characters is enforceable but weak.

Change of characters is the pair of objectives that gets missed. Define it even though enforcement is thin.

Objectives [b] and [d] want a rule about characters changing when a password changes, and mainstream platforms do not count changed characters natively. Define a minimum of at least one changed character, and enforce it through the platform's password history setting, which blocks the fully identical case. State that implementation in your system security plan, the document that describes how your system meets each requirement.

No objective requires password expiration.

Nothing in [a] through [d] mentions a maximum password age. Long passwords that never expire, paired with the MFA this family already requires, are consistent with every objective here. If you keep expiration, keep it as your own policy choice, not because this requirement demands it.

Specify the number of generations and let the directory enforce it.

Objective [a] is one number in the password policy. Twenty-four remembered passwords matches the Windows security baseline, and the matching password history setting in Group Policy or your directory satisfies [b] with a single control.

Temporary passwords are exempt by the requirement's own discussion.

The assessment guide states that password lifetime restrictions do not apply to temporary passwords, so the one-time credential a help desk issues under IA.L2-3.5.9 does not enter the generation count.

Document what each platform can enforce.

Where a system exposes a configurable history depth, set your specified number there. Where one does not, state the platform's actual reuse behavior in the policy and rely on it. The objectives ask that the number is specified and reuse prohibited, not that every product expose the same setting.

One checkbox meets the objective where directories are involved.

Requiring a password change at next sign-in is the entire technical implementation of [a] in Active Directory and Microsoft Entra ID. Set it on every account created or reset with a temporary password. Make it a step in the account creation and reset procedures so it is never optional.

Where the platform cannot force the change, procedure plus justification carries it.

Some local accounts and some virtual desktop first-logon flows cannot enforce a change at first use. Document why the enforcement is unavailable and the instruction users follow instead. An explained gap with a procedure reads as an implementation. An unexplained one reads as a miss.

Make the temporary password worthless after first use.

Generate it randomly per user instead of a predictable house pattern, deliver it through a separate channel, and expire it if it goes unused. The new permanent password then has to meet the IA.L2-3.5.7 rules, which is the point of forcing the change immediately.

Storage means hashed or encrypted, transit means encrypted, everywhere a password lives or moves.

Hashing converts a password into a one-way code that cannot be turned back into the password. Objective [a] covers everything holding passwords: the directory database, application credential stores, the password vault. Objective [b] covers every path a credential travels: sign-in pages, directory binds, service authentications. A modern Windows domain hashes what it stores and encrypts what Kerberos carries, so the work is finding the exceptions.

Kill the cleartext paths by name.

LDAP simple binds on port 389, HTTP sign-in forms, FTP and Telnet carrying credentials, and SMTP authentication without TLS all transmit passwords unprotected. Move LDAP integrations to LDAPS, require TLS on every authentication endpoint, and keep reversible encryption disabled in the domain, because that one setting stores passwords recoverably.

FIPS validation is not in these objectives.

Objectives [a] and [b] ask for cryptographic protection, not FIPS-validated modules. FIPS-validated encryption belongs to SC.L2-3.13.11, which 32 CFR 170.24 ties to protecting the confidentiality of CUI. Do not import that burden into this requirement.

A company-deployed password manager is compliant and in scope.

A vault that encrypts at rest and serves credentials over TLS satisfies both objectives for the passwords it holds. Reversible encryption inside a vault is its design, not a violation. Deploy one deliberately: it displaces the browser-saved passwords and personal accounts that are the shadow alternative. Because it holds the credentials that unlock your environment, it is a security protection asset you account for in scoping.

The passwords spreadsheet fails storage in the plainest way.

Shared spreadsheets of credentials, text files on desktops, and passwords saved in unmanaged browsers are unprotected storage under [a]. The fix is the vault from the previous lesson plus a policy line prohibiting the rest.

Five points ride on this requirement.

32 CFR 170.24 lists IA.L2-3.5.10 among the five-point derived security requirements. 32 CFR 170.21 keeps requirements worth more than one point off a Conditional status plan of action and milestones, the documented list of gaps you commit to close after assessment. The rule names a single exception, and it is not this one. Cleartext credential paths are cheap to find and expensive to leave.

Every mainstream sign-in screen already obscures input. Your work is inventory, not engineering.

Masked password fields on the operating system, in browsers, on network gear consoles, and in your single sign-on portal satisfy objective [a] out of the box. Collect a screenshot per system type and pair the set with one policy sentence stating that authentication feedback is obscured.

The reveal-password control and brief character display do not fail you.

The assessment guide accepts displaying feedback for a very limited time before fully obscuring it, which is what mobile keyboards and the reveal control do. Cover the residue with a procedure line telling users not to reveal passwords within view of others, because a procedure reaches the applications no setting can.

Do not build controls to disable what vendors ship enabled.

Disabling the reveal button through policy is available if you want it, but it is not needed to meet [a], and it trades a compliance nothing for extra lockouts. Spend the effort on requirements with objectives still unmet.

An incident response plan plus the security tools you already run is the capability. A security operations center is not.

Objective [a] asks whether an operational capability exists, not whether anyone watches a screen around the clock. A written incident response plan, an endpoint protection tool that raises alerts, a named reporting channel, and people who know their roles establish the capability. Buy monitoring services when your risk justifies them, not because this requirement demands them.

Write the plan around the six activities the objectives name.

Objectives [b] through [g] each check one phase: preparation, detection, analysis, containment, recovery, and user response. Give each phase its own section that says who acts and what they do. An assessor walks the letters in order, and a plan organized the same way answers each one directly.

Preparation is a short list of concrete artifacts.

Preparation needs four things. List the people inside and outside the organization you would call. Name a reporting channel, such as an email address or phone number. Set up a way to track incidents from open to closed, and a place to store evidence. Those four items carry [b], and none of them requires new tooling. Detection and analysis then run on what you already have. Antivirus and endpoint alerts, log entries that raise concern, and user reports are the sources for [c]. Analysis under [d] means someone compares what they see against normal operations and writes down what happened, including the associated log entries.

User response means every user knows how to recognize and report an incident, and responders know their parts.

Objective [g] is about people. Ordinary users need to know what looks suspicious and who to call. Administrators need the containment and recovery steps for the systems they run. Put the reporting path in your awareness training under AT.L2-3.2.1, and the responder duties in role-based training under AT.L2-3.2.2. Objective [g] then falls out of training you already owe.

Build your DFARS reporting duties into preparation without mistaking them for this requirement's objectives.

DFARS 252.204-7012, the safeguarding clause in your DoD contracts, sets a 72-hour clock. It covers a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to provide operationally critical support. The report goes to DoD within 72 hours of discovery. It also requires preserving images and logs for at least 90 days from submission of the report. None of the seven objectives here measures that clause. Incident reporting has its own requirement, IR.L2-3.6.2, and the 72-hour clock stays a contract obligation either way. Put the DoD reporting steps, the address of DIBNET, DoD's incident reporting portal, and the preservation duty into the plan now. The 72-hour clock is not the time to learn them.

A stolen laptop with CUI on it is an incident.

The capability covers physical loss and theft of equipment holding CUI, Controlled Unclassified Information, not just network intrusions. Cover it in the same plan or in a separate physical loss procedure. Either way, both paths exist and name their owners.

The six objectives are three pairs: record, identify, notify.

Objectives [a] and [b] ask for a record of incidents. Objectives [c] and [d] ask you to name the external authorities and internal officials who get told. Objectives [e] and [f] ask for evidence that the identified parties actually hear about incidents when they occur. Build the requirement in that order.

Tracking is a log. Documentation is the story of each incident.

A ticket system or a spreadsheet with an entry per incident, its status, and its dates satisfies [a] at any size. Documentation under [b] is the fuller record: what was observed, which systems were involved, what was done, and when it closed. Keep both, because the log across time is how you spot a repeat problem.

Define what you report externally before an incident forces the question.

Write a reportable incident definition into your plan: which events require notification outside the organization and which stay internal. Anchor the external threshold to DFARS 252.204-7012, the safeguarding clause in your DoD contracts. It covers a cyber incident that affects a covered contractor information system, the covered defense information on it, or your ability to provide operationally critical support. Reports go to DoD within 72 hours of discovery. A definition on paper turns a 2 a.m. judgement call into a lookup.

Not every malware detection is a reportable cyber incident.

Malware that your endpoint protection blocked and quarantined before it touched CUI, the Controlled Unclassified Information you protect, did not adversely affect the system. Record the detection, judge it against your written definition, and keep the determination with the ticket. The record of a considered decision is [a] and [b] working as intended.

Name the authorities and the officials now, and secure the access to reach them.

For DoD work the external report goes through DIBNET, DoD's incident reporting portal at dibnet.dod.mil. Submitting one requires a DoD-approved medium assurance certificate, a purchased identity credential that takes longer to obtain than the 72 hours you would have. Get the certificate before you need it. Internally, name the roles that hear about an incident: the owner, the program lead, whoever calls the prime contractor above you. Put names against the roles in the plan. That covers [c] and [d].

A clean history is documented, not assumed.

When no incident has met your reporting threshold, keep the tracking log anyway. Record a dated statement that no incidents have required external notification since your system security plan, the document that says how each requirement is met, took effect. Keep the thresholds themselves alongside it. Objectives [e] and [f] are then evidenced by the working procedure and the empty log, and an assessor can follow the path a real incident would take.

A tabletop exercise once a year carries this requirement.

Gather the people named in the incident response plan, walk a realistic scenario end to end, and take notes. The requirement text sets no frequency, but a test with no recurrence goes stale as systems and people change. A plan that exists only on paper is exactly what this requirement exists to catch. An annual exercise keeps the evidence current and the muscle memory real.

Test the plan you actually wrote.

Drive the scenario through your own procedures. Cover how the incident is discovered, who is called, which forms get filled in, how containment is decided, and who talks to the prime contractor and to DoD. Fill out your real incident forms during the exercise. Walk the reporting steps for DIBNET, DoD's incident reporting portal, without submitting. Check whether your logs would have caught the scenario's activity. Every gap you find is the test working.

A real incident does not replace a deliberate test.

The requirement's discussion names checklists, walk-through and tabletop exercises, simulations, and comprehensive exercises as testing. Fold what a real response taught you into the plan, and still run the exercise, because a live incident exercises only the path it happened to take.

No special people or tools are needed.

Your own administrators are the ones who will respond to a real incident, so they are the right people to test with. A conference room, a scenario, and two hours does it. CISA, the federal cybersecurity agency, publishes free tabletop exercise packages with ready-made scenarios if you do not want to write your own.

The output documents are the evidence.

Keep the scenario, the date, the attendee list, notes on what worked and what did not, and the changes made to the plan afterward. A lessons-learned item that produced an actual change is the strongest answer to [a], because it shows the test changed something.

You already perform maintenance. The work here is showing it.

Patching operating systems and applications, fixing what breaks, replacing failing hardware, and updating firmware are all system maintenance. Objective [a] asks whether it happens. Patch reports from your management tooling and a trail of closed tickets are the evidence, so keep both where you can produce them.

Write down a cadence and follow it.

Write a short statement in the maintenance policy: endpoints and servers receive updates monthly, network devices and firmware follow the vendor's releases, and defects are fixed as tickets arrive. That statement turns scattered activity into a program an assessor can check against reality. Manufacturer recommendations are a defensible default where you have no reason to differ.

In a cloud environment, the provider maintains the service and you maintain everything that touches it.

Microsoft maintains the infrastructure of GCC High, its government cloud, and that split belongs in your responsibility documentation. Your side is the endpoints, the network equipment, and their firmware. Provider maintenance never patches your laptop.

Maintenance covers more than computers.

The requirement's discussion pulls in components not directly associated with information processing: scanners, copiers, and printers. Firmware on a firewall or a copier is exactly the kind of thing that goes untouched for years, so put those devices on the same cadence.

Answer four questions in the maintenance policy: which tools, which procedures, which automated jobs, which people.

Objective [a] is a list of approved maintenance tools. Objective [b] covers techniques, the documented procedures for how maintenance is done. Objective [c] covers mechanisms, the scripts, scheduled jobs, and remote management platforms that perform maintenance automatically. Objective [d] names the people authorized to do any of it. A page that answers all four is the core of this requirement.

The scope is tools brought in for diagnosis and repair, not the operating system's own commands.

The requirement's discussion aims at maintenance tools brought in from outside the system boundary for diagnostic and repair actions. Hardware and software test equipment, packet sniffers that capture network traffic, and vendor utilities are the kind it means. Built-in commands such as ping and ipconfig are part of the system and are governed by your access controls, so they need no inventory here.

Control means limiting who can reach the tools and watching their use.

Approve tools before they are used. Restrict maintenance consoles and administrative portals to the authorized people from [d]. Keep automated jobs where only administrators can edit them, and log what runs. Physical or logical access control on each of the four fronts is what the objectives look for.

Your MSP's remote management platform is the maintenance tool to control most carefully.

An MSP is a managed service provider, the outside firm that runs IT for you. Name its platform in your system security plan, the document that says how each requirement is met, and approve it deliberately. Put in the service agreement which of the MSP's staff may use the platform against your systems and what it is allowed to do. An agent on every endpoint with an unnamed operator pool is the opposite of controlled personnel under [d].

Keep it proportional in a small shop.

One administrator, a documented toolset, and administrative credentials nobody else holds satisfy all four objectives. The requirement asks for control, not a maintenance department.

The laptop sent out for repair is the scenario this requirement exists for.

Before any device that has held CUI, Controlled Unclassified Information, leaves your control for repair, the CUI comes off. Whoever works on it has the whole drive regardless of account passwords, so sanitize first or the device does not ship.

Sanitize means the data is gone, not locked.

Account passwords, multifactor authentication, and a login screen are access controls, and they do not satisfy [a]. Follow NIST SP 800-88: overwrite the media, purge it, cryptographically erase it by destroying the encryption keys, or destroy the media outright. Disk encryption with the keys intact is protection, not sanitization.

When you cannot wipe it, remove or destroy the storage.

A dead drive cannot be overwritten. Pull the drive and ship the chassis, destroy the failed drive and forfeit the warranty return, or buy the warranty terms that let you keep failed media. Decide which before the failure, because the vendor's return label does not wait on a policy discussion.

Cloud-managed devices have a one-step answer.

For a laptop enrolled in Microsoft Intune, the cloud service that manages your devices, a remote wipe or Autopilot reset before it ships removes the data. Capture the wipe confirmation as the record.

Keep a sanitization record per device.

Record the date, device, serial number, method, and who did it. The record turns a claim of sanitizing into evidence for [a], and the assessment guide's examine list names equipment sanitization records outright.

Your endpoint protection already does most of this. Write down that you rely on it.

Real-time protection scans a diagnostic utility when it lands on disk and scans removable media on access. State in the maintenance policy that diagnostic and test tools are scanned on download or insertion before they run, and that real-time protection enforces it. This requirement extends the malicious code protection of SI.L2-3.14.2 to the tools maintenance brings in.

The scenario is the vendor's diagnostic utility.

Support sends a tool to collect data from a misbehaving server. Download it, scan it, and verify the hash, the file fingerprint the vendor provides, before it runs on anything in scope. That habit is the whole requirement in practice.

Scan before use, not during.

A scan that runs while the USB drive is already in use on an in-scope system arrives too late for the word before in [a]. Scan on insertion, before files are opened. If removable media arrives from outside regularly, check it on a separate machine before it ever touches an in-scope system.

A finding is an incident.

When a scan flags malicious code on maintenance media, the requirement's discussion routes you to incident handling under IR.L2-3.6.1. Quarantine the media, keep it for analysis, and follow the plan.

Nonlocal maintenance is someone fixing your systems across an external network connection.

Your MSP, the managed service provider that runs IT for you, remoting into a server is nonlocal maintenance. So is a firewall vendor connecting to the management interface, and so are you administering the environment from home. The two objectives are simple: the session starts with multifactor authentication, a second proof of identity beyond the password [a], and ends when the work does [b].

Put the multifactor challenge on the path the maintenance rides.

A VPN, an encrypted connection into your network, satisfies [a] when it requires multifactor authentication. So does a remote access tool that enforces it, or an administrative portal behind conditional access in Microsoft Entra ID, sign-in rules that check the user and device. What fails is a management port reachable from the internet with a password alone.

Get the MSP's multifactor story in writing.

When an external provider maintains your systems through its own tooling, its technicians' authentication into that tooling is your [a] evidence. Require it in the service agreement. Capture it in the provider's responsibility matrix, the document that splits security duties between you, so the assessor sees whose control it is and how it is met.

Terminate means the session closes when the work is finished.

Log out and disconnect at the end of each session, and back the habit with idle timeouts in the remote access tool so an abandoned session closes itself. The termination settings plus a sampled session log answer [b].

A persistent management connection needs a deliberate answer.

Remote monitoring and management platforms hold a standing connection that is never complete in the requirement's sense. Document the platform as part of the system, put multifactor authentication on its console, and terminate operator sessions rather than the agent connection. Write that reading into your system security plan, the document that says how each requirement is met, so the assessor is not left to invent one.

This requirement covers the outsider fixing your systems, not your own administrators.

Maintenance personnel with required access authorization, your IT staff and the vetted provider technicians documented in your program, are not the subject. Objective [a] is about the one-off vendor engineer, the copier technician, and anyone else who works on systems without authorization for the CUI, Controlled Unclassified Information, that they could touch. Supervise those people while they work.

Supervision is a person watching, start to finish.

Assign an employee who knows what the work should look like to stay with the technician for the duration. Sign the visitor in under your PE.L2-3.10.3 procedure, watch the work, and sign them out. A maintenance log entry naming the technician, the supervisor, and the work performed is the evidence.

Temporary credentials beat borrowed ones.

When the technician needs to log in, issue a temporary account that expires in hours, scoped to the systems under repair, and remove it when the job closes. Never hand over an administrator's own credentials. A borrowed credential defeats both the supervision and your audit trail.

Decide in advance who counts as authorized.

Write down which maintenance personnel hold required access authorization: your administrators and the named provider staff. Everyone outside that list gets the supervised treatment, and the list is what lets you answer [a] without improvising at the door.

This requirement is about media you can pick up, not the drives fixed inside your computers.

The assessment guide's examples are paper, microfilm, flash drives, external and removable hard drives, tapes, and optical disks. A drive that takes a screwdriver to remove is still system media, but SC.L2-3.13.16 and your physical protection requirements cover its everyday protection. Aim the controls this requirement adds at what moves: inventory the paper and the portable media that hold CUI, the controlled unclassified information your contract requires you to protect.

The four objectives cover two actions across two media types. You control and store, for paper and for digital.

Physically controlled means you know what media exist, where each item is, and who has it, which is an inventory plus a check-out habit. Securely stored means a locked drawer, cabinet, or room that only authorized people can open. Satisfy all four combinations. A locked cabinet with no inventory fails [a] and [b]. An inventory of media left on desks fails [c] and [d].

A locked cabinet and a short inventory carry this requirement for a small shop.

List each item of media that holds CUI, keep the media in a locked drawer or cabinet, and record when something is taken out and returned. A controlled media library with check-out software does the same thing at a larger organization. You do not need one to meet this requirement.

The cheapest approach is to hold less media.

Every USB drive you do not issue and every page you do not print is media you do not inventory, store, or track. If your CUI lives in a cloud environment and you prohibit printing and removable media, say so and enforce it. Write the prohibition into your system security plan, the document that describes how your system meets each requirement. The requirement then rests on the few exceptions you actually allow.

Know where MP.L2-3.8.1 ends and MP.L2-3.8.2 begins.

This requirement is about controlling and storing the physical items. MP.L2-3.8.2 asks whether the people accessing the CUI on those items are authorized to see it. A single procedure that issues encrypted drives to named people from locked storage produces evidence for both.

Authorization here is about who may see the CUI, not who may touch the container.

A technician can carry a box of backup drives to a storage room without being authorized to read what is on them. The objective asks whether access to the CUI itself, the controlled unclassified information on the media, is limited to authorized users. Your evidence has to name who is authorized and show how everyone else is kept out.

Maintain a named list of who is authorized, and put someone in charge of it.

The assessment guide's example designates a data owner who approves access and keeps the list of authorized users. A one-page list tied to a contract or project, with the owner's name at the top, answers the assessor's first question. Without it you are arguing that access is limited while unable to say to whom.

A written rule with nothing behind it does not limit anything.

A policy that says only authorized users may access CUI media, sitting alongside an unlocked drawer, leaves [a] with no mechanism. Pair the rule with the physical controls: locked storage, a check-out log, and racks or server rooms that lock.

Racks and server rooms are media storage too.

The drives in your servers and the tapes in your backup unit are system media. Locking the server room and limiting who holds the key limits access to the CUI on everything inside it, and the key list doubles as evidence for this objective.

Sanitize everything that held FCI or CUI, and do not parse the wording for an exemption.

Federal Contract Information is the information provided by or generated for the government under a contract and not intended for public release. The requirement text says Federal Contract Information because MP.L2-3.8.3 carries the Level 1 practice forward into Level 2. The CUI on your media, the controlled unclassified information you must protect, is contract information too. The practical scope is every item of media that held either. This is also a five-point requirement under 32 CFR 170.24. Under 32 CFR 170.21, its point value bars it from any POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Have the process working before the assessment rather than promising it after.

Anchor your methods to NIST SP 800-88 and pick by destination.

The assessment guide points to NIST SP 800-88, Guidelines for Media Sanitization, and its techniques of clearing, purging, cryptographic erase, and destruction. Use clear-level sanitization for media reused inside the organization, and purge or destroy anything leaving your control. Write the chosen method for each media type into your procedure so nobody improvises at the recycling bin. You do not need government-grade destruction services for CUI. A method that makes the information unrecoverable is what the requirement asks for.

Understand what your erase button actually does before you rely on it.

A factory reset or a vendor wipe utility qualifies only if it sanitizes all user-addressable storage. Cryptographic erase works only if the encryption key on the drive itself is destroyed. Deleting recovery keys from where you store them does not touch the key on the drive. For each device type you dispose of, keep the vendor documentation that says what the sanitization function does, or destroy the media instead.

Keep a destruction log. The process is invisible without it.

Record the date, the media or asset identifier, the method, and who performed or witnessed it. A certificate of destruction from a shredding vendor is a ready-made entry. When an assessor asks how you meet [a], a log with entries is the difference between a described process and a demonstrated one.

Paper is in scope, and shredding is the answer.

The requirement covers non-digital media, and the guide names removal, redaction, and destruction as sanitization for paper. Cross-cut shredding before disposal or recycling, with the habit written into your procedure, closes [a] for paper. Boxes of intact CUI paper handed to a recycler close nothing.

Mark the removable media and the paper, not the fleet of laptops.

The media in this family is paper, USB drives, external drives, and optical disks. A drive fixed inside a laptop is part of the system. A sticker labeling the lid CUI, controlled unclassified information, marks nothing the requirement covers and advertises the machine as a target. Put labels on the things that detach and circulate.

Carry markings forward. Do not invent them.

You are an authorized holder of CUI, not the designating agency that marked it in the first place. Documents and drawings arrive from the government or your prime contractor already carrying their banner and distribution statement. Print and copy them with the markings intact, and write that carry-forward rule into your policy. A DoD distribution statement on an incoming drawing is a distribution limitation on its face, which is exactly what [b] asks for. Mark your own output as CUI only where the contract directs it.

Small media get the minimum marking.

A USB drive has no room for a full banner. Label it CUI or CONTROLLED plus the designating agency, and keep the detailed category and dissemination markings on the documents inside. That minimum comes from the marking guidance of NARA, the federal agency that runs the CUI program, and satisfies both objectives for space-limited media.

Objectives [a] and [b] are two different marks.

The CUI banner tells a reader the information is controlled. The distribution limitation tells them who may receive it. A drive labeled CUI with no indication of distribution meets [a] and leaves [b] open. Pair the control marking with the distribution statement or a named program restriction.

Define your controlled areas before you argue about transport.

Objective [b] only applies outside of controlled areas, so the boundary has to exist on paper first. Say in your system security plan, the document that describes how your system meets each requirement, which rooms, floors, or buildings are controlled and by what mechanism. Inside that line, MP.L2-3.8.1 and MP.L2-3.8.2 govern. The moment media crosses it, [b] wants a record of who has the media and where it is going.

Accountability is a record, and a transport log is the simplest one.

The log records who took which item, when, to where, and when it came back. A sign-out sheet next to the media cabinet or a ticket in your help desk system both work. The guide's accountability language is about restricting transport to authorized people and keeping explicit records of the movement, which is a log by any name.

Encrypt what travels, and the loss becomes an inconvenience instead of an incident.

The guide names locked containers and cryptography as the transport controls. FIPS validation is the federal program that certifies encryption modules. A FIPS-validated encrypted drive that goes missing in a taxi is a recoverable event. Encryption does not replace the accountability record, but it is the control that matters most when the record says the media is gone.

Shipped media gets packaging, a named recipient, and a tracking number.

The assessment guide's example is exactly this: tamper-evident packaging, a specific addressee, a reputable carrier, and the tracking number shared with the recipient. That paper trail is [b] for anything you cannot hand-carry.

Hand-carried media stays in your personal possession.

A drive or a tube of drawings you carry is under direct control only while it is actually with you. Do not check it as luggage. Do not leave it in a car. Log it out and back in like any other transport.

This requirement gives you two ways to meet its one objective, and encryption is the better one.

CUI, controlled unclassified information, on digital media in transport is either encrypted or wrapped in physical safeguards such as a locked container under authorized custody. Encryption is cheaper, does not depend on anyone's vigilance, and keeps protecting the data after the physical safeguard fails. Reserve the physical route for media that genuinely cannot be encrypted.

Use FIPS-validated cryptography, because the assessor will ask.

The assessment guide's considerations ask whether the cryptographic mechanisms comply with FIPS 140-2, the federal standard for encryption modules. SC.L2-3.13.11 requires FIPS-validated cryptography wherever encryption is what protects CUI confidentiality. A hardware-encrypted drive with a FIPS 140 validation certificate is the clean answer: buy it, record the certificate number, and issue it through your MP.L2-3.8.1 inventory.

This requirement is the backstop for MP.L2-3.8.5.

Accountability tells you a drive is missing. Encryption decides whether that matters. The guide states the intent directly: protect against the situation where control of the media fails through loss. Treat the two as one procedure: sign out the encrypted drive and log the transport.

Backups leaving the building count as transport.

Tapes or drives couriered to offsite storage carry CUI outside your controlled areas. Enable your backup software's encryption for anything sent offsite, and confirm the mechanism is FIPS-validated rather than assuming it.

This requirement restricts what plugs into your systems. MP.L2-3.8.1 restricts who touches your media.

The assessment guide draws the contrast itself. Here the question is whether a flash drive or external disk can be used on a workstation at all, and under what rules. Answer it with a deliberate stance: which device types are allowed, on which systems, for whom.

Default deny, allow by exception, enforce with software.

A policy is a control, but a policy plus enforcement is a control an assessor can test. Block removable storage through your endpoint management or endpoint protection tooling, then allow specific issued devices by exception for people with a business need. The exception list doubles as your MP.L2-3.8.8 ownership record.

Nontechnical controls are legitimate where technical ones do not fit.

The guide accepts policies, procedures, and rules of behavior as controls, and physical measures like port blockers on machines that cannot run device-control software. A shop floor machine with a policy sign-off and a physical port lock is controlled. A network with no stance on USB drives is not.

This is a five-point requirement, so settle it before assessment.

32 CFR 170.24 lists MP.L2-3.8.7 among the five-point derived requirements. Under 32 CFR 170.21, its point value keeps it off any POA&M, the plan of action and milestones that lets certain gaps be closed after assessment. Device control in a modern endpoint suite is hours of work, not a project. Do it early.

The owner can be the organization, a team, or a person. Every device must trace to someone accountable.

The guide names individuals, organizations, and projects as acceptable owners. The common pattern is company-owned drives issued to named people, with the issuance recorded. A device inventory with an owner column is the evidence for [a].

The found USB drive is the scenario this requirement exists for.

A drive in the parking lot has no identifiable owner and never gets plugged in. Say so in policy, cover it in awareness training, and tell people to hand any drive they find to IT. The assessment guide's own example is exactly this drill.

Back the prohibition with a technical default.

A rule the computer enforces works better than a rule people must remember. Configure device control so unknown storage devices are blocked or read-only and only issued, inventoried drives can be written to. This is the same mechanism that MP.L2-3.8.7 uses, so one configuration serves both requirements.

MP.L2-3.8.8 tightens MP.L2-3.8.7 rather than repeating it.

MP.L2-3.8.7 decides which kinds of media are allowed at all. This requirement adds that even an allowed kind is prohibited when the specific device cannot be traced to an owner. Your MP.L2-3.8.7 exception list satisfies it automatically as long as every excepted device has an owner on record.

Start by listing every place a backup of CUI lands.

The list includes server images, file share snapshots, cloud tenant retention, the network storage box in the closet, the external drive someone rotates, and a line-of-business vendor's own backup. The requirement covers the confidentiality of backup CUI, the controlled unclassified information you protect, at each storage location. The location you forgot is the finding. If CUI is in a system, its backups hold CUI.

Encryption, access control, and physical security are all valid. Use encryption as the default.

The guide accepts cryptographic mechanisms or physical controls at the storage location. Encrypting backup data with a FIPS-validated mechanism, encryption the government has certified, answers the assessor's follow-up question before it is asked. A locked room plus tightly limited access is the alternative for on-premises media you cannot encrypt.

Cloud backup inheritance is real, but only as complete as your backup inventory.

If every backup of CUI lives inside your FedRAMP-authorized cloud environment, one the federal government has assessed and approved, the provider's protections can carry this requirement. The claim collapses the moment CUI is also backed up somewhere you did not account for. The inventory from the first lesson is what makes the inheritance defensible.

Inheritance is documented, not declared.

Get the provider's customer responsibility matrix, the document that splits security duties between the provider and you. Find the rows covering backup storage protection. Cite them in your system security plan, the document that describes how your system meets each requirement, next to what remains yours to do. A bare statement that the cloud handles everything is not evidence and invites the questions it cannot answer.

The requirement fixes when screening happens, not what it is.

The requirement prescribes no particular background check. Define the screening for each role that touches CUI, the controlled unclassified information your contract requires you to protect. Ground it in the position's risk, and apply it before the person can reach systems containing CUI. A criminal background check plus employment verification is a defensible baseline for general CUI access.

Your existing hiring process is most of the control.

Write down what already happens before an offer: background check, reference checks, verification of eligibility to work. Then add the one connection this requirement cares about: CUI system access is not authorized until the screening is complete. HR runs the screening. The control lives in the handoff to IT.

Sequence is the evidence.

Objective [a] turns on the words prior to. For each person with CUI access, keep records showing the screening finished before the account was authorized. Make account creation wait on an explicit all-clear from HR, and the evidence generates itself.

Handle existing employees by policy, not by re-running their hiring.

Apply the documented screening to everyone authorized after the policy exists. For staff who already hold access, record what screening they received at hire and state in the policy that it satisfies your standard. Re-screening a twenty year employee is a choice you can make, not one the requirement forces.

Export controlled CUI raises the screening floor.

Some CUI carries export control markings such as ITAR, the regulation covering defense articles and technical data. Export control law restricts access by nationality. For that CUI, screening also verifies the person is a U.S. person or holds the required authorization. Fold that verification into the same pre-access gate.

Write the offboarding procedure first. It is objective [a] verbatim.

A one page procedure naming who tells whom, what gets disabled, what gets collected, and by when satisfies [a] and drives everything else. PS.L2-3.9.2 is a five point requirement under 32 CFR 170.24. Under 32 CFR 170.21, a five point requirement can never sit on a POA&M, the plan of action that buys time for unfinished requirements. A missing procedure is therefore expensive.

Disable access the day employment ends, and earlier when the termination is for cause.

Disable the account in your identity provider, the service that checks user sign-ins. Revoke active sessions so open logins die with the account. Collect devices and badges, and change any shared credentials the person knew. The assessment guide allows accounts to be disabled before the individual is notified when the termination is for cause. Coordinate the disable time with HR instead of acting after the fact.

Transfers are the half of this requirement that fails quietly.

Objective [c] covers the employee who stays but changes roles. Remove the old role's access on the transfer date instead of stacking new access on top. CUI is the controlled unclassified information your contract requires you to protect. A move into a role without CUI contact means CUI access ends, including physical access to spaces where CUI lives.

The control is the HR to IT signal, so build the trigger and the backstop.

Access that outlives employment is what happens when IT learns of a departure late. Make the HR action open an IT ticket, by automation or by checklist. Compare active accounts against the current roster on a schedule, so anything the trigger missed gets caught.

The exit conversation is part of protecting CUI.

Remind the departing person that nondisclosure obligations cover CUI after employment, and record that the reminder happened. When no exit interview is possible, as with job abandonment, run the access and property steps anyway and document why the interview did not occur.

Objective [a] is a list. Write it before you buy a lock.

Name the people authorized for physical access to each controlled area: the building, the office, the server closet. The rest of the requirement limits access to the people on that list, so the list has to exist, stay current, and match who actually holds keys and badges.

Layer the physical controls to match your facility.

A locked exterior door, a lockable office, and a locked closet or rack for network equipment cover [b] and [c] in a small office. Badge readers and electronic locks do the same job with better records. They are worth buying when headcount makes keys unmanageable, not before.

The operating environment is anywhere CUI can be seen or heard.

CUI is Controlled Unclassified Information, the government information your contract obliges you to protect. Objective [d] extends the requirement past the server room. It covers the offices, work areas, and print stations where CUI shows on screens, sits on desks, or comes up in conversation. Define those areas and limit access to them the same way.

Put printers where output is not exposed, or prohibit printing CUI outright.

An output tray in a shared hallway hands CUI to anyone walking past, which fails [c] for that device. Move the printer inside the controlled area. Or write and train a policy that CUI is never printed, and post a sign at the printer saying so.

A shop floor does not need floor-to-ceiling walls.

Fence and lock an enclosure for the equipment inside an access-controlled building. Lock the CUI drawings in a cabinet at the end of the shift. Those layers limit access in a way you can demonstrate. Each layer needs a lock and a defined set of key holders. The material of the barrier matters less than who can pass it.

Policy plus trained people is a real control where hard barriers fail.

A manufacturing bay with doors open for ventilation still passes when signage marks the boundary, visitors sign in and are escorted, and employees are trained to challenge strangers. Write the reasoning down so the assessor sees a decision, not an oversight.

Protect and monitor are two duties across two subjects.

Objectives [a] and [b] ask that the facility and the support infrastructure are protected: locks, barriers, controlled entry. Objectives [c] and [d] ask that both are monitored: some way of knowing who came near and when. Cover each pairing deliberately, because a locked closet nobody can account for fails the second half.

Support infrastructure means the cabling, closets, and panels your systems depend on.

Lock the wiring closet, run cable through conduit or trays where it crosses uncontrolled space, and keep spare network jacks disconnected or locked down. The requirement's discussion names exactly these measures, and they are cheap.

Monitoring does not mean cameras watched around the clock.

Badge logs with alerting on unauthorized attempts count as monitoring. So do an alarm system armed after hours, a reception desk during business hours, and a key sign-out log for the wiring closet. Cameras add coverage and timestamps, and a small office can meet [c] and [d] without them.

Scope stops at what you control.

The requirement does not extend to the power utility or the guards at a substation. It is also not about uptime: NIST SP 800-171 protects confidentiality, so redundant power and fire suppression are risk decisions, not obligations here. Ask of any proposed measure whether losing it would expose CUI, the Controlled Unclassified Information you protect, and spend accordingly.

Multi-tenant buildings are where this requirement fails.

A network closet shared with the landlord or other tenants, with your firewall in it and no way to tell who enters, is the recurring gap. Put your equipment in a locked cabinet inside the shared space, control that key, and get notification of building staff access written into the lease terms.

A visitor is anyone without permanent access authorization, and every visitor gets an escort.

Objective [a] means an authorized person accompanies visitors through the controlled area. [b] means their activity is watched. The escort satisfies both when they stay with the visitor from sign-in to sign-out, because escorting is monitoring.

This requirement can never sit on a POA&M.

A POA&M, a plan of action and milestones, is the document that defers a few unmet requirements past the assessment. 32 CFR 170.21(a)(2)(iii) lists PE.L2-3.10.3, PE.L2-3.10.4, and PE.L2-3.10.5 among the six Level 2 requirements barred from one. A Not Met on any of them denies even a conditional CMMC status. Escorting visitors is also one of the cheapest requirements in the rule to meet, which makes it a bad place to lose an assessment.

Regular vetted outsiders are not visitors. Define them as authorized personnel.

The cleaning crew, a badged subtenant, and contractors with standing access can be vetted, trained as needed, added to the facility access list as third-party personnel, and issued credentials. The escort duty then applies to actual visitors. What you cannot do is wave regulars through without either vetting or escort.

Make visitors identifiable at a glance.

A visitor badge or a distinct lanyard tells every employee who should have an escort. Pair it with a trained norm that employees stop and redirect an unescorted stranger. In a small office where everyone knows everyone, the written procedure still exists even when a badge adds little.

The friend in the hallway is the test.

An employee's friend walking unescorted toward the lunchroom is exactly the situation this requirement addresses. The procedure that passes: walk them back to reception, sign them in, and assign an escort. Then treat the door that let them in as the finding it is.

A paper sign-in sheet is a compliant audit log.

The requirement's discussion accepts procedural logs, automated logs, or a combination. A visitor logbook at the door plus badge system records for employees covers a typical office, and neither requires new spending.

Log the controlled areas, not just the front door.

Physical access points include interior areas with supplemental controls, such as a server room. Where the room has its own badge reader, its log answers this. Where it has a key, a key sign-out sheet does.

Cameras can be the log.

Motion-triggered footage where every clip carries a timestamp is a chronological record of access. For a facility with several entrances and no badge readers, timestamped camera coverage of the entry points is a workable log that asks nothing of anyone day to day.

Define a retention period and honor it.

The requirement says maintain and leaves the period to you. Pick a number, write it into the procedure, and keep the logs that long, because the assessor checks your practice against your own stated period.

Maintained means reviewable, not reviewed.

No objective requires a routine review of these logs. Keep them retrievable so an investigation can reconstruct who was where. A folder of sign-in sheets meets that bar.

This is another of the six requirements 32 CFR 170.21 keeps off any POA&M.

A POA&M, a plan of action and milestones, defers an unmet requirement past the assessment, and a missing log cannot be deferred that way. Have the log running before the assessment, not after it. A sheet of paper and a pen start the evidence today.

Inventory the keys, badges, fobs, and combinations first.

Objective [a] asks that physical access devices are identified: what devices exist, which doors they open, and who holds each one. A spreadsheet with device, area, holder, and issue date answers it.

Control is who gets one. Manage is what happens after.

Issue devices only to people on the authorized access list. Keep spares locked up, and record every issuance for [b]. Then keep the system true over time for [c]. Collect devices at departure, and deactivate lost badges. Change combinations when someone who knows them leaves, and re-key when a perimeter key goes unreturned.

Hand out as few perimeter keys as possible.

Every key to the outer door is a future re-keying decision when it fails to come back. Fewer holders makes departures cheap, and a badge system makes them free, since revocation is a click instead of a locksmith.

An unreturned key is a decision point, not a shrug.

When a departing employee does not return a key, either re-key the affected locks or record the accepted risk with a reason. What fails is an inventory that says twelve keys and a drawer that holds nine with no explanation.

This requirement is barred from any POA&M.

A POA&M, a plan of action and milestones, defers an unmet requirement past the assessment. 32 CFR 170.21(a)(2)(iii) puts PE.L2-3.10.5 on the same barred list as PE.L2-3.10.3 and PE.L2-3.10.4. The device inventory and issuance records have to exist on assessment day, and they are an afternoon of work in a small facility.

A remote work policy is the backbone of both objectives.

CUI is Controlled Unclassified Information, the government information your contract obliges you to protect. Objective [a] asks that safeguarding measures for it are defined for alternate work sites. A policy naming the approved site types and the required protections defines them. Objective [b] asks that they are enforced. Training with a signed acknowledgment plus the technical controls that travel with the laptop enforce them.

The measures that matter travel with the device and the habits.

Encrypt the whole disk, and require a screen lock. Reach your environment through a VPN, an encrypted connection into your network, or through conditional access, sign-in rules that admit only trusted users and devices. Bar household use of the device, and lock up any printed CUI. Enforce the technical half through management tooling such as Microsoft Intune, so the control does not depend on the user remembering.

Calibrate to CUI, not to classified.

CUI at an alternate work site needs a controlled environment: walls, a door that closes, and screens positioned away from casual view. It does not need a windowless room or defenses against surveillance. Rules imported from classified handling produce a policy nobody follows, and an unenforced rule fails [b].

Decide the coffee shop question by policy.

Working with CUI in public spaces is easiest to prohibit outright: homes and hotel rooms with a lockable door qualify as work sites. The airport lounge does not. A written line enforced through training does the job. A geolocation project does the same job at many times the cost.

Cloud-native and fully remote organizations own this requirement outright.

A provider's data center controls can cover much of the rest of this family, but no provider controls your employee's kitchen table. For a fully remote organization every work location is an alternate work site, which makes this small requirement most of your physical protection story. Give it the corresponding weight.

Objective [a] is one sentence in a policy: write down the frequency.

An undefined frequency fails [a] before anyone looks at the assessment itself. The CMMC rule at 32 CFR 170.4 defines periodically as at least annually, so annual is the floor. State the frequency, then show assessments dated to match it for [b].

Assess the risks that come from operating a system that handles CUI, not every risk your company has.

CUI is the controlled unclassified information your contract requires you to protect. The requirement scopes itself: risk resulting from the operation of organizational systems and the associated processing, storage, or transmission of CUI. The risks in scope are unauthorized access, disclosure, spills, compromised credentials, and a vendor with access it should not have. A disaster recovery annex about earthquakes is a different exercise, and padding the assessment with it does not answer [b].

A dated document is the deliverable, not a platform.

The guide's method is threats, vulnerabilities, likelihood, and impact, with NIST SP 800-30, the government's risk assessment guide, as the reference. A few pages that walk your CUI environment through that lens, signed and dated, repeated on your defined frequency, meets the requirement. Buy a risk register tool when the volume of findings demands one, not to have something to show.

Reuse the company-wide risk assessment where the infrastructure is shared.

If your CUI environment runs in the same building, on the same network, with the same staff as everything else, one assessment can serve both. Extend it with the CUI-specific risks rather than duplicating the whole exercise for the CUI environment.

This assessment is what the rest of the family points back to.

RA.L2-3.11.3 remediates vulnerabilities in accordance with risk assessments, and the plans of action under CA.L2-3.12.2 flow from what the assessment finds. Skip it and those requirements lose the document they depend on. Do it and prioritization decisions elsewhere become defensible instead of arbitrary.

Define a frequency you will never miss, then scan more often than it.

Objective [a] wants a number and [b] and [c] want scans dated to match it. Write the frequency you can hold through vacations, outages, and the laptop that stayed in a trunk for a month. Then run your actual scans more often. A quarterly commitment executed weekly never produces a gap between policy and record.

Scan the whole environment the CUI lives in, not just the machines that touch CUI.

CUI is the controlled unclassified information your contract requires you to protect. The guide sweeps in servers, workstations, laptops, virtual machines, network gear, and printers. It says directly that everything in the CMMC assessment scope gets scanned, including laptops that rarely see the office network. A scanner installed on each machine as an agent reaches the remote machines a network scanner never will. Have a plan for one hundred percent of assets, wherever they sit.

Applications hold their own objective letters, so scan them on purpose.

Objectives [c] and [e] exist because an operating-system scan does not see the web application or the database running on the box. A credentialed scan, one that logs in to the machine it examines, reaches the installed software. A web application needs a scan aimed at it. If you build custom software, the guide expects analysis of it, with source code scanning as the accessible starting point.

A scanner you triage beats a platform you ignore.

A free or modest tool run on schedule, with findings reviewed and fed into remediation, is a working vulnerability management program. A subscription generating reports nobody opens is a shelf ornament that fails [b] through [e] the first time an assessor asks what you did about a finding. Pick the tool you will actually operate. This is a five-point requirement under 32 CFR 170.24. Under 32 CFR 170.21, its point value keeps it off any POA&M, the plan of action that buys time for unfinished requirements. A modest working program now outranks a grand plan for later.

Objectives [d] and [e] ask what happens when the world changes between scans.

Two mechanisms cover it: a scanner that updates its vulnerability feed before every scan, and the demonstrated ability to run an off-cycle scan when a severe vulnerability breaks. Keep the report from the last time a headline vulnerability sent you scanning. It is the cleanest evidence [d] and [e] can have.

In accordance with risk assessments means you choose priorities, in writing.

The requirement does not demand that every finding be fixed. It demands that what you fix, defer, and accept follows your assessment of risk. Write the rule down: which severity levels get remediated and on what timeline, which can be accepted, and who signs the acceptance. One defensible rule remediates everything high and critical on a set timeline, drives mediums to a recorded fix-or-accept decision, and risk-accepts documented lows. The same behavior with no written rule is just a backlog.

Show the full life of a finding, twice.

The convincing evidence for this requirement is a pair of examples end to end: a vulnerability appearing in a scan, tracked in a ticket, fixed, and absent from the next scan. Two before-and-after report pairs demonstrate [a] and [b] together better than any process description.

Track what you decided not to fix, or the decision looks like neglect.

A finding you evaluated and accepted, with the reasoning and an owner recorded, is a met requirement. The same finding sitting unexplained in every quarterly report is an unaddressed vulnerability. Severity ratings from the scanner are the input. Your documented disposition is the evidence.

Use the scoring rule for gaps you cannot close on demand.

Under 32 CFR 170.24(b)(1), two kinds of gap are still assessed as MET. An enduring exception is MET when your system security plan, the document that describes how your system meets each requirement, describes the exception and its mitigations. A temporary deficiency is MET when an operational plan of action appropriately addresses it. The machine controller that cannot be patched without breaking the machine belongs in the first category, with its isolation described. The fix awaiting a vendor patch belongs in the second. The regulation gives you both paths, so use them instead of hiding the finding.

A finding whose exploit conditions do not exist in your environment can be reclassified, after an investigation you write down.

When a vulnerability requires a port you have closed, a module you have not installed, or a configuration you do not run, investigate. Record what you checked, and mark the finding not applicable. The documentation is the difference between a risk decision and wishful dismissal.

Define the frequency in writing, and treat annual as the floor.

Objective [a] is a stated frequency, and the CMMC rule at 32 CFR 170.4 defines periodically as at least annually. An annual self-assessment of your implemented controls, documented and dated, satisfies the letter of both objectives. This is a five-point requirement under 32 CFR 170.24. Its point value keeps it off any POA&M, the plan of action and milestones that defers unmet requirements, under 32 CFR 170.21. Build the habit before the assessment year.

Assess effectiveness, not existence.

The requirement says determine if the controls are effective in their application. That is a harder question than whether you are doing what your system security plan, the document that says how each requirement is met, claims. For each control, ask whether the implementation actually mitigates the risk it is there for. The log review that never finds anything may be looking at the wrong logs. The visitor badge process nobody follows is a control on paper only. Record the judgment, not just a met checkbox.

The outputs are documents that feed other requirements.

The guide lists them: documented assessment results, proposed new or updated controls, remediation plans, and newly identified risks. The deficiencies you find become the CA.L2-3.12.2 plan of action, and the risks feed RA.L2-3.11.1. An assessment that produces findings and follow-up work is self-evidently real. One that produces a clean sheet every year invites the question of how hard anyone looked.

Keep CA.L2-3.12.1 and CA.L2-3.12.3 distinct in your program.

This requirement is the scheduled, deliberate look at whether controls are effective as designed. CA.L2-3.12.3 is the ongoing monitoring between those looks. One annual assessment plus a recurring monitoring rhythm covers both. A single activity labeled with both identifiers covers neither, because the evidence for a periodic deep review and for continuous monitoring look different.

An exercise can be a control assessment.

Testing the incident response plan, restoring from backup, or failing over a system assesses those controls in their application. Fold the results into your assessment record. Planning to evaluate the plan only when a real incident arrives is not an assessment method. It is the absence of one.

This is your operational plan of action, not the assessment POA&M, and confusing the two costs you.

The assessment POA&M is the plan of action and milestones defined in 32 CFR 170.4 and constrained by 32 CFR 170.21, and it exists only around a CMMC assessment. It is limited to select low-weight requirements and must close out within 180 days of the conditional status date. The plan this requirement asks for is the standing document you run all year to track deficiencies and vulnerabilities to closure. Keep them as separate artifacts with separate names, because they answer different questions under different rules.

The operational plan of action is also how a temporary deficiency scores as MET.

32 CFR 170.24(b)(1)(ii) states that temporary deficiencies appropriately addressed in operational plans of action, meaning the plan includes deficiency reviews and shows progress toward correction, are assessed as MET. Take the common encryption gap: a required patch moves you off the FIPS-validated module version, the exact build the government certified, while revalidation is pending. That gap does not have to fail the affected requirement if this document exists and shows the deficiency being worked. That makes CA.L2-3.12.2 one of the highest-leverage requirements in the whole set.

Every entry gets an owner, steps, and dates.

The guide's checklist is ownership, clear actionable steps or milestones, responsibility for each step, milestones to measure progress, and completion dates. Format is irrelevant: a spreadsheet tab, a ticket type in your tracker, or a document all work. Content and follow-through are what the objectives test.

Objective [c] is the one that fails: the plan must be worked, not just written.

Entries that sit unchanged through four quarterly reviews show a plan that was developed for [b] and never implemented for [c]. Review the plan on a schedule. Update milestones as they pass, and close entries with evidence. Have someone other than the fixer verify the fix where it matters.

Feed it from everything that finds problems.

Scan findings from RA.L2-3.11.2, deficiencies from CA.L2-3.12.1 assessments, incident lessons, and audit findings all identify the items [a] asks about. One intake and one document beats a scatter of lists. Not every flaw earns an entry. Fix the one-off misconfiguration on the spot. Reserve the plan for deficiencies that take time, resources, or coordination, plus the recurring problem that needs a root-cause task.

Ongoing means a defined rhythm faster than your annual assessment.

CA.L2-3.12.1 is the scheduled full assessment. This requirement is the ongoing monitoring between those assessments. Define which controls get checked monthly or quarterly and which ride the annual assessment, and write the rhythm down. You define the frequencies, but a monitoring plan whose every interval is annual has collapsed into CA.L2-3.12.1 and covers neither well. This is also a five-point requirement under 32 CFR 170.24. Its point value bars it from any POA&M, the plan of action and milestones that defers unmet requirements, under 32 CFR 170.21.

Manual monitoring is fine. Undocumented monitoring is invisible.

A recurring ticket that comes due each month is a working continuous monitoring program for a small shop. So is a spreadsheet with the control, the result, the date, and the reviewer's name. The completed records are the entire evidence base for [a]. A dashboard nobody exports and a policy that says monitoring happens both evaporate under the question of when you last did it.

Spend the frequent checks on the volatile controls.

Patching status, vulnerability findings, asset inventory accuracy, account and access reviews, and document drift change weekly. A locked server room does not. Weight the rhythm toward what moves, and let stable controls surface through the annual assessment. Make sure every control appears somewhere in the combined cycle so nothing is monitored by assumption.

Reuse the activities other requirements already force.

Log review, risk assessment under RA.L2-3.11.1, plan of action reviews under CA.L2-3.12.2, and incident response follow-ups are monitoring activities. Reference them in your monitoring plan and route their outputs into it rather than building a parallel program. The guide's chain is direct: monitoring output informs management's risk decisions and keeps the system security plan, the document that says how each requirement is met, honest between assessments.

The system security plan is the one document a CMMC assessment cannot proceed without.

The plan is the document that describes your system and how it meets each requirement. 32 CFR 170.24(c)(2)(i)(5) requires one in place at the time of assessment, describing each information system in the CMMC assessment scope. The absence of an up to date plan results in a finding that an assessment could not be completed, due to incomplete information and noncompliance with 48 CFR 252.204-7012. Every other requirement failure costs points. This one stops the assessment itself. Out of date carries the same consequence as missing, so a plan written for the environment you had two migrations ago does not protect you.

There is no POA&M escape for this requirement.

32 CFR 170.21(a)(2)(iii) names CA.L2-3.12.4 among the requirements that may never appear on a POA&M, the plan of action and milestones that defers unmet requirements. There is no conditional status to fall back on if the plan is not ready. Finish the system security plan before you schedule the assessment, and treat every review between now and then as a chance to find what it fails to describe.

Objectives [a] through [h] are the table of contents. Write to the letters.

Describe the boundary for [b] and the environment of operation for [c]. Identify the non-applicable requirements for [d]. Describe the implementation method for each security requirement for [e] and the relationships and connections to other systems for [f]. Define an update frequency for [g], and demonstrably honor it for [h]. An assessor walks these letters in order, so a plan organized around them assesses smoothly and a plan organized around a marketing template does not.

Objective [e] wants a narrative per requirement: what you do, not what the requirement says.

For each security requirement, write a brief description of how your organization implements it, addressing the objectives, and reference the policy or procedure that carries the detail. Avoid two failure modes. The shell plan only points elsewhere for every answer. The kitchen-sink plan buries implementation statements in hundreds of pages of pasted boilerplate. Both force the reader to hunt, and the reader is scoring you. The guide is explicit that the plan may be a collection of documents. The narrative is the map that makes the collection usable.

The environment of operation is people, facilities, and workflow, not an operating system inventory.

Objective [c] asks where and how the system operates. Cover what the business does, where CUI, the Controlled Unclassified Information you handle, enters and moves, who touches it, and in what physical surroundings. A few honest paragraphs covering the people, the technology, and the facilities give the assessor the context every later answer hangs on.

Objective [d] is the commonly missed letter: not applicable is a ruling, not a self-assessment.

Requirements you treat as non-applicable must be identified and approved by the designated authority. Under 32 CFR 170.24(c)(2)(i)(8), the ruling comes from the DoD CIO: an adjudication that a requirement is not applicable, or that an alternative security measure is equally effective. That adjudication must be included in the system security plan to receive consideration during an assessment. Claiming adjudicated non-applicability on your own authority and documenting nothing invites the assessor to score the requirement as unmet.

The boundary description in [b] is what makes every scoping argument stick.

Say which assets are inside, which are outside, and what separates them, with a diagram. The enduring exceptions that 32 CFR 170.24(b)(1)(i) assesses as MET also live here, described with their mitigations. When an assessor questions whether a device is in scope or a gap is acceptable, the answer either sits in the system security plan already or turns into a finding.

Update on a defined cycle, and prove it.

Objective [g] wants the frequency defined, and [h] wants it honored. The guide's stated norm is at least annually, and 32 CFR 170.4 caps any periodic interval at one year anyway. Keep a revision history with dates and what changed, and update off-cycle when the environment shifts: a new cloud service, a dropped connection to a partner, a moved office. The revision log is the cheapest evidence in the whole plan, and it is the first place an assessor looks to test whether the document is alive.

Define the boundaries before you defend them.

Objectives [a] and [b] ask for definitions, not equipment. Draw the external boundary where your system meets the internet and anything else you do not control. Then name the components that sit on it: the firewall, the VPN (virtual private network) gateway, and the cloud services where your traffic lands. Then decide whether any key internal boundaries exist. A network diagram that names these boundaries answers [a] and [b] and gives the other six objectives something to attach to.

A small, deliberate boundary makes the rest of this family cheaper.

Every boundary you define must then be monitored, controlled, and protected. An enclave isolates the systems touching CUI (Controlled Unclassified Information) behind one firewall and one set of rules. That gives you two boundaries to defend instead of a sprawling network's dozen. The segmentation that carves the enclave out of the rest of your network is itself a key internal boundary under [b], so monitor and control it like the perimeter.

Having no key internal boundaries is an acceptable answer when it is true.

A small flat network with nothing separating one part of the system from another has no key internal boundaries to name. Write that determination down under [b] and the internal halves of [d], [f], and [h] follow it. What fails is silence: an assessor who finds a segmented development network or a separate WiFi you never declared will ask why your definition missed it.

Cover three verbs at each boundary: monitor, control, protect.

Objectives [c] through [h] pair monitoring, control, and protection with each boundary class. Monitoring means the traffic is logged, reviewable, and alerting on the suspicious [c, d]. Control means connections are denied by default and allowed by exception [e, f], which SC.L2-3.13.6 sharpens into its own requirement. Protection means encryption or tunneling where the traffic warrants it [g, h]. Walk each named boundary through all three verbs. Record the mechanism in your system security plan, the document that describes how your system meets each requirement.

A cloud-first company still has boundaries to declare.

When your CUI lives in a cloud tenant and your staff work from anywhere, the external boundary changes shape. It becomes the host-based firewall on each managed endpoint plus the cloud service's own managed perimeter. Declare both, show the endpoint firewall denying unsolicited inbound traffic, and point at the provider's boundary responsibilities in its shared responsibility documentation.

The six objectives are one structure: identify three things, then employ them.

Objectives [a], [b], and [c] ask you to name the architectural designs, software development techniques, and systems engineering principles you follow. Objectives [d], [e], and [f] ask for proof that each named item shows up in the system. Write the identification document first. Without it the employment evidence has nothing to point at.

Not developing software answers [b] and [e], and nothing else.

Buying commercial software instead of building your own is a legitimate software development technique: state it under [b], and your procurement practice covers [e]. The other four objectives still stand. Architectural designs and systems engineering principles apply to any IT footprint, including a company that has never written a line of code.

Adopt principles from a published source instead of inventing them.

The security design principles in NIST SP 800-160 give you a menu. Pick the ones that fit and cite them. CIS Benchmarks or STIGs, both published hardening guides, serve as engineering principles and do double duty as the configuration settings CM.L2-3.4.2 asks for. Layered protection, least functionality, and deny by default are principles you already practice. The work is writing down which ones you chose.

Show employment through decisions you already made.

The cloud tenant you selected, the baseline that hardens your endpoints, the segmentation that isolates CUI (Controlled Unclassified Information): each is a design decision. For [d], [e], and [f], connect each adopted principle to the decision it drove. The evidence is a page in your system security plan tracing each principle to its implementation. That plan is the document describing how your system meets each requirement.

You define what counts as user functionality and what counts as system management.

Objectives [a] and [b] are definitions you write, and the definitions frame the assessment. Defining system management functionality as domain and tenant administration and user functionality as what a standard account can do is a workable framing. A least-privilege paragraph that never says what either term means gives the assessor nothing to test [c] against.

Separate accounts enforce the separation. Separate networks are optional.

The requirement allows physical or logical separation, and logical separation through access control is the ordinary implementation. Administrators hold a standard account for daily work and a privileged account for administration, and standard accounts cannot reach the administrative functions. This is the same account discipline AC.L2-3.1.6 requires, evidenced from the other side.

Prove [c] by showing what a standard user cannot do.

A demonstration that a normal account cannot open the admin center, install software, or reach management interfaces is direct evidence. Pair it with the definitions and the account inventory, and the requirement is covered without new infrastructure.

Jump servers and privileged access management platforms are upgrades, not requirements.

A dedicated administration host confines privileged sessions, and a privileged access management tool adds checkout and recording. Both earn roadmap space in a larger environment. Neither is needed to meet the objectives when account separation is clean.

This is an operating system property, not a file share setting.

The requirement targets leftover information in shared resources: memory, cache, and disk space reclaimed from one user and handed to another. A current, supported operating system provides the protection. Your work is proving you run current systems configured to keep it.

Evidence is the inventory plus the baseline.

Show supported operating system versions across the fleet, and users without administrative rights so they cannot read other users' profiles. Add the platform memory protections enabled in your baseline, such as kernel DMA protection and core isolation. A configuration report tying those settings to your endpoints answers [a].

Do not chase processor-level scenarios.

Side-channel and processor cache attacks are handled by the patching and flaw remediation you already run under SI.L2-3.14.1. The cases that matter here are shared computers and terminal servers where users can save files outside their own profile. Lock the public locations down.

List what the public can reach before deciding how it is separated.

Objective [a] is an inventory: the public website, the VPN (virtual private network) portal, and the mail gateway. Add anything else with a login page or a service listening for connections from the internet. Publicly accessible means reachable without credentials, so a portal that demands a password still belongs on the list, because its login page is the reachable part.

Separation is a subnetwork with default deny toward the inside.

The classic answer is a DMZ, a buffer network for public-facing components. Put those components on their own subnet or firewall zone. Deny traffic from that zone into the internal network by default, and allow it only by specific rule. Virtual LANs, firewall zones, and cloud network segmentation all qualify as logical separation.

Hosting public components outside your network is separation by construction.

A marketing website run by a third party on the third party's infrastructure never touches your internal network. Identify it under [a], record where it lives, and the separation for [b] is the fact that it shares nothing with the systems holding CUI.

Deny by default is a posture, not a long list of deny rules.

Objective [a] wants an implicit deny that catches everything you did not explicitly allow. A ruleset that blocks a list of ports and permits the rest is allow by default with deny exceptions, the opposite of the requirement. It fails the moment you forget a protocol: deny every TCP port, and UDP and ICMP still flow.

Outbound traffic is included, and it is the half that gets missed.

The requirement does not exempt outgoing connections. Set the default outbound action to block, then allow what the business needs: web on 80 and 443, DNS, DHCP, NTP, and the directory service ports if you run one. Build the outbound exception list by observing what the environment actually uses, then close the door.

Filtering by port is sufficient.

Allow rules keyed to ports and protocols meet both objectives. Per-destination address allowlists and per-application rules are tighter than the requirement asks and cost more to maintain than they return. Adopt them for your own reasons, not for this requirement.

Host firewalls managed centrally satisfy this at the endpoint.

Windows Defender Firewall with default deny pushed through Intune or Group Policy carries the requirement to laptops that never sit behind your perimeter. Rules delivered by mobile device management do not appear in the local firewall console. When you need evidence, export them from the management plane or query the MDM policy store with PowerShell.

With a VPN, this is one setting plus proof users cannot change it.

Disable split tunneling on the VPN (virtual private network) concentrator or client profile, so every packet from a connected device rides the tunnel. Lock the client configuration so users cannot re-enable it. Test one device, then keep the configuration export and the test note as evidence for [a].

Expect the printer problem and solve it deliberately.

Full tunneling breaks printing to home printers, because the local subnet disappears. Decide the answer up front: block device redirection, allow USB-attached printers, or accept no remote printing. Quietly re-enabling split tunneling to stop the complaints defeats the objective.

A cloud-only environment answers this at the endpoint.

With no on-premises system to tunnel into, the requirement does not vanish. The remote device itself becomes the boundary to defend. A host firewall denying unsolicited inbound connections, endpoint detection and response, and DNS or web filtering give the endpoint the controls a perimeter would. Each connection to your cloud tenant is then an individually secured TLS session rather than a bridge between networks. Write that architecture into your system security plan, the document that describes how your system meets each requirement, rather than claiming the requirement is not applicable.

Inventory the paths CUI travels, then name the mechanism on each.

Objective [a] is a list of the ways CUI (Controlled Unclassified Information) moves: email, file transfer, cloud sync, remote access, site-to-site links, scanner-to-server traffic. Give every path a cryptographic mechanism. TLS, the standard encryption protocol for internet connections, at version 1.2 or newer covers nearly all of them, and [c] becomes the configuration evidence per path. The path you never identified is the one the assessor finds.

The module must be validated, not just the algorithm.

CUI in transit outside your protected environment needs FIPS-validated cryptography: encryption tested and certified under the government's FIPS 140 program. Validation attaches to the cryptographic module, the software or hardware running the algorithm, not to the algorithm itself. On Windows, enable FIPS mode so TLS rides the operating system's validated modules, and verify each module's certificate on the NIST Cryptographic Module Validation Program list. SC.L2-3.13.11 carries the full validation story. This requirement is where transmission inherits it.

Email is the path that fails quietly.

Ordinary email negotiates opportunistic TLS, encryption used only when the receiving server supports it, and delivers anyway when the far end cannot. So you cannot show [c] for CUI sent to arbitrary recipients. Force TLS to the partner domains you exchange CUI with. Or encrypt the file itself with a FIPS-validated tool before attaching it. Or move the exchange to a controlled channel such as a secure file transfer service. Pick one answer per counterparty and write it down.

Physical safeguards are the narrow alternative, and radio is never one.

Objective [b] exists for the protected distribution system case: cabling protected against interception inside a controlled facility. It shelters unencrypted traffic on a wired segment inside your physical boundary. It never covers wireless, because the signal leaves the building no matter what the walls do.

This is network session termination. User sessions belong to AC.L2-3.1.11.

The objectives here are about connections: TCP sessions, VPN (virtual private network) tunnels, remote access links. Locking screens and ending user sessions is a different requirement. Keep the two separate in your system security plan, the document that describes how your system meets each requirement, so each points at its own mechanism.

Define the inactivity period, then show the configuration that enforces it.

Objective [a] is a number you choose and write down. [c] is the timeout configured to match. The idle connection timeout on your firewall and the session timeout on your VPN are the ordinary mechanisms. A vendor default counts once you document it as your defined period.

Termination at session end is mostly protocol behavior. Your job is the catch-all.

Connections close when a user disconnects or an application finishes, which covers [b]. The inactivity timeout under [c] is the backstop for sessions that never end cleanly, including the dangling connections browsers leave behind. Defining which network sessions require managed termination is within your power, and remote access sessions are the ones that matter.

List every place cryptography is employed. Each entry needs a key story.

Full-disk encryption recovery keys, TLS certificates, VPN secrets, backup encryption keys, and signing keys all belong on the list. Each needs an answer for how the key is created [a] and how it is stored, renewed, revoked, and destroyed [b]. The inventory is short in a small environment, and writing it is most of the work.

Never store a key where the data it protects lives.

A backup encryption key kept in the same repository as the backups means one compromised account yields both. Store recovery keys for full-disk encryption away from the device. Escrowing BitLocker keys to Microsoft Entra ID or Intune is the ordinary case. Keep backup keys in a separate access-controlled store. Check that no single account reaches both a key and the data it unlocks.

Cloud providers manage the keys for their services. Cite it, do not duplicate it.

For a service like Microsoft 365, the provider generates and manages the keys behind its encryption, and its shared responsibility documentation says so. Your side of [a] and [b] is the keys you hold: device encryption, certificates you issue or buy, and anything you generate yourself.

Certificates are keys with expiration dates. Assign the renewal.

Track certificates from an internal certificate authority in that system, and give externally purchased certificates an owner and a renewal reminder. An expired certificate is a key management failure that announces itself to every visitor.

Validated means a certificate for the module, not an approved algorithm.

AES is a FIPS-approved algorithm. Running it inside a module nobody validated does not satisfy [a]. Validation is a property of the cryptographic module, the software or hardware implementing the algorithm. The module is tested under FIPS 140 and listed with a certificate number by NIST's Cryptographic Module Validation Program (CMVP). For every product protecting the confidentiality of CUI (Controlled Unclassified Information), your evidence is that certificate number. A data sheet that says FIPS compliant is a marketing phrase, not a certificate.

The word when scopes the requirement. Find your encryption points first.

FIPS-validated cryptography is required where cryptography is the thing protecting CUI confidentiality: transmission beyond your protected environment, storage on devices that leave it, wireless and remote access. Inside the protected environment, physical safeguards can carry confidentiality, and encryption used for other purposes there does not need validation. Map the CUI flow, mark where encryption is the protection, and spend your validation effort exactly there.

On Windows, FIPS mode puts the operating system's validated modules to work.

Enable the FIPS policy setting through Group Policy or Intune so TLS and BitLocker use the validated modules, then record the module certificates for your Windows versions. Applications that call the operating system's cryptographic modules inherit that validation. Applications that ship their own cryptography do not, so check each product touching CUI for which case it is.

Encryption without validation is the one large gap the rules let you carry.

A Plan of Action and Milestones is the documented list of gaps you commit to close after assessment. 32 CFR 170.21(a)(2)(ii) permits SC.L2-3.13.11 on that plan only when encryption is employed but is not FIPS-validated. 32 CFR 170.24 scores that state as a three-point deduction, while every other requirement on a plan must be worth one point. Encryption not employed at all is a five-point deduction and cannot ride a plan. Encrypt now with what you have, then close the validation gap inside the 180-day conditional window.

One validated layer per CUI path is enough.

A FIPS-mode TLS session inside a VPN whose own module is unvalidated is still protected, because one end-to-end layer is validated. Decide which layer carries the validation for each path and record it, rather than trying to validate every layer at once. AC.L2-3.1.13 applies the same logic to remote access sessions.

Do not validate what is not protecting CUI.

Switches passing already-encrypted traffic, printers inside the physical boundary, and hashing inside an application are not employing cryptography to protect CUI confidentiality, so they carry no validation requirement. Money spent putting FIPS-validated firewalls in front of traffic that is already validated end to end buys nothing.

Laptop cameras and microphones are collaborative computing devices.

The requirement's discussion names networked whiteboards, cameras, and microphones, and excludes only dedicated video conferencing systems that activate when a participant connects the call. Inventory the built-in cameras and microphones across the fleet along with any room systems, and [a] is done. An organization with no conference room gear does not get to answer not applicable.

Indication of use is mostly built in. Write down what you rely on.

The hardware light beside the camera, the operating system's on-screen microphone indicator, and the meeting client's in-call display each signal a device in use, which answers [b]. A room device with no indicator gets a manual substitute: a posted notice or a locked door while in use.

Prohibit remote activation with configuration, and use camera covers where configuration cannot reach.

Disable auto-answer on room video units so nothing activates until someone accepts the call, and keep remote control of endpoint cameras away from standard users. Physical camera covers are a zero-cost supplement for [c].

Mobile code is code that arrives over the network and runs without installation.

JavaScript in every web page, active content in PDF files, browser plug-ins, and script attachments are the subject: the assessment guide names Java, JavaScript, ActiveX, Postscript, PDF, Flash, and VBScript. It has nothing to do with applications on mobile phones, and a policy about installing unauthorized software misses it entirely.

Allowing is controlling, when the decision is written down.

Control under [a] means deliberate, documented decisions about which mobile code runs. Permitting JavaScript in managed browsers while prohibiting legacy plug-ins and unsigned macros is control. Enforce the decisions through browser management and the Office macro settings in your configuration baseline, with an exception path for the business need that arrives later.

Monitoring rides your existing malware protection.

Objective [b] is satisfied by the tooling you run under SI.L2-3.14.2. State which mobile code technologies your endpoint protection and web filtering inspect, and keep the alerts and their review as the record. A blocked script in the detection history is monitoring evidence.

This covers voice as network traffic, not the copper phone line.

Plain telephone service is outside this requirement. VoIP is data on a network and gets treated like any other protocol. A true no-VoIP environment can assess this requirement as not applicable. But Teams, Zoom, and softphones are VoIP technologies, so no VoIP at all is rarely true. State what you run and how it is controlled.

Control is naming the approved service. Monitoring is watching its traffic.

Authorize the VoIP solution in policy and configuration, and restrict use to the approved product [a]. Monitor through its logs, and watch your network monitoring for voice traffic that is not the approved service [b]. Patching the VoIP software with the rest of the fleet under SI.L2-3.14.1 is part of controlling it.

Keep CUI out of the phone system rather than pulling the phone system into scope.

Segment VoIP from the environment holding CUI (Controlled Unclassified Information), and prohibit CUI discussion over it in policy and training. When a voice conversation about CUI must happen, use a service authorized to carry CUI, such as Teams in GCC High. State compliance through separation in your system security plan, the document that describes how your system meets each requirement, instead of arguing the requirement away.

Session authenticity is confidence that each end is who it claims, for the whole session.

The threats are interception in the middle, session hijacking, and injected traffic. A current version of TLS, the standard encryption protocol for internet connections, with valid certificates provides the protection. The handshake authenticates the endpoint, and the session keys defend the exchange against takeover.

Enforce current TLS and keep certificates from expiring.

Configure servers, the VPN, and management interfaces to current TLS with weak protocol versions disabled, and renew certificates before expiry so the trust chain never lapses. This is largely the same configuration work as SC.L2-3.13.8, evidenced from the authenticity side.

Sweep for the sessions that are not browser traffic.

VPN tunnels, SFTP transfers, and application integrations each ride a protocol with its own authentication story. List the session types in your environment, and confirm each uses a protocol that authenticates the endpoints. Keep a policy naming the approved protocols, so a new one does not arrive unexamined.

Encryption and physical protection both satisfy this requirement.

Objective [a] asks that the confidentiality of CUI (Controlled Unclassified Information) at rest is protected, not that it is encrypted. A server that never leaves an access-controlled room can rest on physical protection. The assessment guide's own example accepts a sign-out and locked-closet procedure for devices that cannot be encrypted.

Encrypt anyway. The argument is worth less than the checkbox.

Full-disk encryption is built into the operating systems you already run and removes the burden of proving the physical story asset by asset. Reserve the physical justification for equipment that genuinely cannot encrypt.

Anything that leaves the protected area is encrypted, not argued.

Laptops, phones, portable drives, and backup media are outside your physical safeguards the moment they move. AC.L2-3.1.19 and MP.L2-3.8.6 make encryption explicit for mobile devices and transported media, and the validation question for that encryption belongs to SC.L2-3.13.11.

Components that never store CUI meet this by keeping it that way.

A device that only processes or relays CUI, with administrative controls keeping CUI from being written to it, has no CUI at rest to protect. Document the control that keeps storage off the asset. If CUI lands on it anyway, it is a storage asset and needs the protection.

Write three timeframes before you touch a patch.

Objectives [a], [c], and [e] each demand a specified time: how quickly flaws are identified, how quickly they are reported, and how quickly they are corrected. The remaining objectives, [b], [d], and [f], are proof you meet those times. Numbers come first: a scan cadence, a reporting cadence, and remediation windows by severity, written into policy.

Reporting is the step that fails organizations that patch well.

Scanning and fixing without a documented reporting step leaves [c] and [d] with no evidence. Reporting means the identified flaws land somewhere reviewable on a schedule: a generated report, a ticket, an email to the responsible person. When one person runs the whole loop, the report is still written: the dated list of flaws produced before patching begins is the reporting evidence.

Flaws are more than missing patches.

Configuration weaknesses found by scans, findings from the security assessments CA.L2-3.12.1 requires, and weaknesses surfaced during incident response are all system flaws in this requirement's sense. Route them through the same identify, report, and correct loop with the same timeframes.

Evidence is the loop running end to end.

A vulnerability report dated inside your identification window covers [b]. The ticket or emailed report with its timestamp covers [d]. Patch deployment history showing correction inside the window covers [f]. A tracking spreadsheet with an open tab and a closed tab is a complete system for a small environment.

Do not put a review board in front of routine patches.

A monthly approval gate for operating system updates slows correction and returns no security. You own your change process. Classify routine patches as standard changes that deploy automatically to a test group and then to production on defined days. Save the approvals for changes that warrant them.

Objective [a] is a list of locations, so write the list.

Designated locations are where malicious code can enter or take hold: workstations, servers, the email service, the web gateway or boundary firewall. Name them in your system security plan, the document that says how each requirement is met. The standard footprint is protection on every workstation and server operating system plus scanning where mail and web traffic enter.

Objective [b] is coverage at every location on the list.

Deploy the anti-malware or endpoint detection agent to each named endpoint and server, and turn on the mail and web scanning your platform provides. Reconcile the protection console against the asset inventory: a machine in the inventory with no agent is the finding waiting to be written.

Modern endpoint detection and response satisfies the requirement.

The objective asks for protection from malicious code, not for a signature-based product category. Endpoint detection and response, the tooling that watches program behavior instead of only matching known malware, meets it with real-time protection on. Reputation and behavior engines count. What matters is that every designated location has it and that it reports centrally.

Email and web are the delivery paths. Designate them.

Malicious code arrives through mail attachments, links, and downloads far more than through inbound network exploits. A designation list that stops at endpoints leaves the entry points unnamed under [a]. Include the mail filtering and web protection you already have.

Subscribe to the sources that match your stack, and name them.

Alerts from CISA, the federal cybersecurity agency, plus the security bulletins for the products you actually run are the working set. Objective [b] is met by receiving and reviewing them on a cadence tied to how often they arrive. The named source list in your procedure is the first thing an assessor asks for.

Decide response actions before the advisory arrives.

Objective [a] wants the playbook in advance: assess applicability, check exposure, patch or reconfigure under your SI.L2-3.14.1 timeframes, and notify the people affected. Three sentences in the procedure cover it.

Keep receipts that action followed.

Objective [c] is the record: the advisory reviewed, the applicability call, and the ticket or change that followed when it applied. An advisory judged not applicable is also a record. A one-line log entry shows the process ran.

Automatic updates are the implementation. Anything manual is a liability.

Malware changes daily or faster, and [a] asks that protection mechanisms update when new releases are available. Turn on automatic definition and engine updates in the platform's policy and let the vendor's release cadence be your cadence.

The work is proving that automatic updates happen.

An auto-updating platform leaves no manual trail, so build one. Keep the policy export showing updates enabled and the vendor's documentation describing its release behavior. Add a console report showing agent and definition versions current across the fleet. Those three artifacts answer [a].

Watch for the agents that stop updating.

A machine with a stale definition version is this requirement failing quietly on one asset. Review the console's outdated-agent view on a schedule and chase the stragglers. The review record doubles as evidence the mechanism works.

The requirement contains two duties, and real-time scanning alone fails one of them.

Periodic scans of the system under [a] and [b] and real-time scans of external files under [c] are independent clauses. Define a scan frequency, run the scans on it, and keep real-time protection on. Continuous protection with no defined periodic scan leaves [a] with no number and [b] with no proof.

You choose the scan type and the frequency. Then match the configuration.

The requirement never says full scans. A weekly quick scan is a defensible definition when real-time protection covers file activity. What fails is a configuration that does not match your written frequency. Say what you do, do what you say, and export the schedule as evidence.

Real-time means on download, open, or execute, and a USB stick is an external source.

Endpoint real-time protection covers files as they arrive and run, and the email service's attachment scanning covers the main delivery path before files reach the endpoint [c]. Confirm scanning fires on removable media, because files copied from a USB drive are files from an external source.

Endpoint products without a scheduled scan feature need a documented equivalence.

Some platforms are designed for continuous scanning and offer no periodic scan to schedule. Collect the vendor's documentation of how every file is examined regardless, and define your frequency in those terms. Put the rationale in your system security plan, the document that says how each requirement is met, before an assessor asks.

Blocking is not monitoring.

A firewall that drops traffic by rule is control. Monitoring is detection plus review. The intrusion prevention and gateway inspection features of the firewall you already own, turned on and alerting, create the detection. A person reviewing the alerts is what makes it monitoring.

Cover the system and both traffic directions.

Objective [a] is the systems themselves, covered by endpoint detection and log review. Objectives [b] and [c] are inbound and outbound traffic. Outbound is the half that catches real attacks: beaconing, the steady call home that malware makes, unauthorized data leaving, and connections to known-bad infrastructure. Enable inspection in both directions and alert on both.

Alerts need a named reader and a cadence.

Route detections to a mailbox or channel someone owns. Put the review on a schedule with a checklist: firewall alerts, endpoint detections, and the logs of the systems holding CUI, the Controlled Unclassified Information you protect. The review record is the evidence for all three objectives, and the records AU.L2-3.3.1 retains are what the review reads.

Scale the tooling to the environment, not to a security operations center ideal.

A small environment meets this with the firewall's security services alerting by email, endpoint detection and response, and a weekly review. A SIEM, the platform that collects and correlates alerts and logs in one place, earns its cost when alert volume outgrows a mailbox. Buying one does not satisfy the objectives. Reviewing what it raises does.

Objective [a] is your acceptable use policy doing double duty.

Define authorized use of the system: who may use it, for what, with which software and services. The acceptable use policy people sign under your awareness program is the definition. Keep it specific enough that unauthorized has a meaning.

Not every prohibition needs a technical detector.

Objective [b] asks that unauthorized use is identified, not that every policy line has a sensor. Technical items get technical detection: alerts on unauthorized software from your inventory tooling, connections refused for unenrolled devices, log review flagging odd hours or odd volume. Non-technical prohibitions, such as photographing a screen, are covered by policy, training, and the duty to report that you place on everyone.

The mechanisms are ones you already run.

Endpoint detections, the log review from AU.L2-3.3.1, application inventory reports, and the network monitoring from SI.L2-3.14.6 all surface use outside the definition. Name them as the identification mechanisms in your system security plan, the document that says how each requirement is met. Objective [b] then points at running machinery instead of intent.