You start your day, and suddenly, the helpdesk lights up. Calls are coming in: devices are locking after just one minute of inactivity. Strange, right? You didn’t configure an Intune Device Lock screen timeout policy. But something is clearly enforcing it.
“It’s not a bug. It’s a feature.”
Let’s break it down.
What’s Really Happening?
At first glance, nothing in your device configuration profiles explains this behavior. There is no policy configured for the lock screen timeout, yet the device still locks. So, where is this device lock policy coming from?
That’s where the wild goose chase begins. We started digging into the usual suspects: Security Baselines, Endpoint Security policies, and configuration profiles. We were sure the MaxInactivityTimeDeviceLock policy had to be hiding in one of them. But everything looked clean. Or so it seemed.
Everything seemed fine. Nothing that contained a policy that could lock those devices. But then, we noticed something strange on the device itself: registry keys showing up in the PolicyManager\Current\device\DeviceLock path.
We didn’t set those DeviceLock MaxInActivityTimeDeviceLock settings. So, why were they there? That’s when we realized this wasn’t an accident. It was the clue we were searching for.
Chasing the Clue: DeviceLock CSP
This is where things started to make sense. The registry values were tied to the DeviceLock CSP, which handles lock screen settings like password timeout and inactivity duration. But this CSP isn’t acting on its own, and it’s powered by something else: Exchange ActiveSync (EAS).
The DeviceLock CSP utilizes the Exchange ActiveSync (EAS) policy engine. Because it relies on EAS, it was clear that the corresponding registry keys in the currentcontrolset\eas\policies path also showed up.
Somehow, EAS also enforced device security policies, including the MaxInactivityTimeDeviceLock setting, which controls how long a device can stay idle before locking. And just like that, all our devices were locked into a 5-minute inactivity timeout. Users had to enter their PIN far sooner than expected.
The Real Trigger: Compliance Policy
Once we connected the dots, it all made sense. We didn’t manually configure the MaxInactivityTimeDeviceLock setting; EAS was pushing it out. Want to know what triggered it? The Lock Screen policy was automatically deployed the moment a specific compliance policy was applied.
Take a look at the above compliance policy in question: it had a setting called “Maximum minutes of inactivity before password is required,” set to 1 minute. The second this compliance policy was applied, EAS kicked in and pushed these settings to all devices. Even though you didn’t configure the inactivity timeout yourself, EAS took care of it, syncing the setting across the entire fleet. That’s why all your devices started locking after just a minute of inactivity.
How EAS + DeviceLock CSP Work Together
This isn’t just a one-off situation. When compliance policies include device lock requirements, EAS doesn’t just evaluate compliance, it enforces it.
So, if your compliance policy includes:
- Minimum password length
- Password complexity
- Inactivity timeout
…EAS will push those down, using DeviceLock CSP, even if your config profiles stay silent.
This also affects all accounts on the device! For example, if you configure password complexity rules, EAS will flag users to change their passwords on next sign-in to meet requirements.
In other words, your compliance policy is doing more than checking boxes; it’s actively setting the rules.
Best Practices and How to Avoid Intune Lock Screen Timeout
Here’s how you can prevent this from happening again:
- Know what compliance policies enforce. Especially anything under “System Security” — those settings are not passive.
- Understand the role of EAS. It doesn’t just sync email , it can enforce security settings silently.
- Check the registry. Look under PolicyManager\Current\device\DeviceLock , and
controleaspoliciessee if something feels off. - Test before rollout. Always pilot compliance changes on a small group before wide deployment.
- Tweak the timeout if needed. If one minute is too aggressive, bump it up to something that fits your organization better.
A Real-World Example: Web Sign-In Breaks After Autopilot
This isn’t the only time DeviceLock policies have caused unexpected behavior. We also encountered a scenario where Web Sign-In vanished after Autopilot pre-provisioning, making it impossible for users to log in with their Temporary Access Pass (TAP). No error message, just a missing login method.
After some digging, the root cause pointed to the DeviceLock CSP, again triggered by a compliance policy that set a short inactivity timeout. That single setting disrupted the login experience entirely.
This shows just how easily DeviceLock settings, especially when enforced silently via EAS, can cause bigger problems than just screen lock frustration.
Final Thoughts
So no, you weren’t imagining things. The lock screen behavior wasn’t a bug or a misconfigured profile. Compliance enforcement was in action, quietly delivered through EAS and the DeviceLock CSP.
The takeaway?
Compliance policies can do more than you think. EAS isn’t just about old-school Exchange email settings; it’s about applying security policies whether you asked for them or not.
Always double-check what your policies are enforcing behind the scenes. Because in Intune, a bug can be a feature!