CMMC Level 2 Session Lock and Idle Timeout in Intune

An unlocked screen is one of the easiest audit failures to spot. If I’m mapping a CMMC session lock policy in Intune, I need more than a vague timeout setting.

At Level 2, the rule sounds simple: after inactivity, the session locks and the screen no longer shows data. What takes real work is translating CMMC and NIST language into Microsoft policy names, testing the result, and keeping proof ready for an assessor.

The starting point is the control language, because Intune doesn’t label settings the way CMMC does.

What CMMC Level 2 means by session lock and idle timeout

For CMMC Level 2, the control most teams care about here is NIST SP 800-171 3.1.10, often referenced in CMMC as AC.L2-3.1.10. The requirement is to use session lock with a pattern-hiding display after a period of inactivity. In plain terms, a user walks away, time passes, Windows locks, and the visible data disappears behind the lock screen or screen saver.

The key detail is that CMMC does not give me one universal timeout. I have to define the idle period in policy, apply it to the right devices, and show that it works. Many teams pick 5 to 15 minutes based on risk, user workflow, and whether the device handles CUI. Microsoft’s CMMC access control guidance is useful for the broader control mapping, but Intune still needs careful tuning.

This quick mapping keeps the terminology straight:

CMMC or NIST term	What I need to prove	Intune or Windows setting
Session lock	The signed-in session locks after inactivity	Interactive logon: Machine inactivity limit
Idle timeout	The organization defines the inactivity period	Documented timeout value in policy and Intune profile
Pattern-hiding display	The screen no longer shows data to a passerby	Lock screen or secured screen saver
Re-authentication	The user must sign back in to resume work	Password-protected screen saver or sign-in required on unlock

I don’t treat this as a narrow compliance task. In my Small Business IT work, this control shows up during Cloud Infrastructure projects, Office 365 Migration efforts, and Data Center Technology refreshes. It matters just as much in Restaurant POS Support and Kitchen Technology Solutions, because a terminal left open is still an exposed endpoint.

Building the Intune policy for Windows endpoints

Intune can handle this well, but I don’t rely on one setting alone. For most Windows 10 and Windows 11 devices, I build a Settings catalog profile and combine machine lock, screen hiding, and sign-in protection.

The settings I use in Intune

I usually start with a Windows Settings catalog profile because it gives me clear, supportable policy names. If a tenant already uses security baselines or Group Policy, I check for conflicts first.

My standard build looks like this:

1. Create a profile for Windows 10 and later in the Settings catalog.
2. Add Interactive logon: Machine inactivity limit and set it to your documented value, such as 900 seconds.
3. Add Enable screen saver and set it to Enabled.
4. Add Password protect the screen saver and set it to Enabled.
5. Add Screen saver timeout and match it to the same idle value, or set it slightly lower.
6. Assign the profile to the device group that contains systems in scope for CUI.

That combination does two jobs. The inactivity limit handles the lock, and the screen saver settings help satisfy the pattern-hiding part while forcing re-entry of credentials. If Windows Hello for Business unlocks the device, that’s still fine as long as the method is approved and the session is protected.

I never treat a single timeout number as the control. The control is the policy, the technical setting, the test result, and the evidence set.

If your environment includes macOS in Intune, I use a separate profile with the same documented idle period and password-on-wake behavior. The principle stays the same even though the setting names differ.

Common conflicts that break the lock

I see three failure points all the time. First, an old GPO overrides the Intune setting. Second, a security baseline sets a different inactivity value. Third, the profile lands on the wrong group, so the test device never receives it.

Shared devices also need attention. A kiosk, front-desk station, or shop floor system may need a different profile and supporting controls. If the device can’t lock the way a normal user workstation does, I document the exception, scope it tightly, and add compensating safeguards. Intune helps here, but it doesn’t excuse weak design.

For admins who want a broader review of secure endpoint settings, I sometimes point teams to these Intune security configuration tips as a cross-check, not as audit proof.

How I validate the control and collect audit evidence

A policy that looks right in Intune can still fail on the endpoint. Because of that, I always test with a real device in scope. I sign in as a normal user, leave the system idle, and measure the lock time. Then I confirm the screen no longer shows open data and that the user must authenticate to return.

For Windows, Event Viewer is useful. Security event 4800 shows that the workstation locked, and 4801 shows it unlocked. Those events can support a sample test record. I also check Intune’s per-setting status so I can show the policy applied successfully.

My audit package usually includes:

• A written policy that defines the idle timeout for in-scope systems.
• Screenshots or exports of the Intune profile and assignments.
• A sample device record that shows the profile reached the endpoint.
• Test notes with date, device name, user role, timeout used, and result.
• Event log evidence or local policy output from the test device.
• An exception list for devices that need alternate treatment.

I keep this evidence simple and repeatable. Assessors want to see that the control is defined, deployed, and operating. They also want consistency between what my policy says and what the endpoint does. If my document says 10 minutes and the device locks at 30, I’ve created my own gap.

Where Intune stops and supporting controls begin

Intune is a delivery tool, not a full compliance answer. A strong CMMC session lock setup in Intune still needs support from identity, endpoint, and operational controls.

I usually pair the lock policy with Endpoint Security baselines, Device Hardening, BitLocker, and Conditional Access rules that require compliant devices for Microsoft 365 access. I also suppress lock-screen notifications where sensitive previews could appear. That helps the pattern-hiding side of the control, especially on mobile workstations and shared desks.

For regulated Microsoft 365 tenants, Intune in GCC and GCC High can shape how I plan assignments, licensing, and service boundaries. That matters for MSPs and internal teams supporting defense contractors.

This is also where good service work becomes visible. My Cybersecurity Services don’t stop at one profile. I tie session lock into Innovative IT Solutions and Tailored Technology Services, whether I’m handling Cloud Management, acting as a Business Technology Partner, or providing Technology Consulting for Infrastructure Optimization and Digital Transformation. For firms setting IT Strategy for SMBs, the same control supports Secure Cloud Architecture, Managed IT for Small Business, and stronger Business Continuity & Security.

Conclusion

An unlocked screen is still one of the fastest ways to fail a control review. The win is not picking a magic timeout number. The win is setting a documented idle period, mapping it cleanly in Intune, and proving the endpoint follows it.

When I handle CMMC session lock in Intune that way, it stops being a checkbox. It becomes a repeatable control that holds up for admins, MSPs, and assessors alike.