Obscure feedback is about what your authentication systems tell the user when authentication fails. If a login screen says “user not found,” an attacker learns that username doesn’t exist. If it says “invalid credentials,” they learn nothing useful. The attacker can’t enumerate valid usernames.
For most contractors using Windows or cloud authentication, this is handled automatically. The system says “invalid credentials” and that’s it. The failure usually comes from custom applications or legacy systems that reveal too much information. This practice completes the IA authentication controls alongside IA.L2-3.5.2 (user authentication) and IA.L2-3.5.3 (MFA), ensuring that authentication is both secure and doesn’t leak information to attackers.
What the assessor is actually evaluating
The assessor is checking that your authentication systems don’t reveal information that could help an attacker. They’ll ask about your login error messages. They might ask you to demonstrate what a failed login looks like. They want to see that the message is generic and doesn’t disclose whether the username exists, what happened to the password, or any other useful information.
For most modern systems, this is automatic. Windows says “the user name or password is incorrect.” Azure AD says “invalid credentials.” These are appropriately obscured. If you’re using a custom application, you need to think about what feedback it gives.
What a realistic SSP definition looks like
Practice IA.L2-3.5.11: Obscure Authentication Feedback
Authentication feedback does not reveal information that could assist an attacker in obtaining unauthorized access.
Standard Authentication Systems:
User authentication to Windows domain, Azure AD, and cloud services uses standard platform authentication. These platforms are configured to provide generic authentication failure messages. When authentication fails, the system displays “invalid credentials” or “login failed” without specifying whether the failure was due to an invalid username, invalid password, account locked, or other specific condition. This prevents attackers from determining which usernames exist in our environment.
VPN and Remote Access:
VPN authentication is provided by [VPN platform]. Authentication failures display a generic message indicating authentication was unsuccessful, without divulging the specific reason for the failure.
Web Applications and Custom Systems:
If custom web applications or legacy systems require authentication, they are configured to provide generic failure messages. Custom applications are reviewed during development and testing to ensure authentication error messages do not reveal sensitive information such as:
- Whether a username is valid
- Whether a password is correct (vs. username being invalid)
- Account status (locked, disabled, expired, etc.)
- Details about authentication mechanisms
Logging vs. Feedback:
While generic messages are displayed to users, detailed authentication failure information is logged on the back end for security monitoring and troubleshooting. This maintains security (generic feedback to users) while preserving operational capability (detailed logs for administrators).
This explains the principle and applies it to different systems. The assessor reads this and understands your approach.
How to present your evidence
- Your SSP statement documenting authentication feedback approach
- Screenshots of authentication error messages from your systems
- Comparison showing generic feedback (not specific about username/password/account status)
- Documentation of custom applications (if any) showing error message handling
Your evidence is simple:
Your SSP statement (above). This is enough evidence by itself for most assessors.
Screenshots of authentication error messages. Try logging in with a bad username and a bad password on your systems. What does each one say? If they both say “invalid credentials,” you’re good. If they differentiate, you have a problem.
Documentation of custom applications (if any). If you have custom apps that require authentication, document how they handle error messages.
That’s all you need. This is quick to present.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP or MSSP
Your MSSP configures your authentication systems. Standard platforms like Windows, Azure AD, and most VPN solutions handle obscure feedback automatically. Your MSSP should have this set up correctly.
If you have custom applications, your MSSP should be aware of the authentication feedback they provide. If not, ask them to review them.
This is not usually a point of emphasis in MSSP relationships because it’s handled automatically by standard systems. If you’re worried, ask them directly.
This guidance is based on assessment room experience and reflects one practitioner’s interpretation of CMMC Level 2 requirements. It is not legal or compliance advice. Always consult your compliance team and official CMMC documentation for final guidance.