Zero-Trust Device Checks: What's Worth Building vs. What to Buy
Zero-trust device verification, checking that a device meets your security posture before it's allowed to reach anything, sounds like a single feature but breaks down into pieces with very different build-versus-buy economics. Here's how to split it so a small team spends engineering time only where building actually saves money.
Vendors Covered in this Article
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
Should you build or buy device posture checks?
Verifying that a device has disk encryption on, a screen lock enabled, and an up-to-date operating system requires an agent running on every employee's machine across whatever mix of operating systems your team uses. Building and maintaining that agent yourself is a multi-person, ongoing commitment that rarely makes sense outside a company whose product is security tooling itself.
This is squarely a buy decision for a small team, and it's usually the first piece a zero-trust rollout should put in place, since it's the foundation the rest of the checks build on.
Access policy logic: build this yourself
Deciding which specific resources a given role, device posture, and network context should be allowed to reach is business logic specific to your systems, not something a vendor can define for you out of the box. Most identity and device platforms expose a policy engine or API for exactly this reason: they check the device, you decide what a passing check should allow.
Write this policy down explicitly, service by service, rather than accepting a platform's default "trusted device = full access" setting. The value of zero-trust comes from the specificity of the policy, not from the posture check alone.
Network segmentation: mostly build, with buy-in for the identity layer
Actually segmenting your network so a verified device only reaches what its policy allows is infrastructure work: firewall rules, service mesh policy, or cloud security groups configured to check identity and posture signals rather than just network location. This part is genuinely yours to build, because it's wired into your specific infrastructure topology.
Where buying helps is the identity provider that issues the signal your segmentation rules check against. Building your own identity and device-trust signaling from scratch is a much larger project than most small teams should take on.
Why does zero-trust need continuous verification, not a login check?
A device that passes its posture check at login and is never checked again defeats much of the purpose: a laptop can lose disk encryption, fall out of date, or leave a monitored network hours into a session. The genuinely hard part of zero-trust, the piece worth paying a vendor for, is continuous, low-friction reverification that doesn't require the user to log in again constantly.
Check what your identity platform actually supports here before assuming continuous verification is included; some plans check posture at login only, and the continuous version is a separate tier worth confirming before you build a rollout plan around it.
A rollout order that avoids the common failure mode
Roll out posture checks first, in monitor-only mode, so you see what would have been blocked before you start blocking anything. Add explicit access policy second, service by service, starting with your highest-sensitivity systems. Add network segmentation third, once policy is stable. Teams that try to do all three at once tend to lock legitimate users out during the rollout, which burns the goodwill needed to finish it.
A rollout order that keeps legitimate users working:
- Deploy device posture checks first, in monitor-only mode, so you can see what would have been blocked before anything is.
- Add explicit access policy second, service by service, starting with your highest-sensitivity systems.
- Add network segmentation third, once the policy is stable and you trust what it allows and denies.
- Write the exception process down before enforcement starts, including how long an approved exception may stand before review.
Handling the exceptions that always come up
Some device or scenario will always fall outside your standard policy: a contractor on a personal laptop, a kiosk device that can't run the standard agent, a legacy system that predates the rollout. Decide how exceptions get approved and how long they're allowed to stand before someone reviews whether they're still needed, rather than letting an exception granted once become a permanent, unreviewed hole in the policy.
Write the exception process down before the rollout starts. Handling the first real exception request without a process in place tends to produce a decision made under pressure that becomes precedent for every exception after it.
For example, a contractor needs access for a few weeks from a personal laptop that cannot run your posture agent. Without a process, someone approves it under pressure, and the exception quietly becomes permanent. With a written process, the request names an approver, limits the contractor to the specific services needed, and carries an expiry date that triggers a review. When that date arrives, the reviewer either closes the exception or renews it on purpose. The value is not the individual decision but the precedent: every later exception follows the same visible, time-limited path instead of an ad hoc one.
What Good Looks Like
Good zero-trust practice means device posture, access policy, and network segmentation are each owned deliberately, with continuous reverification rather than a one-time login check.
Building The Capability (5-Stage Skill Ladder)
How to Get Started
Disclosure: We may earn a commission if you buy through some links on this page. It doesn't change what we recommend.
CrowdStrike's endpoint agent is a common source of the posture signal a zero-trust policy checks against, covering the device-health piece this article argues is worth buying outright.
Tenable's device and vulnerability data is a useful second signal to feed into access policy, since a device can pass a basic posture check and still be running software with known, unpatched vulnerabilities.
Frequently Asked Questions
Do we need zero-trust if our team is fully in-office on one network?
The value is lower but not zero. A compromised device on a trusted office network is still a compromised device, and posture checks catch that regardless of where someone's sitting. Prioritize it lower than a distributed team would, but don't skip it entirely.
How disruptive is a zero-trust rollout to day-to-day engineering work?
Rolled out in monitor-only mode first, disruption is minimal since nothing actually blocks access until policy is confirmed correct. Skipping the monitor-only phase and enforcing policy immediately is the most common cause of a rollout that generates enough friction to get rolled back.
Can we start with just posture checks and add policy later?
Yes, and that's usually the right order. Posture checks alone still give you visibility into device risk even before any access decision depends on them, which makes the later policy work easier since you'll already know what a typical device on your team actually looks like.
About the numbers
This guide doesn't quote a sourced benchmark. Figures in it are estimates or general guidance, so check them against your own numbers.
Related Guides
Building a Continuous Evaluation Suite Engineers Trust
How to design continuous evaluation checks for critical systems that engineers actually trust and act on, instead of ignoring like flaky tests.
Where Production Deployment Budgets Actually Leak
The five places a production deployment pipeline quietly burns engineering time and cloud spend, and how to find each one in your own setup.
Catching a Breaking API Change Before Your Customer Does
How automated contract testing catches breaking changes between services before they reach production, and where teams usually skip it.
Why SOC 2 Prep Breaks Down After the Kickoff Meeting
The point where most SOC 2 readiness efforts stall, and how continuous evidence collection changes what the six months before an audit actually look like.
Continuous Device Verification for a Zero-Trust API
How continuous device and identity verification actually works in a zero-trust architecture, and where to draw the line for a small engineering team.
A Runbook for Zero-Downtime Schema Migrations on a Live Database
A step-by-step runbook for running schema migrations against a production database without an outage window, including the rollback checkpoints.