A colleague grabbed me as I walked past their desk. "Why isn't my computer locking?" they asked. We have a corporate policy - a few minutes of inactivity and the screen locks. Simple, sensible, standard stuff. Except theirs wasn't doing it. They'd step away for an hour, come back, and the machine would be sitting there wide open.
A whole team of people had apparently looked at this already. GPO was confirmed applied, the timeout was definitely set, the policy was pushing correctly. Everything looked fine on paper. No one had an answer.
I started asking the usual questions, and while I was talking to them I noticed something. The optical mouse on their desk was pulsing. The red light underneath would brighten, then dim, then brighten again, every few seconds.
If you know how optical mice work, you'll know that the sensor light doesn't burn at a constant brightness - it ramps up when there's movement to track and drops back down when there isn't. What I was watching was a mouse that thought it was moving.
"It's your mouse," I said, and swapped it out.
Problem solved. The wire inside the old mouse had gone intermittently faulty and was nudging the cursor by a single pixel every few seconds. Completely invisible to the user - you wouldn't notice a one-pixel drift if you were sitting right in front of it - but more than enough to convince Windows that the machine was in active use.
The bit worth taking away
When a machine isn't locking on inactivity, there are really only two possible causes: either the policy isn't configured correctly, or something is feeding it input. That's it. The whole problem space in two options.
If you've confirmed the policy is set correctly - and in this case multiple people had - then by definition it has to be the second one. Something is telling the computer it isn't idle. The question stops being "why isn't the policy working?" and becomes "what is the input and where is it coming from?"
It could be a mouse. It could be a USB device polling aggressively. It could be a piece of software sending synthetic input. But it's something, because the alternative - that the OS is correctly receiving a valid policy and then simply ignoring it for no reason - is vanishingly unlikely, and you should rule out the mundane before you go looking for ghosts in the machine.
A whole team had stared at the software side of this and found nothing wrong, because nothing was wrong. The problem wasn't where they were looking.
Sometimes it really isn't what you think.