Protect the routes, sessions and systems that carry CUI.
Work through all 16 requirements and 41 assessment objectives. Map external and internal boundaries, separate public and management functions, verify allowed traffic and remote routing, and check sessions, cryptography, collaborative devices, mobile code, voice and stored CUI.
Sources reviewed October 28, 2026. These instructions have not been tested in a Microsoft tenant. This guide does not establish compliance or replace an official assessment. Suggested checks and manual worksheet states are working aids.
Map the real boundary. Include external and key internal crossings, public services, management interfaces, remote endpoints and provider duties.
Define intended behavior. Record approved flows, separation, secure architecture and development decisions, session end conditions and inactivity periods.
Follow confidentiality and trust. Link transmission and stored copies to protection, key lifecycle, actual module assurance and session authenticity.
Check devices and execution. Include shared resources, collaborative-device activation and indications, mobile code and VoIP controls and monitoring.
Keep actual observations separate. A plan, default setting or encrypted flag is not proof of all objectives. Assign each unresolved check to an owner.
Use fictional records, approved test identities and harmless traffic for exercises. Do not change production routes, capture staff, export keys or disrupt sessions as an exercise. Keep CUI, secrets, addresses, packet captures and detailed evidence in approved restricted storage. This website does not receive completed worksheets or answers.
Find where communications enter, leave or cross trust levels. Monitoring, traffic control and protection each need evidence at external and key internal boundaries.
Official requirement and assessment objectives
Monitor, control, and protect communications (i.e., information transmitted or received by organizational systems) at the external boundaries and key internal boundaries of organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.1
Objective
Official text
3.13.1[a]
the external system boundary is defined.
3.13.1[b]
key internal system boundaries are defined.
3.13.1[c]
communications are monitored at the external system boundary.
3.13.1[d]
communications are monitored at key internal boundaries.
3.13.1[e]
communications are controlled at the external system boundary.
3.13.1[f]
communications are controlled at key internal boundaries.
3.13.1[g]
communications are protected at the external system boundary.
3.13.1[h]
communications are protected at key internal boundaries.
What to do
Draw the real boundaries
Map internet, partner, remote-access, cloud and internal trust crossings. Include CUI services, management networks and provider responsibilities. A building perimeter or Azure subscription is not automatically the complete system boundary.
Assign monitoring and enforcement
For each crossing name its owner, permitted flows, logging/review route and safeguards. Review both directions and alternate routes. Boundary logs need an accountable reviewer and a response process; an installed firewall is not proof of monitoring.
Check representative flows
With authorization, inspect effective rules and observe harmless allowed and denied traffic. Check collection and review of relevant events at both external and internal points. Retain restricted references rather than addresses, captures or CUI in the public templates.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.1[a]
Trace all external entry and exit paths against the approved system diagram.
Records to keep: Versioned external boundary, interfaces, providers and owner approval.
3.13.1[b]
Identify key internal trust crossings, including management and CUI segments.
Records to keep: Internal boundary rationale, connected components and enforcement points.
3.13.1[c]
Trace a harmless external traffic event through collection and review.
Records to keep: External log source, actual event reference, reviewer and disposition.
3.13.1[d]
Trace a harmless event crossing a key internal boundary through monitoring.
Records to keep: Internal event source, coverage limits and actual review reference.
3.13.1[e]
Compare external inbound and outbound behavior with approved traffic rules.
Records to keep: Effective external rules and actual allowed/denied flow checks.
3.13.1[f]
Check enforcement between internal trust segments with approved test traffic.
Records to keep: Internal rule scope, representative results and untested paths.
3.13.1[g]
Verify confidentiality and other approved protection for external communications.
Records to keep: External safeguard design, effective configuration and observed protection.
3.13.1[h]
Verify protection of communications at the selected internal boundaries.
Records to keep: Internal safeguard configuration, provider evidence and actual checks.
Records to keep
Boundary and flow inventory with separate external/internal owners.
Monitoring review, enforcement checks and protection evidence linked to each crossing.
If a check fails
Contain an uncovered route through approved change, preserve relevant events and assess exposure. If a rule blocks essential traffic, restore the last approved scoped configuration using the recovery path, then recheck both protection and service.
Working with a small budget
Use existing diagrams, firewall records and Windows Firewall where appropriate. Central log collection, retention and cloud traffic processing can add cost; a free register does not create monitoring.
Build security into architecture, software and engineering
Select security principles before implementation, then show that the architecture, development work and system lifecycle actually use them.
Official requirement and assessment objectives
Employ architectural designs, software development techniques, and systems engineering principles that promote effective information security within organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.2
Objective
Official text
3.13.2[a]
architectural designs that promote effective information security are identified.
3.13.2[b]
software development techniques that promote effective information security are identified.
3.13.2[c]
systems engineering principles that promote effective information security are identified.
3.13.2[d]
identified architectural designs that promote effective information security are employed.
3.13.2[e]
identified software development techniques that promote effective information security are employed.
3.13.2[f]
identified systems engineering principles that promote effective information security are employed.
What to do
Identify the three kinds of decisions
Document architectural choices such as trust separation and least privilege; development techniques such as threat modeling, code review, dependency review and safe error handling; and engineering principles such as minimized attack surface, secure defaults and lifecycle verification.
Apply them to actual changes
Link each principle to a design decision, software release or system change. Include configuration scripts, integrations and acquired software; where a supplier performs development, identify the responsibility and obtain relevant assurance rather than declaring development irrelevant.
Review implementation and change
Sample diagrams against deployed boundaries, releases against required reviews, and system acceptance against security criteria. Track exceptions, defects and approved correction. A policy list alone does not demonstrate use.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.2[a]
Select the architectural security designs appropriate to the actual CUI system.
Records to keep: Approved design principles and boundary/trust decisions.
3.13.2[b]
Identify secure development techniques for local code, scripts and acquired software.
Records to keep: Development standards, supplier responsibilities and release criteria.
3.13.2[c]
Identify engineering security principles across acquisition, operation and retirement.
Records to keep: Engineering standards and lifecycle/acceptance criteria.
3.13.2[d]
Compare a deployed design with the approved security architecture.
Records to keep: Design review, implementation reference and discrepancy resolution.
3.13.2[e]
Trace a software or script release through the selected development techniques.
Records to keep: Threat model, code/dependency review and relevant verification records.
3.13.2[f]
Trace an actual system change through engineering security criteria.
Records to keep: Requirements, security acceptance, change review and correction evidence.
Records to keep
Architecture, development and engineering standards with responsible roles.
Actual design, release and acceptance reviews linked to implementation.
If a check fails
Hold a change whose required security review is incomplete. Resolve design gaps before wider release and use the approved rollback if deployed behavior violates a boundary. Keep supplier assurance gaps visible.
Working with a small budget
Use existing change records, peer review and available development tools first. Specialized testing and supplier assurance may require expertise; tool ownership alone does not show secure development.
Ordinary use must not expose the controls that administer systems. Identify both functions and enforce their separation through access, interfaces and operating practices.
Official requirement and assessment objectives
Separate user functionality from system management functionality.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.3
Objective
Official text
3.13.3[a]
user functionality is identified.
3.13.3[b]
system management functionality is identified.
3.13.3[c]
user functionality is separated from system management functionality.
What to do
List user and management functions
Record ordinary file, application and collaboration tasks separately from account administration, security policy, backups, network changes, hypervisor and application administration.
Separate identities and access paths
Use dedicated administrative roles/accounts and protected management interfaces appropriate to the design. AD groups, local privileges and Azure/Entra roles require separate review. A different username with the same unrestricted workstation and access paths may leave the underlying separation weak.
Verify ordinary-user boundaries
Use an approved nonadministrative test identity to confirm it can perform its job but cannot invoke system management functions. Review management network exposure and administrator session use separately.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.3[a]
Identify ordinary user functions for each in-scope system.
Records to keep: Approved role/task list and user application scope.
3.13.3[b]
Identify management functions and their authorized operators/interfaces.
Records to keep: Administrative function inventory, privilege roles and management paths.
3.13.3[c]
Test separation between ordinary use and management functions safely.
Records to keep: Effective permissions, protected management routes and allowed/denied task results.
Records to keep
User and management function inventories.
Role assignments, management path restrictions and safe separation checks.
If a check fails
Restrict unintended management access through a scoped approved change. Preserve legitimate emergency access and verify it before removing a route. Investigate use of exposed administrative functions.
Working with a small budget
Existing AD groups, local roles, firewall restrictions and separate administrator accounts can help. Optional privileged identity/access features need their own licenses and do not replace separation testing.
Shared hosts and services can expose one user's information to another through temporary files, memory, profiles, print queues or other reused resources.
Official requirement and assessment objectives
Prevent unauthorized and unintended information transfer via shared system resources.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.4
Objective
Official text
3.13.4
Determine if unauthorized and unintended information transfer via shared system resources is prevented.
What to do
Identify what is shared
Include multi-session AVD hosts, shared storage, printers/spoolers, application caches, temporary directories and reused compute resources. Define authorized sharing separately from accidental residue.
Apply isolation and safe reuse
Use supported OS/application isolation, appropriate permissions, profile handling and resource clearing/reuse controls. Do not grant ordinary users local administrator rights on shared AVD hosts. Review supplier isolation evidence where the customer cannot inspect the underlying resource.
Check cross-user access with harmless data
Use two approved test identities and made-up files. Check one user cannot retrieve the other's unauthorized temporary, cached or retained content after a task/session and reuse. Do not inspect real staff data or dump memory as an exercise.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.4
Check shared resource isolation and reuse prevents both unauthorized and unintended transfer.
Records to keep: Shared-resource inventory, isolation/cleanup rules, provider evidence and safe cross-user checks.
Records to keep
Shared-resource owners, trust assumptions and isolation controls.
Actual harmless cross-user checks, resource-reuse evidence and limits.
If a check fails
Stop affected sharing or reuse under an approved containment decision, preserve necessary evidence and assess exposure. Correct isolation and verify with harmless data before reopening the resource.
Working with a small budget
Use supported built-in isolation and existing permissions first. Separate hosts or services may be needed where trust assumptions differ, increasing cost.
A public application needs a deliberately separated network area. Merely giving its subnet a public-facing name does not isolate it.
Official requirement and assessment objectives
Implement subnetworks for publicly accessible system components that are physically or logically separated from internal networks.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.5
Objective
Official text
3.13.5[a]
publicly accessible system components are identified.
3.13.5[b]
subnetworks for publicly accessible system components are physically or logically separated from internal networks.
What to do
Inventory public components
Include public websites, gateways, APIs, remote administration endpoints and provider-hosted components. Record the public interfaces, business purpose, backing services and management routes.
Design a separated subnetwork
Use physical or logical separation with controlled connections to internal services. For Azure review subnet and network interface NSGs, route tables, peering and other enforcement points. An NSG can contain default virtual-network allows, so association alone does not establish separation.
Test constrained reachability
Use approved harmless checks to confirm the public service works and unnecessary internal access is denied. Include access from the public component toward internal systems, management access and alternate paths.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.5[a]
Reconcile the inventory with actual publicly accessible components.
Records to keep: Public interface/service inventory, owner and external exposure review.
3.13.5[b]
Check public component subnetworks are separated from internal networks.
Records to keep: Network design, effective route/rule evidence and safe separation checks.
Records to keep
Public services and backing dependencies.
Separated network design, approved flows and verified isolation.
If a check fails
Remove unintended public/internal exposure through approved change while retaining a safe management route. If internal services were reachable unexpectedly, involve incident handling and review related paths.
Working with a small budget
Use existing segmented network equipment and appropriate Azure network controls. Additional firewalls, gateways or separate hosting may add cost. Separate subnet names are not a control.
Deny traffic by default and permit explicit exceptions
Define the traffic the system needs, then verify that everything else in scope is denied. Inbound-only restrictions leave outbound and internal paths unanswered.
Official requirement and assessment objectives
Deny network communications traffic by default and allow network communications traffic by exception (i.e., deny all, permit by exception).
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.6
Objective
Official text
3.13.6[a]
network communications traffic is denied by default.
3.13.6[b]
network communications traffic is allowed by exception.
What to do
Approve necessary flows
Record source, destination, protocol, port/service, direction, purpose, owner and review/end date using restricted references. Include DNS, identity, time, updates, monitoring and recovery dependencies before changing defaults.
Inspect effective defaults and precedence
Review host and network layers together. Azure NSGs include low-priority default rules, including virtual-network and outbound internet allows. Lower numeric priorities win. Add approved higher-priority controls where needed; do not assume the presence of an NSG means deny-all. Windows Firewall defaults also need checking per profile and direction.
Stage and verify exceptions
Use an authorized small scope with recovery access. Check an approved flow succeeds and an unapproved flow is blocked in each relevant direction. Record effective results and exceptions; never deploy a blanket deny without dependency and recovery planning.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.6[a]
Check effective default-deny behavior across relevant traffic directions and layers.
Records to keep: Effective default actions, precedence, routes and actual unapproved-flow denial checks.
3.13.6[b]
Trace allowed traffic to specifically approved exceptions.
Records to keep: Flow approval, narrowly scoped rule, owner, review date and permitted-flow results.
Records to keep
Approved traffic exception register.
Effective default/precedence evidence and allowed/denied test observations.
If a check fails
If an essential service fails, use the approved recovery path and restore only the necessary authorized exception. If unapproved traffic succeeds, contain the route and recheck overlapping defaults and rules.
Working with a small budget
Built-in host filtering and existing network controls may meet parts of the need. Engineering dependency maps and monitoring still takes time; Azure gateways/firewalls and logs may be separately billed.
Check whether a remote device can connect to organizational systems while also communicating with outside resources through another connection. AVD clipboard or drive redirection is a different issue.
Official requirement and assessment objectives
Prevent remote devices from simultaneously establishing non-remote connections with organizational systems and communicating via some other connection to resources in external networks (i.e., split tunneling).
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.7
Objective
Official text
3.13.7
Determine if remote devices are prevented from simultaneously establishing non-remote connections with the system and communicating via some other connection to resources in external networks (i.e., split tunneling).
What to do
Map remote-device connections
Identify VPN clients, wired/wireless adapters, secondary interfaces, IPv4/IPv6, routes and local/external destinations while connected. Record client/platform and management authority. A network diagram of only the server misses endpoint routing.
Choose supported routing and endpoint controls
Use the approved remote-access design to prevent simultaneous outside paths. For Azure VPN Client, optional routing documentation applies to configured point-to-site OpenVPN connections and client/platform versions. Forced routing needs a designed egress path; Azure VPN Gateway does not itself provide internet connectivity. Do not paste a route as a complete design.
Verify actual simultaneous behavior
With approved test resources, compare routes and permitted organizational access with attempts over other external paths while connected. Include secondary adapters and IPv6 where present, reconnect/restart and relevant client types. Keep packet contents and addresses restricted.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.7
Verify remote devices cannot use the prohibited simultaneous organizational and other external connections.
Records to keep: Approved remote-access topology, effective client routes/controls and harmless concurrent-path checks with client/platform limits.
Records to keep
Remote-device and VPN/client scope, route policy and approved egress design.
Actual simultaneous-path checks and unresolved alternative interfaces.
If a check fails
If a bypass exists, suspend the affected remote path or apply approved containment. Correct routing and endpoint controls in a test scope, retain recovery connectivity and check business dependencies before wider rollout.
Working with a small budget
Use supported existing VPN/client controls where suitable. Forced-tunnel egress and managed endpoints can add cost. AVD redirection restrictions alone do not satisfy this requirement.
Identify how confidentiality is protected on each transmission path. The requirement permits cryptography or alternative physical safeguards that actually protect the transmission.
Official requirement and assessment objectives
Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI during transmission unless otherwise protected by alternative physical safeguards.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.8
Objective
Official text
3.13.8[a]
cryptographic mechanisms intended to prevent unauthorized disclosure of CUI are identified.
3.13.8[b]
alternative physical safeguards intended to prevent unauthorized disclosure of CUI are identified.
3.13.8[c]
either cryptographic mechanisms or alternative physical safeguards are implemented to prevent unauthorized disclosure of CUI during transmission.
What to do
Choose the safeguard per path
Map browser, file, email, service-to-service, backup, remote session and voice paths that carry CUI. Identify the cryptographic mechanism and relevant termination points. If relying on alternative physical safeguards, document why they protect the complete path and obtain the appropriate approval.
Implement the selected protection
Configure supported protocols and endpoints, verify certificates/identity and avoid unprotected fallback. Link cryptography to key management and the module assurance review in 3.13.10 and 3.13.11. A TLS label on the front end does not establish protection after a proxy terminates encryption.
Check complete paths
Use harmless data and approved observation to verify the negotiated protection across each segment. For a physical alternative, inspect the actual protected route/access rather than treating a private IP or internal network as physical protection.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.8[a]
Identify the cryptographic mechanisms selected to protect transmission confidentiality.
Records to keep: Flow-to-protocol/module mapping, endpoints and intended protection.
3.13.8[b]
Identify any alternative physical safeguards selected for transmission confidentiality.
Records to keep: Physical route, safeguards, rationale and approval; explicit record where none are relied on.
3.13.8[c]
Verify the chosen cryptographic or physical protection is implemented on actual CUI paths.
Records to keep: Effective segment protection, physical inspection where used and safe verification results.
Records to keep
Transmission path and safeguard decisions.
Actual protection verification and linked key/module or physical evidence.
If a check fails
Stop the affected CUI transfer if protection cannot be established. Use an approved protected route, correct the fault and assess any prior exposure. Never bypass certificate warnings to continue.
Working with a small budget
Supported TLS/IPsec capabilities may already be available. Certificate operations, suitable gateways and physical protection still need resources; free encryption does not prove validated implementation.
Terminate connections at session end and inactivity
An idle screen lock, a browser timeout message or an AVD disconnect is not by itself proof that the associated network connections ended.
Official requirement and assessment objectives
Terminate network connections associated with communications sessions at the end of the sessions or after a defined period of inactivity.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.9
Objective
Official text
3.13.9[a]
a period of inactivity to terminate network connections associated with communications sessions is defined.
3.13.9[b]
network connections associated with communications sessions are terminated at the end of the sessions.
3.13.9[c]
network connections associated with communications sessions are terminated after the defined period of inactivity.
What to do
Define inactivity periods
Have the system owner define applicable inactivity periods and session types, including remote access, administrative sessions, application sessions and supporting connections. Record exceptions and behavior required at normal session end without inventing a universal timeout.
Configure the actual termination mechanism
Match application, gateway, VPN, host and remote-session controls to the design. Review what each setting actually ends: display access, application authorization, user session or network connection. Account for background traffic, keepalives and disconnected sessions.
Observe both end conditions
Use an approved test session with harmless data. Observe connection state before and after normal end, then separately after the defined inactive interval. Record actual elapsed time, affected connections and any remaining session path. Avoid disrupting real users or losing unsaved work.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.9[a]
Confirm approved inactivity periods for the relevant communications sessions.
Records to keep: Session inventory, owner-approved interval and exception rationale.
3.13.9[b]
Observe associated network connections terminate after normal session end.
Records to keep: Authorized session-end observation, connection states and residual-path review.
3.13.9[c]
Observe termination after the defined inactivity period.
Records to keep: Test start/idle/end times, actual connection state and keepalive or client limits.
Records to keep
Session types, termination owners and defined inactivity periods.
Separate normal-end and idle-end observations with residual connections.
If a check fails
If connections persist, contain the affected session path and correct the responsible layer. If legitimate work is interrupted, restore approved settings through change control and reassess the interval without silently disabling termination.
Working with a small budget
Use application and existing network/host timeout controls first. Central policy or advanced session management may need licensing. Manual sign-out instructions alone do not demonstrate automatic inactivity termination.
Keys need accountable establishment and management wherever cryptography is used, including provider-managed keys and recovery material.
Official requirement and assessment objectives
Establish and manage cryptographic keys for cryptography employed in organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.10
Objective
Official text
3.13.10[a]
cryptographic keys are established whenever cryptography is employed.
3.13.10[b]
cryptographic keys are managed whenever cryptography is employed.
What to do
Inventory key uses and ownership
Record cryptographic purpose, system/provider, key identifiers, generation/import responsibility, approved algorithms/modules and authorized roles. Use references only; never enter private keys, secrets, recovery passwords or seed material in a worksheet.
Define the complete lifecycle
Specify authorized generation, distribution, storage, access, rotation/replacement, backup/recovery, revocation and retirement according to the actual technology and obligations. Record compromise handling, dependencies, provider duties and retention/recovery needs before any destructive action.
Verify operations without disclosing material
Review access and lifecycle records. Rehearse authorized recovery with harmless test data and approved test keys in a suitable environment. Check provider evidence and expiry/change notifications. A vault name or automatic rotation switch does not show all dependent systems can use a replacement.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.10[a]
Trace each cryptographic use to properly established keys and accountable responsibility.
Records to keep: Key-use inventory, generation/establishment evidence and provider responsibility.
3.13.10[b]
Check ongoing protection, access, replacement, recovery and retirement of keys.
Records to keep: Lifecycle policy, actual access/operation records, recovery check and compromise procedure.
Records to keep
Key identifiers and lifecycle owners, excluding key values.
Actual establishment, access, rotation/recovery and retirement evidence references.
If a check fails
For suspected key compromise, invoke incident and key-management procedures. Coordinate replacement and dependent services; do not delete, export or rotate production keys as a training step. Preserve required recovery and evidence.
Working with a small budget
Use supported existing platform key management and restricted records where suitable. Managed vaults/HSMs and customer-managed keys add cost and operational responsibility; provider-managed keys still require responsibility evidence.
Verify the actual FIPS-validated cryptographic module
FIPS assurance is about the actual module, version, approved operating conditions and certificate status. An algorithm name, TLS certificate or BitLocker encrypted flag is insufficient.
Official requirement and assessment objectives
Employ FIPS-validated cryptography when used to protect the confidentiality of CUI.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.11
Objective
Official text
3.13.11
Determine if FIPS-validated cryptography is employed to protect the confidentiality of CUI.
What to do
Identify the deployed implementation
For each CUI confidentiality use, record product/service, OS/build, cryptographic module and exact version, operational environment and cryptographic function. Determine whether the application actually calls the claimed module; provider services need service-specific assurance evidence.
Match validation and Security Policy
Locate the applicable NIST CMVP certificate and module Security Policy. Check exact version/environment, approved mode, configuration and caveats, plus current certificate status and applicable transition requirements. Algorithm validation or a vendor statement alone is not module validation. Follow Microsoft release-specific documentation for Windows.
Review the supported deployment
Compare actual configuration and key setup with all relevant Security Policy conditions. A legacy FIPS policy switch is not universal proof. Do not downgrade Windows to an obsolete release to match a certificate. If assurance is unresolved, choose a supported appropriately validated implementation with qualified review and record the gap.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.11
Trace every CUI confidentiality cryptographic use to the actual validated module in its approved deployment conditions.
Records to keep: Module/version/environment, CMVP certificate/status/date, Security Policy conditions, effective configuration and application/provider linkage.
Records to keep
CUI cryptographic uses linked to module and version.
Certificate/status and Security Policy review, deployed conditions and unsupported/unknown coverage.
If a check fails
Do not assert FIPS coverage when the module or deployment cannot be matched. Escalate the gap, protect CUI using an approved alternative and plan a supported change. Never expose keys or alter production cryptography merely to obtain a screenshot.
Working with a small budget
Official module certificates and Security Policies are public. Mapping complex applications or cloud services may require supplier assistance. Buying an encrypted product does not resolve assurance automatically.
Prohibit remote activation and show collaborative-device use
People near a camera, microphone or other collaborative device need an indication when it is in use, and remote activation must be prohibited.
Official requirement and assessment objectives
Prohibit remote activation of collaborative computing devices and provide indication of devices in use to users present at the device.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.12
Objective
Official text
3.13.12[a]
collaborative computing devices are identified.
3.13.12[b]
collaborative computing devices provide indication to users of devices in use.
3.13.12[c]
remote activation of collaborative computing devices is prohibited.
What to do
Inventory collaborative devices
Include room systems, webcams, microphones, smart collaboration equipment and relevant host/client redirection. Identify owners, activation paths, local controls and visible/audible indications in the actual room or workstation.
Apply activation restrictions and indications
Use supported device/OS/application settings and physical controls where appropriate. Review Windows camera/microphone settings with documented desktop-app limitations. A meeting invitation or a privacy toggle alone does not establish remote activation is prohibited across every device.
Check safely in an empty test setting
With permission and no real staff or visitor capture, verify local users receive the intended in-use indication and that relevant remote activation paths fail. Record actual device/app/version behavior and any uncovered control path.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.12[a]
Reconcile devices and activation paths with the collaborative-device inventory.
Records to keep: Device type/location reference, owner, app and remote-control paths.
3.13.12[b]
Observe the indication users present receive while an approved test device is in use.
Records to keep: Harmless device-use observation, actual indicator and visibility limitations.
3.13.12[c]
Verify remote activation is prohibited for relevant control paths.
Records to keep: Effective restrictions, physical controls where used and safe denied-activation checks.
Records to keep
Device and activation-path inventory.
Actual indicator and remote-activation prohibition checks.
If a check fails
Disable or disconnect the affected collaborative function under an approved procedure until activation/indication can be assured. Preserve relevant records and address possible exposure without recording people as an investigation shortcut.
Working with a small budget
Existing device switches, shutters and supported privacy settings can help. Room hardware or application controls may need replacement or licensing; verify actual behavior rather than relying on labels.
Mobile code includes code transferred from another system and executed locally, such as scripts, browser-delivered code and macros. It is not simply software on mobile phones.
Official requirement and assessment objectives
Control and monitor the use of mobile code.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.13
Objective
Official text
3.13.13[a]
use of mobile code is controlled.
3.13.13[b]
use of mobile code is monitored.
What to do
Define permitted code and execution
Identify code types, sources, signing/trust decisions, users and execution hosts. Include browser code, scripts, document macros and downloaded components. Assign approvals and exceptions for business use.
Apply host-appropriate controls
Use supported browser/application policy and application control to restrict execution. App Control script behavior depends on the host; some hosts can block even when a policy is in audit mode. Stage changes with recovery and harmless approved code; do not assume audit mode has no business impact.
Review actual use and enforcement events
Select logs that show allowed/denied use for the relevant execution hosts, assign reviewers and retention, and test event collection with harmless code. A control log or block label needs interpretation against actual execution behavior.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.13[a]
Verify permitted and prohibited mobile-code use follows approved policy.
Records to keep: Code/host inventory, trust rules, effective controls and harmless execution checks.
3.13.13[b]
Trace mobile-code use through relevant logging and review.
Records to keep: Actual code-use event references, coverage limits, review and follow-up actions.
Records to keep
Approved code types, sources, execution hosts and exceptions.
Actual execution/enforcement and monitoring review evidence.
If a check fails
Stop unapproved execution through the approved response process and preserve events. For a business-impacting policy error, restore a known approved scoped policy, verify the execution boundary and avoid broad permanent exclusions.
Working with a small budget
Supported built-in browser and application controls may be available. Central policy, endpoint monitoring and advanced reporting can require licenses; confirm OS feature support before relying on a control.
Voice traffic, signaling, endpoints and recordings need defined controls and monitoring. An encrypted call does not establish every VoIP requirement.
Official requirement and assessment objectives
Control and monitor the use of Voice over Internet Protocol (VoIP) technologies.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.14
Objective
Official text
3.13.14[a]
use of Voice over Internet Protocol (VoIP) technologies is controlled.
3.13.14[b]
use of Voice over Internet Protocol (VoIP) technologies is monitored.
What to do
Map voice services and dependencies
Inventory Teams or other VoIP services, phones, room systems, gateways, direct-routing components, external providers, signaling/media flows and recordings. Identify whether CUI is permitted and where it can be stored.
Control authorized voice use
Restrict administration, endpoints, external connectivity and calling/meeting features according to approved policy. Teams documents TLS and SRTP transport protection; this is not a blanket end-to-end encryption claim or proof for third-party gateways, recorders and CUI authorization.
Monitor relevant use
Assign review of appropriate service, endpoint and gateway events for unauthorized or abnormal use. Use an approved fictional test call to check permitted/denied behavior and event review. Call quality metrics alone do not establish security monitoring; do not record real conversations as an exercise.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.14[a]
Check actual VoIP endpoints, features and flows against approved use.
Records to keep: Voice inventory, effective policy, access/flow restrictions and safe test-call results.
3.13.14[b]
Trace VoIP use through monitoring and responsible review.
Records to keep: Service/endpoint/gateway event references, reviewer, investigation route and coverage limits.
Records to keep
VoIP scope, permitted CUI use and provider responsibilities.
Actual control checks and reviewed security-relevant voice events.
If a check fails
Contain unauthorized calling or exposed administration with the voice owner. Preserve required records, investigate possible disclosure and verify emergency/business calling dependencies before restricting services.
Working with a small budget
Use existing service administration and logs where available. Teams Phone, calling connectivity, reporting and retention can have separate entitlements and costs; Office ownership alone does not establish them.
Confirm the communicating parties and preserve session integrity against impersonation or hijacking. Confidentiality and session authenticity are related but distinct.
Official requirement and assessment objectives
Protect the authenticity of communications sessions.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.15
Objective
Official text
3.13.15
Determine if the authenticity of communications sessions is protected.
What to do
Identify session trust mechanisms
Record the protocols, endpoint identity checks, certificates/trust anchors, service/user authentication and relevant session/token protections for web, remote administration, VPN and other communications.
Use supported authenticated sessions
Configure approved authentication and transport/session integrity controls, certificate validation and appropriate session handling. Protect private keys and tokens through their lifecycle. Do not train users to ignore certificate warnings or rely on a familiar-looking URL alone.
Check trust failures safely
Use approved test endpoints and identities to check valid sessions work and invalid identity/trust conditions are rejected. Review expiry, revocation and session-reuse behavior appropriate to the protocol without intercepting real communications or collecting credentials.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.15
Verify communications sessions authenticate their intended parties and resist unauthorized session use under the approved design.
Records to keep: Protocol/trust design, effective endpoint/session controls and harmless valid/invalid trust checks.
Records to keep
Session protocol, identity and trust-anchor ownership.
Actual authentication/integrity checks, certificate lifecycle and unresolved session paths.
If a check fails
Stop the suspect connection and verify identity through an approved route. Correct trust configuration or replace compromised material using the incident/key process; do not bypass validation to restore convenience.
Working with a small budget
Supported TLS and integrated authentication are often already available. Certificate management and application changes require effort; a paid certificate alone does not prove complete session authenticity.
Find CUI on endpoints, servers, shared profiles, databases, cloud storage, exports, temporary locations and backups. Each stored copy needs confidentiality protection.
Official requirement and assessment objectives
Protect the confidentiality of CUI at rest.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.13.16
Objective
Official text
3.13.16
Determine if the confidentiality of CUI at rest is protected.
What to do
Locate stored copies
Link the data inventory to actual storage, ownership and provider responsibility. Include AVD profile storage, application caches, offline copies, backup exports and restore staging areas. A protected live database does not cover every derived file.
Apply appropriate access and confidentiality safeguards
Limit authorized access and implement the approved at-rest protection. For BitLocker confirm supported edition, actual protection state and recovery arrangements. Full-disk encryption does not prevent an authorized signed-in process from reading data; file/service permissions remain necessary.
Verify protection and recovery access
Use harmless sample data and approved accounts to check authorized/denied access and protected storage state. Link cryptographic protection to 3.13.10 and 3.13.11 assurance. Confirm recovery is possible for authorized roles without copying keys into the record.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A written plan, completed template or proposed action does not establish that the communications control worked.
3.13.16
Verify confidentiality of CUI at actual storage locations, including temporary, provider and backup copies.
Records to keep: Storage inventory, effective access/protection evidence, key/module references and authorized safe checks.
Records to keep
Stored-copy locations and customer/provider confidentiality duties.
Effective access/protection, key assurance and recovery verification references.
If a check fails
Restrict an exposed copy while preserving necessary evidence and recovery. Investigate possible disclosure, correct access/protection and check related copies. Do not wipe storage or destroy keys as a verification step.
Working with a small budget
Use supported included encryption and existing permissions where suitable. Windows edition, management, storage encryption options and key services have separate support/cost limits; one encrypted flag does not establish the whole control.
Confirm the actual tenant, cloud, Windows edition/build, device join, policy authority, network paths and provider responsibilities. These instructions have not been tested in a Microsoft tenant. Obtain authorization, use a small representative test scope and agree recovery before changes. Product availability does not approve a service for CUI.
AD DS-only and hybrid Windows
For AD DS-only devices, identify the linked GPOs and effective local/network policy. Open Windows Defender Firewall with Advanced Security to inspect active profiles, inbound and outbound rules and connection security rules. Record approved flows and management access before proposing a change. Built-in Windows Firewall is available across Windows editions; specific management and protection features still have prerequisites.
In a hybrid environment, identify which settings come from GPO, Intune or local configuration. Check effective policy on representative devices; hybrid join does not reconcile conflicting settings. Entra roles do not replace AD or local administrative separation.
Review host filtering alongside physical firewalls, VPN routing, network segmentation and application rules. Stage default-deny changes with essential identity, DNS, time, update and recovery dependencies accounted for. Keep a verified authorized recovery route.
Review BitLocker policy and actual drive protection/recovery under the supported configuration. Check module/version and Security Policy conditions separately. Do not use a FIPS toggle or a drive percentage as the complete verification.
Microsoft Entra joined Windows
Entra join establishes an identity relationship; it does not by itself deploy firewall, disk, code or session controls. With eligible Intune management, choose supported policies for the actual OS/build, scope assignments to an approved test group and check the device's effective behavior. If using supported local management instead, document the authority, repeatable settings and review process. Confirm Intune and optional Conditional Access entitlements rather than assuming Office includes them.
Commercial Microsoft 365 and Azure
For Azure, inspect the relevant subnet/network-interface NSG rules, effective routes, peering and public exposure together. Default NSG rules include virtual-network and outbound internet allows. A public component requires actual separation from internal networks and documented permitted exceptions. Select the right monitoring source and assign event review; do not infer security monitoring from an installed service.
For Teams or another voice/collaboration service, review identity, endpoint, calling/meeting, gateway and recording paths. TLS/SRTP transport is not a claim of end-to-end encryption for every call. Teams Phone, connectivity and reporting can need separate licensing. Check specific service documentation, contract requirements and actual CUI use before relying on provider controls.
GCC, GCC High and Azure Government
Record the identity tenant and each service instance. Commercial, GCC, GCC High and Azure Government are not interchangeable names. Verify exact feature availability, cloud endpoints, supported authentication, client version, entitlement and data flow before applying a commercial instruction. This guide does not assert parity for Intune, Teams, AVD, VPN or key-management features. Unverified cloud-specific capability remains an explicit gap; use supported existing controls while obtaining the service-specific answer.
Azure Virtual Desktop and remote-device routing
Record customer responsibilities for identities, endpoints, apps, session-host OS, configuration and network controls. AVD reverse connect reduces inbound exposure for the service connection, but check other direct administration and application routes.
Review the trust assumptions of pooled multi-session hosts. Separate ordinary work from administration and avoid ordinary users with local administrator privileges on shared hosts. Check profile/temp/shared-resource isolation with two approved test identities and harmless files.
Define normal-end and inactivity behavior and verify the actual associated network connections. A locked screen, disconnected desktop or sign-in frequency setting alone does not demonstrate connection termination.
Inspect the remote endpoint's actual VPN routes and other interfaces to address split tunneling. Clipboard, drive and printer redirection concern data-transfer paths and do not establish prevention of simultaneous other external connections.
For Azure VPN Client routing guidance, confirm the configured point-to-site OpenVPN prerequisite and supported client/platform version. Plan forced-tunnel egress: VPN Gateway does not itself supply internet connectivity. Check IPv4/IPv6, secondary adapters and dependencies through a separately authorized harmless test.
Cryptographic assurance and safe recovery
Record the actual module/version, operational environment, application linkage, CMVP certificate/status and Security Policy conditions for each CUI confidentiality use. Windows validation pages include older releases; do not downgrade to an unsupported release to match a listing. Current primitive-module self-tests and legacy FIPS policy behavior vary by release and protector scenario. Follow the exact applicable Security Policy and supported configuration, with authorized recovery verified before any change.
Keep key values out of registers. Review generation, storage, access, rotation, recovery, compromise and retirement responsibilities, including providers. A certificate or encrypted flag is only part of the evidence. Never delete, export or rotate production keys to complete a training exercise.
Collaborative devices, code and included options
Windows camera/microphone privacy controls have desktop-app limitations; some apps may still access devices despite those toggles. Check actual remote activation and in-use indications with the hardware and application in an empty authorized test setting. For mobile code, check script/browser/macro execution and its monitoring. App Control behavior depends on the host and audit mode can still block some execution, so plan recovery.
Start with existing diagrams, supported host firewall, access permissions, local/GPO controls and these free materials. BitLocker and application-control capabilities depend on supported editions/versions and configuration. Optional Intune, privileged identity features, endpoint analytics, voice services, central logs, gateways and managed key services can add licensing or consumption cost. Verify the gap and entitlement before buying; a spreadsheet records controls but does not enforce them.
These situations are fictional. Discuss them with network, system, application, development, cryptographic and collaboration owners. Use the Word exercise pack for facilitator notes. Record what participants actually did and what was only proposed. These example answers are not test results.
Supports 3.13.1, 3.13.5, 3.13.6, 3.13.7
A public subnet with an unexpected detour
Fictional Harbor Workshop proposes a public portal in an Azure subnet. The diagram labels it isolated, but the team has not checked effective default rules. Its remote support laptop uses a VPN and another internet path. A colleague offers an AVD drive-redirection screenshot as proof that split tunneling is blocked.
Discuss
Which external and internal boundaries and directions need review?
What would establish default-deny and approved exceptions?
How will the team verify actual remote-device routing without changing production?
What a useful response includes
Map the public component, backing services, management route and key internal crossings; assign monitoring and protection owners.
Review actual NSG precedence and default virtual-network/outbound allows alongside routes and host rules. Plan harmless allowed/denied checks with recovery.
Separate AVD redirection from simultaneous VPN/external routing. Review client/platform, adapters, IPv4/IPv6 and approved egress, then authorize a safe concurrent-path check.
Lesson: Labels and screenshots must be connected to actual effective behavior. Neither a subnet name nor an unrelated AVD setting establishes the required isolation.
Record: Record fictional flow references, missing evidence, proposed checks, owners and review dates. No rule or routing change has been performed.
Fictional Cedar Engineering stores project files on an encrypted laptop and sends them through a TLS service. The review packet contains a padlock screenshot and an algorithm name. The exact module version, certificate status, key owner and post-proxy transmission segment are unknown. Someone suggests installing an old Windows release from a validation list.
Discuss
What separate transmission, at-rest, session and key evidence is missing?
How would the team establish actual FIPS module assurance?
What safe response protects the information while the gaps are resolved?
What a useful response includes
Map complete transmission segments and stored copies; identify trust checks, access permissions, key identifiers and lifecycle owners without recording keys.
Match the deployed module/version/environment to the actual CMVP certificate, status and Security Policy conditions. Obtain service-specific provider evidence where needed.
Reject unsupported downgrade or key-export shortcuts. Keep unknown assurance open, select supported approved protection and plan harmless checks and authorized recovery.
Lesson: Encryption, session authenticity, key management and validated-module assurance require separate linked evidence.
Record: Record restricted module and flow references, unknown conditions and assigned supplier/system-owner follow-up. No encryption change or recovery test is claimed.
Fictional Meadow Lab proposes a shared collaboration station with VoIP, a camera and scripts that download from an internal service. Users share a profile, the display locks when idle, and the proposal assumes all network sessions end then. The camera indicator and remote activation controls have not been checked. No one owns code-use or voice-event review.
Discuss
Which architecture, management separation and shared-resource decisions need approval?
How can actual connection termination and device behavior be checked safely?
What separate mobile-code and VoIP control and monitoring evidence is needed?
What a useful response includes
Review security design, development and engineering criteria; separate administrative work and use isolated test identities to examine shared temporary/profile data.
Define inactivity periods and observe network connections at normal session end and inactivity. Check camera indication and prohibited remote activation in an empty authorized test setting.
Inventory code hosts and voice paths, approve permitted use and assign log reviewers. Stage harmless code/call checks with recovery; audit-mode App Control can still affect some hosts.
Lesson: A screen lock and an approved meeting do not prove termination, device restrictions, resource isolation or monitoring. Discussion identifies follow-up; it does not perform those checks.
Record: Keep actual discussion observations separate from proposed technical tests. Assign owners, recovery steps, dates and evidence locations without recording people or running unapproved code.
Five free Word and Excel materials
Download a copy and adapt it in your approved environment. Blank inputs and fictional examples are separate. Use restricted references; keep CUI, credentials, detailed system records and evidence in approved storage. The templates do not calculate a compliance score.
Excel
Boundary, flow and safeguard register
Map each boundary, allowed communication and confidentiality safeguard to its owner and actual evidence.
Ready for record review means a row is prepared for someone to examine. It is not verified protection, a completed technical check or a compliance finding. Keep remaining limitations and next actions explicit.
Turn a missing check into an assigned action
In a fictional review, a public subnet has an NSG but its effective internal and outbound defaults have not been checked. The team keeps 3.13.6[a] as Evidence to check in the Level 2 gap-and-action worksheet. It links the restricted flow record and assigns the network owner to inspect precedence and perform approved harmless denied-flow checks with recovery. No pass is recorded from the NSG's presence.
Sources reviewed October 28, 2026. Official text is separate from our suggestions. Product documentation supports the features and limits described; it does not establish that your deployment works or that a service is suitable for your CUI. Network design, cryptographic assurance, service support and provider responsibilities depend on your actual systems and obligations. This guide does not approve a cloud service for CUI or certify a deployed module.
Release-specific modules and Security Policy conditions. A generic policy flag is not complete assurance; older listed releases are not recommendations.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, credentials, detailed system records, logs, evidence and completed worksheets in your approved environment. Do not email them to us.