Anyone who has worked with smart card and Windows clients have probably seen that on rare occasions users can pull their smart card from the smart card reader and the machine will not be locked although it should be locked instantly. As this typically only occur very rarely it is extremely hard to troubleshoot. However, things are coming together with a cause that makes sense and also shed some light on this elusive problem.
A smart card is enforced to be used to login to machines in Windows 7 or Windows 10. GPO settings declare that when the smart card is removed from the smart card reader, the machine will be locked.
When the user removes the smart card from the smart card reader, the machine is not locked (rarely). Most of the times the machine is locked but occasionally the machine is not locked and the user can continue to work inside Windows with the card in their hands.
The Smart Card Removal Policy service has been restarted and when it restarts, the session to keep control over when the smart card is pulled from the card reader is lost and therefore the machine is not locked. The cause of Smart Card Removal Policy service being restarted is when new Windows patches are released and installed on the machines, specifically many of the latest Cumulative Updates for Windows 10 causes the problem. The issue is more rarely seen in Windows 7, likely due to the changes in updating/patching strategy in Windows 7 vs Windows 10 which differs quite a lot.
None by Microsoft as this is by design (bad design I might add). A solution is to use a third party smart card tool that provides its own service to lock the machines.
The restart of this service does not trigger any events in the Event Viewer so we cannot trigger on anything. By design the machine should be locked whenever the Smart Card Removal Policy service is restarted but that does not happen. Could there be problems with that design? Probably, otherwise I suppose it would work that way already Microsoft!? :)