Build or Buy for Verifying Every Device That Connects?

Device identity, cryptographically proving this is the same device that was enrolled, not an impersonator, is a narrower, more solved problem than device posture, is this specific device currently patched, encrypted, and free of known compromise right now. A device can have a perfectly valid identity certificate and still be running an outdated operating system with a known exploited vulnerability. Treating identity verification as sufficient on its own is a common gap: it proves the device is who it says it is, not that it's safe to trust.

A workable in house approach needs a certificate authority you control, an enrollment process that ties a certificate to a specific device rather than a shared credential, and a revocation path that actually gets checked on every access attempt, not just at enrollment. This is a real, ongoing operational burden: certificate rotation, revocation list distribution, and handling the edge cases of lost or reimaged devices all need continuous attention. Teams that build this and then understaff its maintenance end up with a system that technically exists but that nobody trusts enough to actually gate access on.

Continuous posture checking, confirming a device is still patched and healthy at the moment of each access request rather than only at enrollment, is where platforms built for this, CrowdStrike and Tenable both play here from different angles, tend to earn their cost. CrowdStrike focuses on endpoint detection and real time compromise signals, Tenable focuses on vulnerability and exposure visibility across the fleet. What to check before choosing: whether the platform's posture signal integrates directly into your actual access decision point, not just into a separate dashboard nobody checks during the access moment itself.

Posture checks need a concrete bar for what counts as healthy enough to trust, and federal remediation guidance is a reasonable one to anchor to even outside government work: a device with a high severity vulnerability on an internet accessible system should be remediated within thirty days, and a known exploited vulnerability gets a much tighter clock¹. If your posture check's definition of healthy is looser than that clock, a device that's technically passing your check could still be carrying a known exploited vulnerability well past the point it should have been fixed.

Build identity verification in house if you already have device management infrastructure that can tie certificates to enrolled devices reliably, since that part is well understood and doesn't need to change often. Buy posture checking, since it requires continuous threat intelligence and vulnerability data that's genuinely expensive to maintain independently and that a specialized platform updates constantly as new threats emerge. Compare the leading endpoint platforms once you've settled the identity side and are evaluating posture vendors specifically.

Put the split into practice like this:

• Build device identity in house if your device management already ties certificates to enrolled devices reliably, since that part is well understood and rarely changes.
• Buy posture checking from a specialist, since it depends on continuous threat and vulnerability data that is expensive to maintain independently.
• Set the posture bar to a concrete patch clock instead of a vague sense of what counts as healthy.
• Price the in house option with certificate rotation and revocation upkeep included, not just the initial build.

Say a team estimates building certificate based identity verification will take one engineer six weeks to stand up. That estimate almost never includes the ongoing cost: rotating certificates before they expire, handling a lost or reimaged device without locking out its owner, and keeping the revocation list synced across every access point that checks it. Add a realistic ten to fifteen percent of one engineer's time every quarter after launch for exactly that maintenance, and the true first year cost is closer to double the initial build estimate. Running that fuller number past whoever approved the original six week estimate is often what actually settles the build versus buy question, more than any feature comparison.