IA.L2-3.5.11 Obscure feedback: requirements and evidence

What IA.L2-3.5.11 asks for when users type a password

A defense contractor running a system that handles CUI needs a login screen that hides what the user types. IA.L2-3.5.11 requires that authentication information, such as password characters, is obscured while it is entered. It is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.5.11, a derived requirement in the Identification and Authentication family. Under 32 CFR 170.24 it is worth 1 point, so it is a low-weight item in the score, but an assessor still expects to see it working on every path where a person enters a secret. The risk it addresses is simple: someone standing behind the user can read a password off the screen, or a screen recording or screen share can capture it.

The CMMC Assessment Guide for Level 2 describes the expected practice as obscuring feedback under a defined policy, such as showing asterisks. It also allows smaller devices to briefly display each character before obscuring it, which helps on phones and tablets where a masked character is hard to check while typing. Your organization should write that policy down, decide which devices and interfaces fall under it, and confirm the brief display window is configured the same way across them. Ask your identity provider, VPN client, remote desktop gateway and any local console software to show you the masking behavior in a test account, and keep screenshots as configuration evidence. The Department of War suspended CMMC Phase II on 13 July 2026, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. That means this requirement still has to be implemented and documented now, and it will appear in any self-assessment your organization submits. Confirm the current status with your contracting officer and the DoW CIO About CMMC page before you plan any certification timing.

Which login surfaces fall under IA.L2-3.5.11 in a CUI boundary

IA.L2-3.5.11 applies to any place where a person types authentication information inside the assessed CUI boundary, so the scoping question is less about the requirement and more about which logins exist. The cards below walk through the surfaces assessors usually see, and what to confirm about each one before you write the system security plan.

Workstations and local logins

Every engineer and administrator workstation in the boundary has a local login screen, and that screen is in scope. The operating system's default password entry normally masks characters, but the configuration should be confirmed rather than assumed, including any custom credential provider or remote desktop prompt. Record the operating system build and the masking behavior in the evidence you collect for the assessor.

Servers and privileged consoles

Server console logins, out-of-band management interfaces and hypervisor consoles accept authentication information and are inside the boundary when they host CUI or manage systems that do. Check whether the console is a graphical or text login, whether a serial or KVM session echoes characters, and whether vendor firmware prompts behave differently from the operating system. Each of these needs its own check.

Web consoles and VPN portals

Web-based administration consoles and VPN or remote access portals are common sources of gaps because they are often managed by a different team or a vendor. Login forms in these pages should render a password field that masks input, and the same should hold for any second-factor prompt that asks for a code. Test the pages in each browser your staff use, since a browser extension or custom theme can change the field type.

Mobile and small-screen devices

Phones and tablets that access CUI are in scope, and this is where the policy allowance matters most. The CMMC Assessment Guide Level 2 describes a defined policy under which small devices may briefly show each character before obscuring it. Document the exact behavior your platform uses, the delay before masking, and whether it applies to every entry field or only to the password field.

Service accounts and kiosk logins

Automated service logins usually have no human typing, so the feedback requirement rarely applies to them directly, but any interactive prompt they expose does. Kiosk or shared terminals in a controlled area are different: a shared sign-in screen that displays typed characters for other people to see is a finding. Decide which prompts are interactive, list them in the boundary inventory, and state how each one is treated.

Third-party hosted logins

A hosted identity provider, SaaS application or managed service that stores or processes CUI and sits inside the assessed boundary brings its login pages into scope, even though you do not operate them. Ask the provider for its login design and any documentation of masking behavior, and record that evidence in your assessment file. If the provider cannot show how its login pages behave, confirm with the assessor how that gap should be recorded before relying on the service.

How an assessor tests masked authentication feedback

This table compares the four checks an assessor runs against the single SP 800-171A objective for IA.L2-3.5.11, showing what each check does, what evidence the assessor asks for and where organizations usually fall short. Read each row as one step in the test, and treat the common findings as the points to rehearse before the assessment begins.

Test step	What the assessor does	Evidence requested	Common findings
Observe a live login	Watches a real sign-in on each in-scope interface, such as console, web portal, VPN, remote desktop and administrative tools, and confirms characters are hidden as they are typed	Recorded or witnessed login on each interface, with the account and interface named in the notes	Masking applied on the web portal but not on a legacy console or command-line tool
Review the masking policy or configuration	Reads the written policy and the configuration that sets obscured feedback, then compares the two	Final approved policy, configuration exports or settings screenshots taken from the production system	Policy says masking is required, but no configuration setting enforces it
Check small-device behavior	Confirms that any brief display of a character on a small screen matches the defined policy and ends with obscuring	Documented small-device rule in the policy, plus a test on a representative handheld or small-screen device	Brief display is in use but never written into the policy, or characters stay visible on the device
Review audit records and authenticator feedback procedures	Checks the procedures SP 800-171A names as potential evidence and any logs showing that authentication feedback handling was configured and applied	Authenticator feedback procedures, change records for masking settings and logs or records tied to the system security plan	Procedures exist only as drafts, or change records do not show when masking was enabled
Confirm exceptions are documented	Looks for any login path, service account prompt or legacy tool that does not mask input and checks for a recorded justification	Exception register with owner, scope, compensating measure and approval	Undocumented exceptions discovered during the live login step
Confirm coverage across login paths	Compares the list of login paths in the system security plan with the paths tested live	Inventory of authentication interfaces mapped to the system boundary	Masking set only on some login paths, such as the main application but not its administrative console
Confirm evidence is in final form	Checks that screenshots and procedures reflect the current production configuration and an approved version	Dated final artifacts with version control or approval history	Screenshots taken from a draft or test environment rather than the final configuration

How to implement and document feedback obscuring in six steps

This sequence turns IA.L2-3.5.11 from a policy statement into configuration evidence an assessor can test, with each step producing a record that the next step relies on. The work stays inside your environment and your change control, and the assessment itself remains with an independent assessor.

Inventory every login interface
List every place a user, administrator or service enters an authenticator within the CMMC assessment boundary: workstation sign-in, VPN and remote access portals, web applications, administrative consoles, database clients, mobile devices and any network device with a local login prompt. Record the platform, owner, authentication method and whether the interface is in scope for CUI. The output is a dated inventory list that the policy and test steps reference, so an assessor can see that no login path was skipped.
Write and approve the obscuring policy
Draft a defined policy stating how authentication feedback is obscured, for example by showing masked characters such as asterisks or dots. Include the brief character display rule for small devices, such as phones or handheld terminals, specifying which devices qualify and how long each character may show before it is masked. Have the policy approved by the system owner and security lead, then store it under document control. The output is an approved policy version that the configuration and test steps cite by version number.
Configure each platform and identity provider
Set each inventoried interface to match the approved policy, using the vendor's own settings for masked input and, where a platform offers one, a documented option that limits any character display on small devices. Where open-source platforms are involved, the configuration is captured in version-controlled files or exports so the setting is reproducible. Confirm the exact setting names with each vendor or project, since behavior differs across operating systems, browsers and identity providers. The output is a configuration export for every interface, stored with the policy version it implements.
Test each interface and record the result
Test every inventoried interface against the single assessment objective for 3.5.11: authentication information must be obscured during the authentication process. For each interface, a tester enters a test credential, observes the field, and records whether the characters are masked, whether any brief display matches the policy, and the device type used. Capture a screenshot or screen recording and retain it with the tester's name and date. The output is a signed test record per interface, with any failure logged as a finding rather than corrected silently.
Record exceptions with owners and dates
Where an interface cannot meet the policy, record the exception in the risk register with the specific gap, the compensating control in place, a named owner and a target date for closure. Confirm with your assessor how exceptions are presented, since a 1-point requirement such as IA.L2-3.5.11 may be placed on a plan of action and milestones only under the conditions in 32 CFR 170.21, and only if your score and status allow it. The output is an exception register entry for each gap, reviewed by the security lead before the assessment.
Lock the configuration under change control
Bring the approved policy, configuration exports and signed test records under the same change control process used for the rest of the system security plan. Any later change to a login screen, identity provider or device image triggers a retest of the affected interface and an update to the record. Schedule periodic review of the policy and test records so they remain accurate. The output is a controlled baseline with a version history that shows the feedback obscuring setting has been maintained, not just configured once.

Which evidence passes IA.L2-3.5.11 and how to keep it current

Assessors test IA.L2-3.5.11 by checking that authentication input is masked on every interface and that the policy and configuration behind it are documented. The cards below cover each artifact an assessor is likely to ask for, along with how to keep it accurate between assessments. Every item must be in final form, since draft documents do not count toward a MET result.

Approved feedback obscuring policy

The written policy states that authentication information is obscured during entry, and it names the rule for small devices. Record the version number, the effective date and the name and role of the approver, so the assessor can see who accepted the requirement. Review the policy when login platforms change, when a new device class is added, or when the defined exception rule changes. Confirm that the approved version is the one users and administrators actually follow, because an older draft in a shared folder is a common source of finding.

Login platform configuration exports

Export the relevant settings from each platform that accepts credentials, including the directory, identity provider, VPN, remote access gateway, Linux and Windows login, and any internal web applications. Store each export with its capture date and the system name, so the assessor can match settings to the system security plan. Repeat the export after upgrades, since default behavior can change between versions. Compare exports against the approved policy, and record any mismatch as an exception with a remediation date.

Dated screenshots or recordings of masked input

Capture a dated screenshot or short screen recording for each login interface showing that typed characters appear as masking symbols during entry. Cover the interfaces users see, not only the administrative console, because the assessor may choose any of them. Retake these captures after interface changes and label each file with the system, the interface and the date. Store them in the evidence repository with the same naming convention used for the other artifacts, so retrieval is quick during the assessment.

Small-device display rule and test

Where a device has a screen too small for a masked password field, the policy may allow each character to show briefly before it is masked. Document the device types this covers, the display duration the platform uses, and the test you ran to confirm the behavior. The test record should show the device model, the operating system version, the date and the result. Repeat the test when the device fleet or mobile application changes, and confirm the brief display never persists after the character is entered.

Exception and deviation records

If any system does not mask input as the policy requires, record the exception with the affected system, the reason, the compensating measure, the approver and an expiration date. Assessors look for exceptions that are open indefinitely with no owner. Review each open exception at a set interval and close it once the platform is corrected or retired. Tie any exception that cannot be closed to the plan of action and milestones process, and confirm with your assessor how they will treat it.

Change tickets for login configuration

Keep a change ticket for each modification to login interfaces or authentication settings that could affect input masking, including vendor patches and new deployments. Each ticket should show the requested change, the approver, the test performed, and the date it was closed. Assessors use these records to confirm that the configuration evidence reflects the current state rather than a past snapshot. Link the tickets to the configuration exports they produced, so the chain from change to evidence can be followed without manual searching.

What meeting IA.L2-3.5.11 costs in money and effort

This table lists the cost components of obscuring authentication feedback, who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a written scope and to ask providers for line-item quotes. The main takeaway is that most of the cost sits in configuring and evidencing each login interface, so shared identity configuration is the strongest lever.

Cost component	Who is paid or who bears it	One-time or recurring	What drives the cost
Login interface inventory	Internal staff or implementation partner	One-time, refreshed when systems change	Number of login screens, apps, consoles and command-line tools that accept credentials
Feedback configuration per platform	Implementation partner or internal engineers	One-time per platform, plus rework after upgrades	Number of platforms and device types, and whether each one sits behind a shared identity provider
Policy writing and approval	Internal compliance lead, reviewed by management	One-time, reviewed on a defined cycle	Whether one organization-wide display policy covers all systems or each system needs its own rule
Test effort per interface	Internal testers or a partner running the checks	One-time per interface, repeated after changes	Number of interfaces, small-screen devices in use, and whether masking is tested at each entry point
Evidence collection and upkeep	Internal security or compliance staff	Recurring, tied to assessment and review cycles	How much screenshot, configuration and policy evidence must be kept current and in final form
Configuration monitoring	Internal platform team, optionally with open-source tooling	Recurring	Whether drift is caught by scheduled checks or only found at assessment time
External review or testing, if bought	Independent security tester or consultant	Optional, one-time per engagement	Scope agreed in writing, number of interfaces tested and depth of review
Assessor time	Independent assessor or C3PAO, paid by the organization	One-time per assessment cycle	Number of interfaces the assessor samples and the quality of ready evidence
Licence spend for monitoring tools	Software vendor, if commercial tooling is used	Recurring	Commercial licences scale with endpoints. Self-hosted open-source tools such as Wazuh (GPL-2.0-only) and Fleet (MIT) remove this licence line but still need hosting and staff time

How Wazuh and Fleet can produce evidence for feedback obscuring

Wazuh and Fleet both check endpoint configuration and report results per device, which makes them useful for showing that a masking setting exists and stays in place. Neither tool tests whether a login screen actually hides characters during entry, so the assessor's own observation remains the deciding test.

Wazuh configuration assessment checks

Wazuh Security Configuration Assessment compares monitored endpoints against YAML policies, most of them based on CIS benchmarks, and can be extended with custom policies. For IA.L2-3.5.11, write a custom policy that checks the files, registry keys or running processes that hold the masking setting your organization defined, such as a screen lock or login configuration value. Each failed check comes with remediation guidance, which gives your team a documented path to correct drift. Confirm each check against your own build, because a setting can exist in one file and be overridden elsewhere.

Fleet policies as yes or no questions

Fleet policies are yes or no questions written as osquery queries, and the policies page shows which devices in each fleet pass or fail. A custom policy can ask whether the masking setting your organization defined is present on each device. The pass or fail view gives a current, per-device record that you can export as evidence. Confirm that the query returns the setting in the form your policy expects, since a query that returns nothing can look like a pass in a poorly written check.

Choosing which tool covers which devices

Wazuh suits monitored servers and endpoints where you want configuration checks tied to a broader security monitoring program. Fleet suits fleets of workstations where you want quick yes or no answers about device state. Many environments use one tool for most devices and document why the other covers the rest. Write down which device classes each tool reaches, because an assessor will ask whether every system that displays authentication information is inside the check.

Limits of automated evidence

Both tools report that a setting is present, not that a user sees obscured characters during a real login. A passing check does not show that the application or login screen actually applies the setting. Pair each automated check with a documented observation of the login process on each device type, including small-screen devices where the policy may allow brief character display. Keep the screenshots, check output and approval records together in final form, because an assessor will test the evidence, not the tool.

Who owns the policy, the configuration and the assessment

Your organization owns IA.L2-3.5.11. Someone on your side must decide what the authentication feedback policy says, confirm that every system that handles CUI actually obscures password entry, and be able to show the result to an assessor. For Phase I self-assessments, which remain in place, your leadership performs the assessment, scores the requirement and posts the result in SPRS. An outside party can help, but the decision and the affirmation belong to your team.

Policy ownership: Write or approve a defined policy stating that authentication feedback is obscured, and state where brief character display is allowed on small devices.
Scope decisions: Identify every login surface in the CUI boundary, including web applications, operating system logons, VPN clients and mobile devices.
Self-assessment: Score IA.L2-3.5.11 against the assessment objective in NIST SP 800-171A and record the basis for the result.
Evidence custody: Keep configuration exports, test screenshots and approved policy versions in final form, not drafts.
Affirmation: Your Affirming Official confirms the posted status is accurate.

Before you start, confirm which phase applies to your contracts, since the Department of War's current status changes the assessment path.

Why a 1-point requirement still needs a clean record

IA.L2-3.5.11 is worth 1 point under 32 CFR 170.24, so it barely moves a score out of 110. It is also not on the exclusion list in 32 CFR 170.21(a)(2)(iii), which means it can sit on a plan of action and milestones (POA&M) if the assessed score is at least 88 of 110 (0.8). Under that path, the organization must close the item within 180 days. The arithmetic is simple, but the decision is not: a single 1-point gap is only tolerable if the rest of the environment clears the threshold, and every other open item draws from the same margin.

The practical risk is that a small item can still block a contract. If the score drops below 88, the Conditional Level 2 route closes, and a missing 1-point requirement becomes one of several reasons an award or renewal stalls. Before relying on a POA&M, confirm the current status with your contracting officer and check the operative text in the eCFR, because the DoW CIO "About CMMC" page and the eCFR's phase schedule in 32 CFR 170.3(e) do not currently describe timing the same way. Phase timing changes what assessment you may face, so treat the status question as open until it is confirmed in writing.

For planning, the cleanest approach is to close IA.L2-3.5.11 outright rather than carry it on a POA&M. Keep a dated configuration record showing that the login screen masks entry, that any brief character display is governed by a written policy for small devices, and that the setting is applied consistently across the systems in scope. Assessors will want the policy and the configuration evidence in final form, not drafts, so assign an owner to the record before the assessment window opens.

Where organizations usually miss feedback obscuring and how to close it

Most organizations that fail IA.L2-3.5.11 do not lack a masking setting. They lack consistent coverage, documented behavior and dated proof that the setting still works. The gaps below cluster around scope, documentation, governance and change over time.

Masking missing outside the main portal

Teams often confirm that the customer or employee portal hides passwords, then assume the same is true for VPN clients, admin consoles and service logins. Each login surface is a separate system component that an assessor may sample. Inventory every interface that accepts authentication input, including command-line prompts and legacy applications, and check each one. Record the result for every entry point, not only the primary one.

Small-device behavior left undocumented

The CMMC assessment guidance allows smaller devices to briefly show each character before obscuring it, but many organizations never write down whether their phones, tablets or kiosks do this. An assessor who finds an undocumented behavior has to ask whether it was intended. State the permitted display behavior for each device class in the policy, and confirm it on a real device of each type.

Policy drafted but not approved

A masking standard saved in a shared drive with no owner, approval date or version history does not give an assessor a defined policy to test against. Assign an accountable owner, route the policy through formal approval, and record the version number and effective date. Keep superseded versions so you can show which rule applied during any past period.

No test record against the final configuration

Testing done during a pilot, or against a staging build, does not show how production behaves. Test the configuration that will be assessed, capture the date, the system and the result, and store the record with the evidence set. Test records should describe the actual screens and settings observed, not a general statement that masking is enabled.

Exceptions handled informally

A help desk that turns off masking for one user to troubleshoot a login, or a vendor who asks for a plain-text field during setup, creates an exception that no one records. Route every exception through a documented request with a reason, an approver, a scope and an end date. Review open exceptions on a fixed schedule so temporary deviations do not become permanent.

Drift after software updates

Updates to operating systems, identity providers or web frameworks can reset display settings or add new login forms with different defaults. Treat masking as a monitored configuration item. Use a configuration assessment tool to check the relevant settings after each change, and re-run your test record when a login component changes. Wazuh's configuration assessment and Fleet's policy queries can help show which endpoints still pass a given check.

What buyers ask before they bring in help for IA.L2-3.5.11

How much effort does IA.L2-3.5.11 take compared with other Level 2 requirements?

It is one of the lighter Level 2 items. IA.L2-3.5.11 is worth 1 point under 32 CFR 170.24, and NIST SP 800-171A gives it a single assessment objective: authentication information is obscured during the authentication process. Most of the effort is confirming that every login screen, application, and remote access path masks what is typed, and that any brief display on small devices follows the organization's written policy. The heavier Level 2 work usually sits in the requirements that depend on account lifecycle, logging, and network boundaries. Effort varies with how many systems and login paths the organization runs, so ask a prospective partner to list them in the written scope.

Can our team meet IA.L2-3.5.11 without outside help?

Often yes, because the requirement is narrow and the evidence is mostly configuration output and a written policy. A team that already runs an identity provider and a documented authentication standard can usually check each login path itself. Outside help becomes more useful when the environment has many legacy applications, appliances, or custom logins that do not mask input by default, or when the team needs an independent view before a Level 2 assessment. Whatever the choice, the organization owns the control and the policy. Confirm whether your assessor will accept your internal review as supporting evidence before you decide how much to buy.

What do our identity and endpoint staff need to provide?

Identity and endpoint staff own the facts an assessor will test. They need to supply:

A written authentication policy that defines when feedback is obscured and whether brief character display is allowed on small devices
A list of every login surface, including directory-backed applications, local accounts, VPN and remote access portals, mobile apps, and administrative consoles
Configuration exports or screenshots that show masking is enforced, along with the version of each platform
Procedures for reviewing exceptions, such as legacy systems that display input

If endpoints are monitored, configuration checks can be scripted with tools such as Wazuh Security Configuration Assessment, which uses YAML policies to check files, registry keys, and processes. Confirm that your staff can run and retain those results.

How long does the IA.L2-3.5.11 work take?

No duration is given in the facts available for this page, so no timeline is stated here. The scope sets the time. The main drivers are the number of login surfaces, how many of them need configuration changes, how much legacy software has to be reviewed, and whether the evidence has to be captured in final form for an assessment date. Ask the partner to break the timeline into discovery, configuration, evidence capture, and review, and to name the systems each phase covers. Confirm the schedule against your own assessment date and any contract milestones, since the CMMC rollout timing has changed recently.

Can an implementation partner issue a CMMC certification?

No. An implementation partner prepares systems, configurations, and evidence, but it cannot issue a certification or assessment report. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, currently The Cyber AB, under 32 CFR 170.17 and 170.18. Self-assessments are carried out by the organization itself. The partner and the assessor should be kept independent, so the organization should not ask the same firm to prepare the evidence and then certify it. Confirm the assessor's status with the accreditation body before you sign anything.

What should a written quote for this work include?

A useful quote follows from a written scope and states exactly what is delivered. Ask for:

The list of login surfaces and systems covered, with versions
The current state review and the target configuration for each surface
The evidence package, including policy text, configuration exports, and test results, with a clear statement of what the organization must still produce itself
The roles of each party, including who owns the policy and who speaks to the assessor
The timeline by phase, any dependencies on your staff, and what happens if the scope changes
Whether support or retesting after the assessment is included or sold as a retainer

DeployOpen does not publish a price list, and its quotes follow from the written scope.

How DeployOpen scopes and prepares IA.L2-3.5.11 evidence

DeployOpen works on IA.L2-3.5.11 as a bounded piece of a wider CMMC Level 2 environment, inside the client's own infrastructure. We prepare the login mechanisms, the configuration evidence and the test records an assessor will examine, while the organization keeps ownership of its controls and the independent assessor makes the determination.

How we scope

Confirm which login interfaces, admin consoles and self-hosted platforms display password entry and are in the CUI boundary.
Record the defined policy for obscuring feedback, including whether any small-screen devices may briefly show characters.
Agree the scope in writing before work starts, with deliverables, owners and timelines for each platform.

How we build

Configure masked password fields and verify obscuring behavior on each in-scope login path, including web, console and mobile clients.
Where a platform cannot mask input by default, document the limitation and the compensating approach for the organization to decide on.
Use configuration checks such as Wazuh Security Configuration Assessment policies to confirm settings persist on monitored endpoints.

How we hand over

Deliver test records showing the assessment objective, the tested login paths, the observed behavior and the date of each test.
Document the defined feedback policy in a form the organization can own, approve and keep under change control.
Provide the evidence in final form, since drafts do not satisfy an assessor. The independent assessor decides whether the requirement is met.

How we support

Re-test obscuring behavior after platform upgrades, new login pages or changes to the authentication flow.
Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
Recurring checks can use policy results, such as Fleet policies that show which devices pass or fail a configuration question, to flag drift early.