Verifying Devices Before They Touch Production, Not After

A real device trust check looks at a small set of concrete facts: is disk encryption on, is the operating system on a supported and patched version, is a screen lock enforced, and is the device enrolled in whatever management tool your company uses. None of that requires guessing at intent, it's all directly checkable.

What doesn't count as a trust signal: the device having passed a check once, being owned by a senior employee, or simply being on the office network. Those are all proxies that can be true of a compromised device just as easily as a clean one.

A device check can rely on these concrete, directly checkable facts:

• Disk encryption is turned on for the device.
• The operating system is on a supported version and is fully patched.
• A screen lock is enforced on the device.
• The device is enrolled in your management tool, and it loses trust immediately if it is removed.

A device approved once and never re-checked is a device you're trusting based on stale information. Real zero-trust verification checks the device's current state at the moment of access, not its state whenever it was last reviewed.

This matters most for patch status specifically, since a device can pass every other check and still be running software with a known, unpatched vulnerability that was disclosed after the last review.

The same logic applies to enrollment itself. A device removed from your management tool, whether because someone offboarded, reset their laptop, or simply uninstalled the agent, should lose trust immediately, not whenever the next scheduled review happens to notice it's missing.

A device's own vulnerability exposure is a legitimate part of the trust decision. Federal guidance treats a known, actively exploited vulnerability as urgent enough to require remediation within 14 days for anything assigned a CVE in 2021 or later, and a device still carrying that kind of unpatched flaw shouldn't be treated the same as one that's current, regardless of who owns it¹.

Scoring devices this way turns patch status from a background IT concern into a direct input on the access decision itself, which is closer to what zero trust is actually supposed to mean.

It's common to build strong device checks for the initial login and then let a session run indefinitely afterward, with no re-verification while the device is connected. A laptop that was clean at 9 a.m. and gets compromised at 2 p.m. keeps its access under that model until the session naturally expires.

Re-checking at a reasonable interval during a live session, not just at login, closes that gap without requiring the user to re-authenticate constantly.

For example, a team could check device state at login and again at a regular interval during the session. If a laptop that was patched in the morning is later found to have disk encryption switched off, or to be missing from the management tool, its session loses access to sensitive systems while less sensitive tools stay available. This keeps people working without trusting stale information. A useful decision rule: the more sensitive the system, the shorter the interval between re-checks, and the sooner a failed check should cut access.

Start by observing and logging which devices would fail the checks, without actually blocking access, for a couple of weeks. That surfaces exactly how many legitimate devices are out of compliance before you flip the switch to enforcement, and gives people time to fix their own device instead of getting locked out mid-workday.

Move to enforcement in stages, starting with access to the most sensitive systems first, rather than applying a hard block everywhere at once on day one.

Give people a clear, self-service path to fix a failing device, a link to the exact setting that's missing, not just a denial message, before enforcement goes live. A rollout that blocks access without explaining why, or how to fix it, generates support tickets instead of compliant devices.