CMMC Entra ID Sign-In Risk Policies for Level 2

A bad sign-in can undo months of security work. When I review Microsoft 365 tenants that handle CUI, the weak spot is often not MFA itself. It’s the lack of a clear policy for risky access.

For CMMC Level 2, I treat CMMC Entra ID design as part policy, part proof. You need the right controls in Microsoft Entra ID, and you also need evidence that those controls are active, reviewed, and tied to your written process.

What sign-in risk means in Entra ID, and what it doesn’t

In Microsoft Entra ID, sign-in risk is the chance that a single authentication attempt is not from the real user. Microsoft Entra ID Protection calculates that risk from signals such as unusual location, unfamiliar sign-in pattern, leaked credentials, or other suspicious activity. Microsoft documents a common starting point in its risk-based sign-in MFA guidance and the broader Entra ID Protection risk policy steps.

That matters because many teams mix up five different ideas:

A risky sign-in is an event. A risky user is a state.

Sign-in risk applies to one login attempt. User risk reflects the chance that the account itself is compromised. Conditional Access is the policy engine that can act on those signals. MFA is one response the policy can require. Identity Protection is the service that detects risky users and risky sign-ins.

I see confusion here all the time. A tenant may have Conditional Access and MFA, yet still lack Identity Protection-based policies. In that case, the tenant has strong authentication, but not risk-aware authentication. For CUI, that gap matters.

There is also a licensing caveat. Risk-based policies rely on Microsoft Entra ID P2. Some older pages and URLs still say Azure AD Identity Protection, but the current product name is Microsoft Entra ID.

One more detail catches teams off guard. If a user has not registered MFA, a risky sign-in can be blocked. That is by design. So before I turn on enforcement, I verify registration coverage and exception handling.

Where sign-in risk fits in a CMMC Level 2 control set

CMMC Level 2 does not say, “Turn on this Entra feature and you are compliant.” I never present it that way. What Entra ID gives me is a practical way to support access control and identification and authentication practices, then prove that the controls operate as intended.

Microsoft’s CMMC Level 2 identification and authentication guidance is helpful because it maps identity features to the broader control set. Still, the burden stays with the contractor. You must define scope, identify where CUI lives, limit access, use strong authentication, and document how you review and respond to risky events.

For me, the best way to think about sign-in risk is as a control amplifier. Passwords and MFA are your front door. Risk policies are the extra guard who checks whether the person at the door looks wrong even when the password is correct.

That is why I don’t build these policies in isolation. I tie them to user groups that access CUI, admin roles, device trust, and response procedures. If the sign-in is risky but the device is unmanaged, the action should be stronger. If the user is privileged, the policy should be tighter.

A good CMMC Entra ID approach also avoids false comfort. A medium-risk sign-in policy with MFA is useful. It does not replace account reviews, log review, incident handling, or endpoint controls.

The policy set I would deploy for users who touch CUI

When I build a policy set for a small or mid-sized contractor, I start small and strict. First, I identify the user population that can reach CUI. Next, I confirm MFA registration. Then I roll policies out in report-only mode, review the logs, and move to enforce after cleanup.

This is the compact policy stack I trust most:

Policy	Scope	Trigger	Response	Evidence to save
Risk-based sign-in policy	Users with CUI access	Medium and high sign-in risk	Require MFA, block if user is not registered	Conditional Access export, sign-in logs with risk detail
User risk policy	Same users, excluding service accounts	High user risk	Force password change where supported, or disable pending review	Risky users report, help desk ticket, reset record
Privileged access policy	Admin roles and security staff	Any cloud admin access	Require phishing-resistant MFA where possible, require compliant device	Role inventory, CA policy, successful auth logs
Legacy auth block	All users	Any non-modern auth attempt	Block access	Sign-in logs showing blocked protocols

I also add two controls around those policies. First, I exclude emergency access accounts from normal Conditional Access and protect them with long offline-held credentials, close monitoring, and test records. Second, I add device requirements for CUI apps. Risk-aware sign-in is stronger when it works with compliant devices and session controls.

For example, a medium-risk sign-in from an unmanaged laptop should not get the same path as a normal sign-in from a hardened workstation. In practice, I combine sign-in risk, app targeting, device compliance, and reauthentication frequency.

This is where many small firms either gain control or lose it. If you handle CUI, a risk policy should sit beside Endpoint Security and Device Hardening, not apart from them.

The evidence an assessor will want to see

A screenshot of a policy is not enough. I want evidence that shows design, approval, operation, and follow-up over time.

My documentation package usually includes these items:

• A system security plan that names Entra ID, scoped user groups, CUI-connected apps, and policy intent.
• Conditional Access exports or screenshots that show assignments, exclusions, sign-in risk settings, and enforcement state.
• Sign-in logs and risky user logs that prove the policy triggered and that staff reviewed the results.
• Incident records for risky sign-ins, including who reviewed the alert, what action they took, and when they closed it.
• Exception records for emergency accounts, service accounts, and any temporary bypass.

I also keep a plain-language policy statement. It should explain when MFA is required, how risky access is handled, who reviews the logs, and how often that review happens. Assessors usually care about consistency. If the written rule says the team reviews risky sign-ins weekly, the evidence should show weekly reviews.

Log retention matters too. Native portal views are useful, but I prefer to send sign-in data to a SIEM or log store so I can keep history and show trend data. That supports both audit readiness and incident response.

One more caveat belongs here. Service accounts and workload identities do not fit neatly into user risk and sign-in risk policy design. I document them separately and apply other controls.

Common gaps I keep seeing in small business tenants

Most failures are ordinary. A team finishes an Office 365 Migration, sets up MFA, and assumes identity work is done. Six months later, the tenant still has pilot exclusions, weak group scoping, and no review rhythm.

I see the same pattern across Small Business IT, Cloud Infrastructure, and Data Center Technology projects. Access policy gets pushed behind server cutovers, app onboarding, or mailbox moves. The business stays busy, but the control set stays half-built.

That problem is not limited to office users. Shared devices show up in Restaurant POS Support and Kitchen Technology Solutions too. If those systems connect to Microsoft 365, shared sign-ins and local admin habits can bleed into your identity risk model.

For me, strong Cybersecurity Services connect identity to the rest of operations. That means Cloud Management, Secure Cloud Architecture, and Business Continuity & Security all reinforce the same access rules. It also means Technology Consulting should produce settings, records, and review steps, not only advice.

When I act as a Business Technology Partner, I want Tailored Technology Services that fit how the client works. Some need tighter controls around engineering users. Others need better Managed IT for Small Business processes so policy changes do not break line-of-business apps. Good Innovative IT Solutions still need boring discipline. Review the logs. Clean the groups. Test the exceptions.

That is how identity supports Infrastructure Optimization, Digital Transformation, and a practical IT Strategy for SMBs.

Conclusion

Risk-based sign-in policy is one of the clearest ways I can improve a CUI tenant without adding clutter. It helps me challenge suspicious access in real time, and it gives me evidence that the control is alive.

The strongest result comes from pairing CMMC Entra ID policy with device trust, clear documentation, and steady review. When those pieces line up, the tenant is easier to defend, easier to explain, and far easier to take through an assessment.