Know who and what connects, check how they authenticate and close the gaps.
Work through all 11 requirements and 25 assessment objectives. Review users, processes and devices, then check MFA, identifier rules and password handling in the systems you actually use. Keep observations separate from intended settings.
Sources reviewed October 27, 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.
Confirm scope. Include systems handling CUI and the services protecting them, applications, remote access and provider responsibilities. If the information or boundary is unclear, start with Do we handle CUI? and your scoping work.
List more than people. Include administrators, ordinary users, guests, processes acting for users and devices. Give each an owner, purpose and approved reference.
Separate the checks. Identify local and network privileged access, ordinary network access, device authentication, service authentication, password changes, resets and recovery.
Find the actual authority and policy. Check the tenant cloud, device join, identity store, authentication mechanism, effective policy and subscription. Installed Office applications do not establish those details.
Protect access while testing. Agree a supported recovery route first. Use disposable test accounts and harmless work in an appropriate test environment. Do not dump credentials, capture real secrets, replay production tokens, mass-disable accounts or repeatedly trigger failed sign-ins.
Never enter passwords, hashes, app secrets, authentication seeds, recovery codes or biometric information in these materials. Keep detailed identity records and evidence in your approved environment. This website does not collect exercise answers or accept CUI or completed worksheets.
Know which users, processes and devices access the system
Start with an identity list you can explain. Include people, the processes acting for them and the devices connecting to the system. A list of employee email addresses leaves important gaps.
Official requirement and assessment objectives
Identify system users, processes acting on behalf of users, and devices.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.1
Objective
Official text
3.5.1[a]
system users are identified.
3.5.1[b]
processes acting on behalf of users are identified.
3.5.1[c]
devices accessing the system are identified.
What to do
List the identities and owners
Use approved references for staff, administrators, guests, service accounts, scheduled jobs, applications and devices. Record the owner, purpose, identity store and resources reached. For a process acting for a user, retain the connection to that user and the identity used by the process.
Include each way of connecting
Cover local and remote Windows access, Microsoft 365, AVD, file services and other systems in scope. Distinguish a person, a separate administrator account, a workload identity and a device identity even if their names look similar. A hostname or IP address is a useful reference, not proof of device identity.
Compare records with actual access
Review representative accounts, application/service configuration and connecting devices with their owners. Investigate unknown or shared identities. Connect additions, role changes and retirement to the inventory and access process so the list stays useful.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.1[a]
Identify the users who access each system, including privileged, ordinary, external and emergency accounts.
Records to keep: Identity references, assigned person or accountable role, purpose and system scope.
3.5.1[b]
Identify processes acting for users, the identity each uses and its accountable owner.
Records to keep: Process/service/job map, user relationship, application identity and owner.
3.5.1[c]
Identify connecting devices and relate the actual connections to approved device records.
Records to keep: Device identity references, ownership, connection scope and unexplained devices.
Records to keep
User, process and device identity references with owners and purpose.
Access-path map and unresolved identities, linked to inventory and access records.
If a check fails
For an unexplained identity, preserve relevant records and establish what depends on it before changing access. Use the incident route where misuse is suspected. Do not delete a service account merely because its display name is unfamiliar.
Working with a small budget
Start with existing directory, local account, application and inventory records plus the free register. A paid identity product does not replace knowing who owns a process or why a device connects.
An identity record says who or what something is meant to be. Authentication checks that claim before access. Review users, processes and devices separately.
Official requirement and assessment objectives
Authenticate (or verify) the identities of users, processes, or devices, as a prerequisite to allowing access to organizational systems.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.2
Objective
Official text
3.5.2[a]
the identity of each user is authenticated or verified as a prerequisite to system access.
3.5.2[b]
the identity of each process acting on behalf of a user is authenticated or verified as a prerequisite to system access.
3.5.2[c]
the identity of each device accessing or connecting to the system is authenticated or verified as a prerequisite to system access.
What to do
Map each identity to an authentication method
For each path, record the identity provider or verifier, credential type, target and relevant policy. Include applications using delegated user access, service credentials, certificates, managed identities and device trust where used. Keep secret values out of the register.
Check the access decision
Use supported configuration and an authorized harmless test to establish that the user, process or device is authenticated before the resource is available. Check the denied case in a suitable test environment without repeated failures or production lockouts. A device object in Entra or an allowlisted IP alone does not establish device authentication on every path.
Review unattended and fallback paths
For an application acting for a user, check the verified user identity and the application identity involved. Record how noninteractive processes authenticate; do not assume they can satisfy a human prompt. Check alternate protocols, cached/offline access and recovery routes rather than testing only the browser sign-in.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.2[a]
Check a representative user is authenticated before access and that an unauthorized test identity is denied under the intended policy.
Records to keep: Applicable policy, identity-provider/resource results, safe test scope and limits.
3.5.2[b]
Trace a process acting for a user through the identity verification required before its access.
Records to keep: User/process relationship, authentication configuration, target decision and safe result.
3.5.2[c]
Check how the connecting device proves its identity before access, using the actual trust/certificate mechanism for that path.
Records to keep: Device trust or certificate design, effective enforcement and authorized result checks.
Records to keep
Authentication method and verifier for each user/process/device path.
Observed access decisions, permitted fallbacks and unresolved authentication gaps.
If a check fails
If a change prevents access, use the approved recovery route and investigate the affected trust, certificate, policy or dependency. Do not remove authentication broadly as a workaround. Preserve existing working protections while testing a repair.
Working with a small budget
Use supported authentication in your existing directory and services. Azure managed identities can avoid handling a service secret on supported workloads, but Azure resources still cost money and permissions still need review. No one free control covers every application or device.
Cover local and network access to privileged accounts, and network access to ordinary accounts. Registering an app or seeing one cloud MFA prompt does not establish that coverage.
Official requirement and assessment objectives
Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.3
Objective
Official text
3.5.3[a]
privileged accounts are identified.
3.5.3[b]
multifactor authentication is implemented for local access to privileged accounts.
3.5.3[c]
multifactor authentication is implemented for network access to privileged accounts.
3.5.3[d]
multifactor authentication is implemented for network access to non-privileged accounts.
What to do
Identify privileged accounts and access paths
Include domain, tenant, local, support and emergency administrators. Record local privileged access, network privileged access and ordinary users' network access as distinct checks. Include AVD, direct remote access and services outside Microsoft 365.
Choose supported enforcement and protect recovery
For cloud access, review current security defaults, per-user settings and Conditional Access before changing anything. Security defaults is available without extra Entra licensing but is not a tailored policy for every CMMC path. Conditional Access generally requires P1 or an eligible bundle. Review exclusions and keep emergency access under an approved, tested arrangement; exclusions are not automatic CMMC exceptions.
Check the actual authentication result
Use an authorized test account and inspect the applicable policy and authentication details for the exact connection. Report-only results and method-registration counts do not show enforcement. A session can satisfy MFA with an earlier claim, so absence of a fresh prompt alone does not prove a bypass. For Windows privileged access, separately check the supported local sign-in or elevation and allowed fallback.
For the detailed cloud, Windows and AVD steps, use the existing 3.5.3 MFA implementation walkthrough. Check each connection stage and the host join model you actually use.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.3[a]
Reconcile the privileged-account list with actual directory, cloud and local administration rights.
Records to keep: Privileged identity inventory, effective rights and account owners.
3.5.3[b]
Check MFA for applicable local privileged access, including the actual administrator identity and permitted fallback.
Records to keep: Supported Windows authentication design, safe observed result and uncovered local routes.
3.5.3[c]
Check enforced MFA and the authentication result for privileged network access across the relevant services.
Records to keep: Policy scope, exclusions, sign-in details and safe connection results.
3.5.3[d]
Check enforced MFA and the result for ordinary users' network access, not only administrator portals.
Records to keep: User/resource/client scope, session authentication evidence and remaining gaps.
Records to keep
Privileged and ordinary account/path coverage matrix.
Enforcement, authentication results, recovery checks and action records for uncovered paths.
If a check fails
If users cannot sign in, use the approved recovery process and verified support route. Investigate the policy, method, client and dependency before expanding scope. Do not disable working MFA across the tenant to make a test pass.
Working with a small budget
Microsoft Authenticator is a free app; an app alone does not enforce MFA. Compatible software OATH methods depend on service support and policy. Security keys, smart cards, readers, cloud policy features and supported Windows deployment can add cost. State those limits before purchasing.
A captured authentication exchange should not be usable again to authenticate. Review the actual mechanism for both privileged and ordinary network access. MFA and replay resistance are related questions, with different evidence.
Official requirement and assessment objectives
Employ replay-resistant authentication mechanisms for network access to privileged and non-privileged accounts.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.4
Objective
Official text
3.5.4
Determine if replay-resistant authentication mechanisms are implemented for network account access to privileged and non-privileged accounts.
What to do
Record the protocol and its protection
For each network sign-in, identify the actual authentication protocol and the freshness or challenge mechanism that prevents accepting a repeated exchange. Use current vendor protocol documentation and configuration evidence. Do not infer the protocol from the product logo or the method a user registered.
Check what the connection actually uses
Review the effective setup, permitted fallback and representative authentication records. Kerberos and supported key-based designs have their own prerequisites; a connection that falls back uses a different path that also needs review. HTTPS protects a transport path, but its presence alone does not establish the authentication mechanism's replay resistance.
Keep the limits visible
Record which connections are supported by evidence and which need a supported technical check. Use only an authorized isolated test if specialist replay testing is necessary. Do not capture or replay production credentials, codes or tokens. Replay resistance is not a promise that a method defeats phishing, real-time relay or theft of an already valid session token.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.4
For privileged and ordinary network access, connect protocol documentation to the effective configuration and actual authentication path, including fallback. Record how replay is resisted and any unverified path.
Records to keep: Protocol/mechanism references, scope, effective settings, authentication evidence and remaining limits.
Records to keep
Network authentication mechanism map and supporting documentation.
Actual-path/fallback checks and gaps needing further verification.
If a check fails
If a service depends on an unsuitable or unverified method, record the gap and plan a supported replacement or restriction through change control. Check application dependencies and recovery before removing a protocol. An MFA checkbox is not a substitute for that review.
Working with a small budget
Existing supported protocols may already provide the needed mechanism. Establish the actual path before buying another product. Keep additional phishing and session protections in the wider security plan without treating them as proof of this objective.
Keep retired identifiers from being reused too soon
Choose the period during which an identifier cannot be reused and enforce it. This concerns account and other identity names or identifiers, not how many old passwords are remembered.
Official requirement and assessment objectives
Prevent reuse of identifiers for a defined period.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.5
Objective
Official text
3.5.5[a]
a period within which identifiers cannot be reused is defined.
3.5.5[b]
reuse of identifiers is prevented within the defined period.
What to do
Define the rule and the identifiers it covers
Specify the non-reuse period, responsible owner and covered human, process and device identifiers. Consider sign-in names, aliases and other identifiers used to trace access. Record the basis and how renamed, deleted and recreated accounts are handled. CMMC does not give one universal number here.
Check proposed names against history
Keep restricted retirement and assignment history long enough to apply the rule. Make the provisioning or renaming process check it before issuing an identifier. Directory uniqueness only checks current objects; a newly created object with a new internal ID may still reuse an old sign-in name.
Review actual provisioning records
Compare recent creation/rename records with the retained history. Use fictional names to exercise the review process. Record prevented reuse and any gap rather than recreating a real departed user to test it.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.5[a]
Find the defined identifier non-reuse period, scope and provisioning responsibilities.
Records to keep: Approved period, covered identifiers, ownership and retirement-history arrangement.
3.5.5[b]
Check actual creation and rename decisions against retained identifier history and the approved period.
Records to keep: Provisioning checks, decision dates, blocked reuse and unresolved records.
Records to keep
Approved non-reuse rule and restricted identifier assignment/retirement history.
Provisioning checks and decisions, with remaining gaps.
If a check fails
If an identifier was reused too early, preserve the assignment timeline and review access, mail, application and audit implications before an approved correction. Avoid silently transferring old permissions or treating historical activity as belonging to the new person.
Working with a small budget
A controlled provisioning checklist and restricted identifier-history register can help a small team. A password-history setting or retention of deleted objects alone does not implement this naming rule.
Disable identifiers after the defined inactivity period
Define inactivity for the identities you use, choose a period and reliably disable identifiers when the rule applies. A blank last-sign-in field is a question to investigate, not proof that an account is unused.
Official requirement and assessment objectives
Disable identifiers after a defined period of inactivity.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.6
Objective
Official text
3.5.6[a]
a period of inactivity after which an identifier is disabled is defined.
3.5.6[b]
identifiers are disabled after the defined period of inactivity.
What to do
Define activity and the disabling rule
Specify the period, relevant activity for each identity class, evidence sources, review timing and who disables the identifier. Include noninteractive service use, infrequent jobs, legitimate absence and emergency access in the design. State any special handling and unresolved coverage; do not hide it under an undocumented exemption.
Check evidence and dependencies
Use successful activity where available, owner information and relevant system records. A failed interactive attempt does not show legitimate use. An interactive-only report misses service activity, and missing or expired reports leave uncertainty. Review dependencies and approved recovery before disabling an account; a mass-disable command is not a safe first check.
Apply the rule and verify the result
Carry out authorized disabling when due, record the decision and check the relevant access is blocked. Review existing sessions or credentials separately under the service's supported process; disabling an account does not necessarily end every session immediately. Investigate overdue actions and data gaps.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.6[a]
Locate the defined inactivity period and the activity sources and review process used to apply it.
Records to keep: Approved rule, identity classes, responsibilities and review schedule.
3.5.6[b]
Trace an identifier that reached the period through review, actual disabling and the relevant access check.
Records to keep: Activity basis, decision, disable date/result, session handling and unresolved exceptions.
Records to keep
Inactivity rules and activity-source coverage.
Dated disable decisions, access checks, dependencies and remaining uncertain or overdue records.
If a check fails
If a necessary account was disabled, verify the request and dependency through the approved route before restoring access. Preserve the reason, authorizer and recovery result. Review the activity rule and data coverage; do not simply extend every inactivity period after one problem.
Working with a small budget
Use a repeatable manual review if it can meet the approved timing and evidence needs. Entra activity reporting has licensing and permission limits: the Graph lastSuccessfulSignInDateTime property requires P1/P2. Without sufficient records, keep the evidence gap open rather than guessing.
Define and enforce password complexity and character changes
State the rules for new passwords and for changes of characters, then check the actual enforcement. This Revision 2 requirement should not disappear because a newer general password recommendation uses different wording.
Official requirement and assessment objectives
Enforce a minimum password complexity and change of characters when new passwords are created.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.7
Objective
Official text
3.5.7[a]
password complexity requirements are defined.
3.5.7[b]
password change of character requirements are defined.
3.5.7[c]
minimum password complexity requirements as defined are enforced when new passwords are created.
3.5.7[d]
minimum password change of character requirements as defined are enforced when new passwords are created.
What to do
Write the rules for each password authority
Cover domain, local, cloud and application-managed accounts as relevant. Define complexity and the character-change requirement separately, with the chosen values and meaning. Do not invent a CMMC-mandated length or number of changed characters. If you use passwordless authentication, document which password and recovery paths remain and how they are controlled.
Compare the rule with what the platform can enforce
Review the effective domain/fine-grained, local, cloud or application policy. Built-in Windows composition checks do not implement an arbitrary count of characters changed from the old password. Many Entra cloud-managed restrictions are fixed. If your chosen rule is not technically enforced, record the gap and decide a supported correction; a written policy alone does not close it.
Test creation and change safely
On an approved test account, check allowed and disallowed cases for each defined rule through the relevant creation/change paths. Use disposable values that are not reused anywhere, and record only result references. Keep passwords out of screenshots, tickets, worksheets and this website.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.7[a]
Find the defined password complexity rules and their account/system scope.
Records to keep: Approved complexity definition, policy owner and applicable password authority.
3.5.7[b]
Find the separately defined password change-of-character rules and what they require.
Records to keep: Approved rule, chosen meaning/values and account/system scope.
3.5.7[c]
Compare effective policy and harmless new-password test results with the defined complexity rule.
Records to keep: Policy/resultant-setting reference, accepted/rejected result and uncovered paths.
3.5.7[d]
Check actual enforcement of the defined character-change rule when new passwords are created through the applicable change paths.
Records to keep: Supported enforcement mechanism, safe result references and any product limitation or gap.
Records to keep
Separate complexity and character-change definitions for each authority.
Effective configuration, safe result references and unenforced requirements.
If a check fails
If a rule blocks legitimate resets or fails to enforce the definition, use the approved recovery process and test a supported correction. Do not install an unreviewed password filter or weaken production policy as a quick fix. Keep the failed condition in the record.
Working with a small budget
Use the policy capabilities already available in your identity stores. Do not buy or deploy a password-filter extension before understanding the gap, support requirements and recovery risks. Generic advice is not evidence that the chosen rule is enforced.
Prevent password reuse for the chosen number of generations
Specify how many password generations cannot be reused and verify the behavior. The password-change and password-reset paths may not apply the same checks.
Official requirement and assessment objectives
Prohibit password reuse for a specified number of generations.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.8
Objective
Official text
3.5.8[a]
the number of generations during which a password cannot be reused is specified.
3.5.8[b]
reuse of passwords is prohibited during the specified number of generations.
What to do
Specify the history rule
Record the number of generations, scope and responsible owner. Keep this separate from identifier non-reuse and password age. Check which identity store controls the password, including domain policy, any fine-grained policy, local accounts and cloud-only users.
Check platform and reset limits
For AD DS, inspect the resultant password settings for the intended test user and the interaction with minimum password age. For cloud-only Entra accounts, do not claim that a domain history value applies. Microsoft documents different password-change and reset behavior; the service does not expose an AD DS-style configurable history count. Keep any mismatch with your specified generations open for supported design review.
Verify allowed and rejected reuse
Plan a small authorized test for the chosen history boundary and relevant reset paths, using a disposable account in an appropriate test environment. Observe minimum-age restrictions without changing production policy or rapidly cycling real passwords. Record only the acceptance/rejection and evidence reference, never the values.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.8[a]
Find the specified number of password generations and the identities/stores it covers.
Records to keep: Approved count, scope and authority mapping.
3.5.8[b]
Compare effective history policy and safe boundary/reset checks with the specified count.
Records to keep: Resultant policy, test method and accepted/rejected results, including unsupported or unverified paths.
Records to keep
Password-history count and per-authority coverage.
Effective settings, safe result references and change/reset limitations.
If a check fails
If reuse is allowed contrary to the rule, preserve the finding and identify the actual change or reset path. Review a supported identity or policy design with the responsible security/assessment advisers. Do not mark it met merely because the normal change screen rejected one password.
Working with a small budget
AD DS and supported local policies include history controls. Cloud subscription upgrades do not automatically add an arbitrary history control. Establish the specific gap before considering a different service or architecture.
Require an immediate change when a temporary password is used
A temporary system-logon password should lead to a required change before normal access. Issuing a temporary value is only the first part of the process.
Official requirement and assessment objectives
Allow temporary password use for system logons with an immediate change to a permanent password.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.9
Objective
Official text
3.5.9
Determine if an immediate change to a permanent password is required when a temporary password is used for system logon.
What to do
Define issuance and identity checks
Specify who may issue a temporary password, how the requester is verified and how the value is delivered through an approved protected route. Include domain, local, cloud and application reset paths. Do not put passwords in ordinary tickets or send them to this website.
Check the first-use behavior
Use a disposable test account to check that temporary-password logon requires an immediate change before ordinary work is available. Confirm the resulting permanent credential works and the temporary value no longer does, without repeated failures. Check each supported logon/reset route rather than assuming one directory flag covers them all. Microsoft Temporary Access Pass is a separate bootstrap method; its presence alone does not demonstrate temporary-password behavior.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.9
Observe an authorized test showing temporary-password logon requires immediate change to a permanent password before normal access, for the applicable paths.
Records to keep: Issuance/reset policy, first-use setting, safe observed result and unverified or incompatible routes.
Records to keep
Temporary-password issuance, identity verification and protected delivery procedure.
First-use/change results without credential values, plus path-specific limitations.
If a check fails
For a lost, exposed or unusable temporary password, verify the user through the approved recovery route and invalidate/replace the credential using supported procedures. Keep the immediate-change requirement in the replacement flow and record only the action/result.
Working with a small budget
Use supported first-logon/change controls in the services you already operate. Check hybrid reset/writeback and application support before promising a cloud reset works for every Windows logon. No extra tool makes an unverified help-desk request safe.
Protect passwords in storage and while they travel
Review the whole password-handling path, including application stores, scripts, reset delivery, exports and backups. A masked sign-in box does not protect a password copied into a ticket.
Official requirement and assessment objectives
Store and transmit only cryptographically-protected passwords.
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.10
Objective
Official text
3.5.10[a]
passwords are cryptographically protected in storage.
3.5.10[b]
passwords are cryptographically protected in transit.
What to do
Map where passwords and verifiers exist
List identity stores, applications, service configurations and recovery paths. Record the exact storage mechanism and access protection. The Revision 2 discussion describes salted one-way password hashes; Windows documentation also describes legacy unsalted mechanisms. Do not treat any hash, or a vendor name, as sufficient evidence. Record provider evidence and unresolved questions for the responsible security/assessment review. Do not build a custom password store or extract live credential databases or hashes as a test.
Check protected transmission
Review every relevant sign-in, reset, application and administrative path for supported cryptographic protection and correct endpoint/certificate validation. Do not assume a protected browser page covers a backend connection or a password later sent in email. Do not accept certificate warnings or collect real credentials in packet captures.
Remove exposed handling paths safely
Check approved configuration, logs and support procedures for places where a password could be written in plain text. Use a harmless marker in a test workflow if needed, not a real secret. If a credential was exposed, follow the incident/reset procedure. This review does not establish that every cryptographic requirement elsewhere in CMMC is met.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.10[a]
Identify storage locations and check documented and configured cryptographic protection, including application/service and recovery records.
Records to keep: Storage mechanism/provider references, access restrictions and uncovered plaintext handling.
3.5.10[b]
Check cryptographic protection for each applicable password transmission path, including reset/delivery and backend connections.
Records to keep: Protocol/endpoint settings, certificate checks, protected workflow references and remaining gaps.
Records to keep
Password-handling map with protection and owner references, without passwords or hashes.
Storage/transit checks, exposed-path findings and approved corrective actions.
If a check fails
Restrict access to an exposed record and follow the approved credential-incident process, including supported reset/rotation and session review as appropriate. Preserve required incident evidence securely without copying the secret into ordinary tracking records. Check the corrected handling path.
Working with a small budget
Use the secure storage and transport supported by your platforms and approved credential-management methods. Azure managed identities can remove some application-secret handling where supported; they do not protect unrelated user passwords or make resource use free.
Keep authentication information out of visible feedback
Check what the user and nearby people can see during authentication. Password values or other secret authentication information should not appear in ordinary feedback, error messages or support recordings.
Official requirement and assessment objectives
Obscure feedback of authentication information
NIST SP 800-171A, June 2018. Determine if:
Official objectives for 3.5.11
Objective
Official text
3.5.11
Determine if authentication information is obscured during the authentication process.
What to do
Review each authentication surface
Include Windows sign-in, browser and application prompts, reset pages, command-line tools and remote sessions in scope. Check that secret entry is obscured and failure messages or debug output do not repeat the entered value. Do not treat asterisks as evidence of protected storage or transmission.
Test with harmless input
In a suitable test workflow, use a disposable nonsecret marker to inspect default entry, submit/failure, reset and support-recording behavior. Avoid repeated failed logons or real passwords in screenshots. Review any deliberate reveal feature within the actual authentication design rather than assuming the page is safe because one field was masked.
Check each objective
Record what you observed, the evidence reference and anything still unknown. A saved policy, registered method or completed template does not establish the full requirement.
3.5.11
Inspect applicable authentication prompts and harmless test feedback to confirm authentication information is obscured during the process.
Records to keep: Covered surfaces, default-entry/error/reset observations, safe result references and gaps.
Records to keep
Authentication-surface list and harmless feedback checks.
Application or procedure fixes and their recheck results.
If a check fails
If a prompt, log or recording exposes secret information, stop using that test path and follow the credential-handling and application correction process. Protect affected records and verify the fix with harmless input before normal use resumes.
Working with a small budget
Most supported sign-in interfaces already obscure secret input. The work is checking custom applications, scripts and support practices too. A new subscription is not a substitute for correcting a prompt that echoes its input.
Use the path for the actual identity store, cloud and host join. Check current documentation and the license before changing a setting. These examples do not configure your tenant, approve a service for CUI or cover non-Microsoft applications automatically.
AD DS and hybrid joined Windows
Identify domain users, computer accounts, service identities and local accounts. Record who owns each and how it authenticates to the target. A synchronized user and a hybrid joined device are different records.
In Active Directory Administrative Center, find the authorized test user and use View Resultant Password Settings. Review the applicable fine-grained policy; if none applies, examine the domain default. Inspect local account policy separately on the host. A GPO linked to a workstation does not by itself define domain-user password policy.
Compare complexity, history and reset behavior with your approved rules. Use supported domain authentication and review fallback. For local privileged MFA, plan a supported smart-card or Windows Hello for Business deployment where appropriate; a cloud MFA policy does not change a password-only local administrator sign-in.
For hybrid users, map on-premises authentication, synchronization, federation or password writeback as actually used. Check creation, change and reset paths separately. Do not assume cloud and domain policy settings are identical or that a cloud reset has updated every on-premises route.
Microsoft Entra joined Windows
Confirm the device join, intended user account and resource. Check how the device identity participates in access. Entra join alone does not require MFA on every local or network connection.
For cloud-managed accounts, compare the documented fixed password behavior with your rules. Local Windows account policy does not alter a cloud-only Entra password. Keep incompatible history or character-change requirements open for a supported design review.
If using Windows Hello for Business, select the supported deployment for the device and resources. Check prerequisites, enrollment, effective policy, actual privileged sign-in/elevation, fallback and recovery. A local-account PIN or a successful ordinary-user Windows sign-in is not evidence for every privileged path.
Commercial Microsoft 365 and Azure
In the intended Entra tenant, use Users to inspect a test account's authentication methods and sign-in records with the necessary read access. Compare method registration with the applicable enforcement policy and authentication details.
Review security defaults or Conditional Access as currently deployed. Conditional Access needs an eligible license, generally P1 or above. Check target users/resources, exclusions, grant conditions and enforcement mode. Preserve working protections during an approved pilot; do not turn off security defaults merely to create an untested replacement.
Review application/service identities separately, using supported certificates, managed identities or other approved mechanisms. Maintain identifier retirement and inactivity decisions. Use the password-change/reset behavior for the account's actual authority, not an assumed Office-license feature.
GCC, GCC High and Azure Government
Record the identity tenant and service instance first. GCC and GCC High have different identity/service arrangements; do not choose instructions from the label alone. For government-cloud identities, use the documented national-cloud endpoints, application registrations and available features. Check the authentication method, reporting, Conditional Access entitlement and supported AVD client/host combination in that environment. Keep exports and evidence inside the approved boundary. Do not switch to a commercial integration as an undocumented workaround.
Azure Virtual Desktop
Map authentication to the AVD service, the Windows session host and applications/profile storage inside the session. Record the host's actual join, the user identity and the storage authentication design separately.
For supported Entra SSO, hosts must be Entra joined or hybrid joined and meet the documented client, operating-system, trust and cloud requirements. AD DS-only hosts do not support that Entra SSO path. Do not weaken domain-admin replication restrictions to force SSO to work.
Apply the documented MFA policy coverage for the AVD service and, where SSO is used, Windows Cloud Login. Check permitted clients, reconnect/unlock behavior and sign-in evidence. A browser MFA test does not establish local privileged MFA on the host.
Use the detailed MFA walkthrough for the separate AD DS-only, hybrid and Entra joined steps. Agree a supported recovery arrangement before any change.
Read-only password-policy examples
Authorized administrators can inspect these settings on the appropriate Windows/domain system. AD commands need the Active Directory module and permitted directory access. A blank resultant fine-grained-policy result does not mean there is no password policy; check the domain default. These commands do not reveal passwords and were not run against the owner's systems.
# Local account policy summary on the current computer
net accounts
# Domain policy summary when the computer and account have the required access
net accounts /domain
# AD module required; inspect the domain default
Get-ADDefaultDomainPasswordPolicy | Select-Object ComplexityEnabled, MinPasswordLength, PasswordHistoryCount, MinPasswordAge, ReversibleEncryptionEnabled
# Replace the placeholder with an authorized test account; check its fine-grained policy
Get-ADUserResultantPasswordPolicy -Identity 'REPLACE-TEST-ACCOUNT' | Select-Object Name, ComplexityEnabled, MinPasswordLength, PasswordHistoryCount, MinPasswordAge, ReversibleEncryptionEnabled
Inspect with the test account and correct authority. Keep configuration output restricted. Do not add password, token, hash, seed or recovery-code values to the output or tracker. These summaries do not establish MFA, device authentication, cloud password policy or complete enforcement.
Included options and costs to check
Use the Office templates, supported directory/local account tools and your existing authentication features first. Microsoft Authenticator is a free app, and security defaults provides baseline cloud protections without an extra license. Compatible software OATH apps are usable only where the service and policy allow them. Tailored Conditional Access, some activity reports, password writeback and other management features can require additional licenses. Smart cards, security keys, readers, supported Windows deployment and Azure resources can add costs. None of these purchases establishes CMMC compliance.
These situations are fictional. Discuss them with the people who manage accounts, authentication and recovery. Use the Word exercise pack for facilitator notes. A discussion is not a technical test; record unperformed checks honestly.
Supports 3.5.1, 3.5.2, 3.5.3, 3.5.4
Cloud MFA works but local administrator access is unchecked
Fictional exercise: a small contractor has registered its staff for MFA and seen an administrator complete a Microsoft 365 sign-in. The same team uses AVD and has a local recovery administrator on a workstation. Nobody has checked the session-host sign-in, local privileged access or the software service account used by a scheduled job.
Discuss
Which identities and ways of connecting are still missing from the review?
What shows that MFA was required and satisfied for the access being examined?
Which checks can be planned without changing production authentication or risking lockout?
What a useful response includes
List the human, process and device identities, their owners and the resources they access. Separate local privileged access, network privileged access and ordinary users' network access.
Keep the successful cloud sign-in as evidence of that event only. Check the applicable policies, authentication details and any earlier MFA claim. Review the AVD service, session host, local administrator and other permitted connections separately.
Plan authorized checks using a test identity, harmless work and a supported recovery route. Review how each network authentication method resists replay; neither an MFA registration count nor an HTTPS address answers every question.
Lesson: A working cloud MFA sign-in does not establish MFA for every Windows account or connection. Service and device identities also need identification and authentication checks; do not pretend an unattended process can answer a human MFA prompt.
Record: Create fictional identity-register rows for the missing paths. Record observed evidence separately from checks not performed, assign an owner and keep the open objectives visible.
Supports 3.5.5, 3.5.6
A new contractor is given an old account name
Fictional exercise: a team plans to reuse a departed contractor's sign-in name for a new starter. Its records do not show an approved identifier non-reuse period. An inactivity report also has blank dates for several accounts, including an emergency account and an account used by an infrequent service.
Discuss
What is the difference between reusing an identifier and reusing a password?
What do a blank activity field or a failed sign-in attempt tell you about account use?
How should the team review dependencies and emergency access before disabling anything?
What a useful response includes
Find or establish the approved identifier non-reuse period and a restricted record of retired identifiers. Check the proposed name against it before creating or renaming the account. Do not rely on the directory's current uniqueness check alone.
Define the inactivity period and relevant activity for each identity class. Check successful interactive and noninteractive activity where available, data coverage and owner information. Treat missing report data as unknown, not proof of inactivity.
Review service dependencies, legitimate absence and emergency access under the approved process. Apply the required disabling rule with verified recovery arrangements, record the actual decision and check the result. Do not use an undocumented exception to leave a gap hidden.
Lesson: A fresh account object can still reuse an old sign-in name. A blank report date can reflect missing data. Keep naming history, inactivity evidence and account-disable decisions as separate records.
Record: Record fictional reuse and inactivity rules, affected identity references, missing evidence, dependencies, authorized decisions and next actions. Do not disable real accounts for this discussion.
Supports 3.5.7, 3.5.8, 3.5.9, 3.5.10, 3.5.11
The password-change test passed but the reset path was never checked
Fictional exercise: a contractor wrote a password-history requirement after looking at an AD DS policy screen. Some staff have cloud-only Entra accounts. The team tested a normal password change but not administrator resets or temporary-password sign-in, and a support ticket contains a temporary password in plain text.
Discuss
Which identity stores and change or reset paths need separate checks?
Does the selected cloud service enforce the organization's chosen history and character-change rules?
How should the team handle the exposed temporary password and arrange a safe retest?
What a useful response includes
Map each account type to its actual password authority and effective policy. Define complexity, character-change and history decisions, then compare them with both normal change and reset behavior. Do not copy an AD DS history setting into the cloud-only column as if it applied there.
Check whether temporary-password use requires an immediate change before normal access. Examine storage, transmission and authentication feedback through configuration and harmless test evidence. Use disposable test credentials only; never record the test values, hashes, seeds or recovery codes in the tracker.
Treat the exposed temporary password through the approved credential-incident and reset process, restrict the record and verify the recipient's identity through the approved route. Plan a supported correction for any cloud policy limit and keep unverified or unenforced requirements open.
Lesson: Normal changes, administrator resets and first sign-in can behave differently. A masked sign-in field does not protect a password copied into a ticket, and an AD DS setting does not change Entra's cloud-only password policy.
Record: Save fictional policy and test-result references, the affected credential-handling path, unresolved product limits, owner and next check. Do not put any real or example password value in the record.
Five free Word and Excel materials
Download a copy and adapt it in your approved environment. Blank inputs and fictional examples are separate. Use identity and evidence references; never store credential values in these files. The templates do not calculate a compliance score.
Excel
Identity and access-path register
Connect users, processes and devices to their owner, resources, authentication methods and checks still needed.
Ready for record review means a row is prepared for someone to examine. It is not an approved account, successful authentication test or compliance result. Keep remaining limitations and next actions explicit.
Turn an unchecked sign-in into a specific next action
In a fictional example, an administrator completes MFA for Microsoft 365, but local privileged Windows access is untested. The team keeps 3.5.3[b] as Evidence to check in the Level 2 gap-and-action worksheet, links the identity register and assigns the local-access check to an owner. It does not use the cloud sign-in as evidence for the local objective.
Sources reviewed October 27, 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. The password requirements shown here remain those of the Revision 2 baseline.
Requirement discussions, including replay resistance and organization-defined identifier rules. Generic newer password advice does not replace this baseline.
Activity interpretation, reporting access and P1/P2 requirements for the Graph lastSuccessfulSignInDateTime property. Missing data is not proof of inactivity.
Cloud-managed password restrictions and the difference between change and reset history. Do not assume configurable AD DS history applies to cloud-only users.
Email cmmc@purposefulsecurity.com with a general description. Keep CUI, identity records, passwords, tokens, recovery codes, logs and completed worksheets in your approved environment. Do not email them to us.