What it is
The Endpoint Posture Requirements Checklist defines the device-health bar every endpoint must clear before it's allowed to connect remotely — the posture policy that sits between an unmanaged, out-of-date, possibly-compromised laptop and your production environment. It hands you a concrete baseline (supported, patched OS within SLA; full-disk encryption verified; screen lock enforced; EDR installed, running, and healthy; host firewall on; MDM-enrolled and compliant; no active malware or high-severity detections; not jailbroken/rooted), a device-class matrix that sets required vs. recommended signals for managed devices, BYOD, and vendor machines, an implementation sequence for wiring those signals into your ZTNA or conditional-access engine, and a set of decisions to fill in (patch SLA, no-exception targets, remediation path, residual privilege for partially-compliant devices, policy owner).
The core principle is that a remote session is only as trustworthy as the endpoint it originates from. The checklist makes that operational: collect the signals (connect MDM, EDR, and IdP device-compliance feeds to your access engine, each mapped to an authoritative source so nothing is self-reported), define the policy per device class, decide the failure path (block-and-remediate for hard failures like no encryption or EOL OS, quarantine for fixable gaps, step-up or reduced privilege for soft signals), and make it continuous (re-evaluate posture during long sessions, terminate or downgrade when posture degrades mid-connection, and log every decision as audit evidence).
The device-class matrix is what makes it practical. Managed devices are held to the full bar; BYOD gets work-profile MDM, managed-app EDR, and required encryption; vendor machines that can't be postured are routed through a VDI or jump host rather than trusted directly. The checklist is the device-trust domain of zero trust made concrete — it's the detailed companion to the posture line items in the zero-trust security checklist, and the policy your ZTNA migration will enforce.
What it's used for
Posture is the control that stops a valid credential on a compromised laptop from becoming the door into production. Teams use this checklist to define and enforce what 'healthy enough to connect' means:
- ✓ Writing a device-posture policy that specifies the exact health signals — encryption, patch SLA, EDR health, MDM compliance, no jailbreak — an endpoint must satisfy before any remote session starts.
- ✓ Setting different bars for managed devices, BYOD, and vendor machines using the device-class matrix, so each population gets a realistic but enforced standard.
- ✓ Wiring posture signals into a ZTNA or conditional-access engine from authoritative sources (MDM, EDR, IdP) so nothing is self-attested by the user.
- ✓ Deciding the failure path for every signal — block-and-remediate, quarantine to a remediation network, or step-up authentication — so a failed check never quietly becomes 'allow anyway.'
- ✓ Making posture continuous: re-evaluating during long sessions and terminating or downgrading a connection when a device falls out of compliance mid-session.
- ✓ Routing unmanaged vendor or contractor devices through a VDI or jump host instead of trusting them directly, because you can't posture-check a device you don't control.
- ✓ Logging every posture decision as evidence for access reviews and audits, turning device trust into something you can demonstrate rather than assert.
Who uses it
Posture sits between endpoint management and network access, so it's owned and consumed across both. The checklist gives each team its piece.
Context & good to know
Posture closes the gap that MFA leaves open. MFA proves who is connecting; posture proves what they're connecting from. A perfectly valid credential and a passing MFA prompt mean nothing if the laptop behind them is unpatched, unencrypted, or already compromised — the attacker inherits the session along with the legitimate user's access. Device posture is the control that makes the endpoint a condition of access, not an afterthought, which is why it's a core pillar of any real zero-trust deployment.
The two failures that make posture theater are self-attestation and an undefined failure path. If posture signals come from the user ticking a box rather than from MDM and EDR feeds, the check proves nothing — a compromised device will happily attest that it's healthy. And if no one decided what happens when a managed device fails a check, the default is silent: it gets allowed anyway. The checklist forces both decisions — every signal mapped to an authoritative source, and every signal assigned a concrete action (block, quarantine, or reduce privilege).
Continuous evaluation is what upgrades posture from a one-time gate to a genuine zero-trust control. A device can pass at connect time and be compromised minutes later; if posture is only checked at login, that window is wide open. Re-evaluating during long sessions — and terminating or downgrading when EDR fires or compliance drops — is what 'never trust, always verify' actually means at the endpoint. It's also where tooling differs: not every remote-access or ZTNA stack supports mid-session posture re-evaluation, which is a real selection criterion when comparing platforms.
The device-class matrix reflects an unavoidable reality: you control managed devices, partially control BYOD, and don't control vendor machines at all. The honest answer for unmanaged devices isn't a weaker posture check — it's not trusting them, and routing them through a managed surface (VDI or jump host) where the posture you can enforce lives on the broker side. Getting this matrix right is what lets you say yes to BYOD and vendor access without quietly importing their risk into production. It's the same logic the vendor access request form applies at grant time and the ZTNA migration plan enforces at the network layer.