Build vs. Buy for Verifying Every Device That Connects In

A real zero-trust check confirms identity (who is this, with strong authentication, not just a password), device posture (is this device compliant: patched, encrypted, not jailbroken or rooted), and does both continuously rather than once at the start of a session. A system that checks identity at login and then trusts the session indefinitely is not zero trust, no matter what it's called internally; the continuous part is what makes it meaningfully different from a traditional perimeter.

A real zero-trust check confirms three things:

• Identity, meaning strong authentication of who is connecting, not just a password.
• Device posture, meaning the device is compliant: patched, encrypted, and not jailbroken or rooted.
• Both of the above continuously during a session, rather than only once at login.

A homegrown version means integrating your identity provider's continuous authentication signals, building or integrating device posture checks across every operating system your team uses, and wiring both into every application and network path you want protected, not just the ones that are convenient to instrument first. This is a substantial, ongoing engineering commitment, not a project with a clean finish line, because new applications and new device types keep showing up after the initial rollout.

Platforms built for this, such as CrowdStrike for endpoint posture or Tenable for exposure and vulnerability context, maintain device posture signals across operating systems and device types as an ongoing product, which is exactly the part that's hardest to keep current in a homegrown build. What they don't do is make the identity and access policy decisions for you; that mapping, of which resource requires which posture level, is still a decision your team has to make and maintain.

If your team's devices are largely company-managed and homogeneous, a lighter homegrown check tied to your existing device management tooling may cover most of the real risk. If your team includes contractors, a range of personal devices, or a fleet spanning several operating systems, the ongoing cost of keeping a homegrown posture check current across all of them usually exceeds the cost of a platform built to maintain that breadth as its core product.

To apply the rule, count how many device types and operating systems actually connect today. For example, a team of company-managed laptops with a couple of contractors on personal machines has a mixed fleet even if most devices are uniform, and the contractor devices are usually where posture checks are hardest to maintain. Start by writing down each group, who manages it, and whether your existing device management tooling can report its condition. If a group falls outside that tooling, that gap is the strongest argument for a platform. If every group is covered, a lighter check may be enough, so revisit the count whenever your hiring or contractor mix changes.

Rolling zero-trust verification out to every internal tool on day one is how these projects stall. Start with the systems where a compromised session would do the most damage, get continuous verification working well there, and expand from a working example rather than trying to cover the full estate before anything is actually enforced. A known exploited vulnerability on an unverified device is exactly the kind of gap this is meant to close, and it's worth closing on your highest-value systems first.

A contractor whose managed device hasn't checked in for a week, a new employee whose posture agent hasn't finished enrolling, a legitimate but unusual login from a new location: every real rollout hits cases where a strict continuous check would block someone who has a genuine reason to get in. Decide ahead of time who can grant a time-boxed exception and how it gets logged, rather than leaving the first real case to be improvised by whoever is on call when it happens. An exception process nobody trusts gets worked around quietly, which defeats the point of the system.

A verification system that blocks legitimate work often enough gets its checks quietly disabled by frustrated engineers long before it ever stops a real incident, so track false positives and support tickets from the rollout with the same attention you give coverage percentage. A system with perfect theoretical coverage that nobody actually complies with protects nothing in practice.