Device Posture Checks That Actually Catch Unmanaged Laptops

TL;DR

Device posture is the verification that a device meets security expectations before and during access to protected resources. The difference between a posture check that works and one that is a checkbox exercise comes down to which signals you check, how often you check them, and what you do when the check fails. Most deployments check too few signals, only at tunnel establishment, and either deny access entirely or let everything through without an intermediate response. This post describes twelve posture signals that actually catch unmanaged or compromised laptops, shows how to implement continuous re-evaluation, and ends with a practical policy framework. All examples are platform-agnostic — the specific signals available on macOS, Windows, and Linux differ in how they are collected, but the policy model is the same.

Who this is for

Security engineers and architects designing or reviewing a device-posture policy. IT administrators rolling out a ZTNA product that includes posture features. CISO-team members writing the policy document that the engineers will implement.

Table of contents

1. Why most posture checks fail
2. Twelve signals that work
3. Gating posture vs continuous posture
4. Signal sources: agent, MDM, EDR, OS-native
5. Policy model — fail-open, fail-closed, or remediate
6. Integrating MDM and EDR signals
7. BYOD posture without full management
8. The 15-minute implementation start
9. Common anti-patterns to avoid
10. What auditors ask about posture

1. Why most posture checks fail

Three failure modes.

Only at login. A posture check at tunnel establishment confirms the state at that moment. Ten minutes later, if the user disables their EDR for a debugging task, the ZTNA does not know. The session continues with the same access rights. Attackers exploit this window.

Too few signals. A check for “disk encryption enabled” satisfies the policy document but does not catch a compromised machine whose disk encryption is fine but whose EDR is crashed. Multiple signals together are much harder to game.

Binary enforcement without remediation. A policy that denies access to any device failing posture forces users to disable posture or run around it. A policy that silently grants access to failing devices provides no security. A middle path — restricted access plus a remediation flow — keeps users productive while protecting resources.

A good posture implementation addresses all three.

2. Twelve signals that work

Ranked roughly by value for a typical commercial deployment.

2.1 Disk encryption

Whether the device’s disk is encrypted (FileVault on macOS, BitLocker on Windows, LUKS on Linux). This is the foundational signal: a device that has lost disk encryption has likely been modified or is running in an unusual configuration. Most posture products check this natively.

2.2 OS version and patch level

Is the device running a supported OS version with recent patches? A machine on an unsupported or out-of-date OS has known vulnerabilities. Specify an acceptable minimum per OS family.

2.3 EDR or antivirus status

Is an approved EDR (CrowdStrike, SentinelOne, Microsoft Defender, etc.) running and reporting healthy? This is often checked by presence of a specific process or registry key. The policy should specify the list of acceptable products.

2.4 Firewall state

Is the host firewall enabled? Windows Defender Firewall, macOS Application Firewall, or a Linux equivalent. A disabled host firewall is a meaningful risk indicator.

2.5 Screen lock configuration

Is an automatic screen lock configured to trigger within a reasonable interval (commonly 5–15 minutes)? An unlocked device left on a train, plane, or shared desk is a significant exposure; screen-lock policy reduces it.

2.6 MDM enrolment

Is the device enrolled in the organisation’s MDM (Jamf, Intune, Workspace ONE)? For corporate-owned devices, this is the baseline for management. For BYOD, MDM may be optional.

2.7 Certificate presence

Is a specific corporate certificate installed on the device? Useful for machine identity validation, especially for devices that have been pre-provisioned for specific roles (code signers, infrastructure admin laptops).

2.8 Required software presence

Is specific required software installed — password manager, VPN client, EDR agent, IDE with required extensions? Varies by role.

2.9 Prohibited software absence

Is specific prohibited software absent — known risky tools, unauthorised file-sharing clients, unapproved messaging apps? Harder to enforce; more useful as a detective control.

2.10 Network context

What network is the device currently on — corporate Wi-Fi, home, public hotspot? Does the device have unusual DNS or proxy configuration? Context can escalate or lower confidence.

2.11 Geographic location

Where is the device — country and rough locality? Can be used to detect impossible travel (device in two countries within an hour) and to enforce geographic access restrictions for regulated data.

2.12 Behavioural risk signal

Aggregate risk score from login patterns, access history, and prior alert activity. A device with no prior anomalies scores well; a device with recent alerts scores lower. Typically a derived signal from SIEM or UEBA integration.

3. Gating posture vs continuous posture

Two models.

Gating posture. Check at tunnel establishment or session start. Gate access at that moment. Do not re-check during the session.

Continuous posture. Check at tunnel establishment, then re-check on a regular interval during the session. Terminate or restrict the session if posture degrades.

Continuous posture is meaningfully better for several reasons.

1. Catches in-session compromise. A device that passes posture at login but is compromised ten minutes later is detected.
2. Catches user-driven policy violations. A user who disables EDR to debug something trips the policy within minutes.
3. Supports step-down access. Rather than binary terminate, a continuous-posture ZTNA can silently downgrade access when a signal degrades.

The overhead of continuous posture is low — typically a check every few minutes. Modern ZTNA products include it natively.

4. Signal sources: agent, MDM, EDR, OS-native

Where the signals come from matters for reliability.

4.1 ZTNA agent

The ZTNA client itself collects many signals: disk encryption state, OS version, firewall status, screen lock settings. Direct, low-latency, native to the client. Limitation: the agent runs as a user process (or daemon) and can be bypassed by a compromised endpoint.

4.2 MDM

Signals from the corporate MDM are authoritative because MDM is typically at a higher privilege level than the agent. Signals: enrolment state, configuration profile compliance, managed apps present. Integration via MDM APIs.

4.3 EDR

Signals from the endpoint detection and response product are the most trustworthy for behavioural signals. EDR kernel-level visibility, active threat indicators, process trees. Integration via EDR API or SIEM.

4.4 OS-native

Some posture signals are available through native OS APIs — macOS’s MDM server queries, Windows’ SCCM or Intune, Linux’s systemd state. Direct but platform-specific.

Best practice: cross-check critical signals across two sources. If the ZTNA agent reports EDR healthy but the EDR’s own API says degraded, the device fails posture. This catches tampering with the ZTNA agent.

5. Policy model — fail-open, fail-closed, or remediate

Three policy shapes.

Fail-closed. Any posture failure denies access entirely. High security, user-hostile. Works for high-sensitivity resources; overkill for general productivity.

Fail-open. Posture failure is logged but access continues. Useful telemetry; zero enforcement. Almost never appropriate as the final policy.

Remediate. Posture failure triggers a remediation flow — user sees a dialog explaining what is wrong and how to fix it, access to a reduced set of resources is granted (typically just the remediation resources), and normal access is restored when posture recovers.

Good deployments use fail-closed on high-sensitivity resources and remediate on general-purpose resources, with fail-open observability for two weeks before any enforcement is turned on.

6. Integrating MDM and EDR signals

Two integration patterns.

6.1 Direct API integration

The ZTNA queries the MDM or EDR API directly for a specific device. Real-time, requires API credentials and maintenance of the integration. Higher engineering cost upfront; less ongoing overhead.

6.2 SIEM-mediated integration

The ZTNA subscribes to a SIEM’s event stream. The MDM and EDR forward events to the SIEM. The ZTNA reacts to events. More infrastructure but composable with other security telemetry.

Either works. Direct integration is simpler if your ZTNA supports it natively (most modern ones support major MDM/EDR vendors). SIEM-mediated is more flexible if you have heterogeneous tooling.

7. BYOD posture without full management

For devices not enrolled in MDM, a limited posture set is achievable with a lightweight agent. Typical BYOD posture:

• Disk encryption enabled.
• OS version in supported range.
• Host firewall enabled.
• Screen lock configured.
• No known malicious processes (if the ZTNA agent can see this).

What BYOD cannot verify without management:

• Whether the device has been modified.
• Whether prohibited software is absent.
• Whether a corporate certificate is installed.

Policy consequence: BYOD access is typically scoped to a smaller, less-sensitive subset of resources. Email, web-based productivity tools, public-facing information. High-sensitivity resources (code repositories, customer data, financial systems) require managed devices.

8. The 15-minute implementation start

If you are deploying device posture for the first time with a ZTNA product, this is the shortest path to meaningful coverage.

# Concept: most ZTNA products expose posture via policy rules.
# QuickZTNA CLI example (pseudo-syntax — check current docs):

# Step 1: Enable posture collection on all devices.
ztna policy posture enable --all

# Step 2: Start in observe mode. Collect telemetry, do not enforce.
ztna policy posture mode --set observe --duration 14d

# Step 3: After two weeks, review the telemetry to find
#         which devices would have been denied under each rule.

# Step 4: Enable enforcement rule by rule, starting with disk encryption.
ztna policy posture rule set --name disk-encrypted --enforce deny

# Step 5: Layer on additional rules with fail-open remediate for two more weeks.
ztna policy posture rule set --name edr-healthy --enforce remediate

# Step 6: Escalate to fail-closed on sensitive resources only.
ztna policy posture resource-group prod-db --require disk-encrypted edr-healthy

The incremental rollout matters. Turning on all rules with fail-closed on day one produces a user-support wave you will regret. Observe-then-remediate-then-enforce over four to six weeks avoids that.

9. Common anti-patterns to avoid

Six specific mistakes.

9.1 Posture check only at login

Covered in section 3. Use continuous posture.

9.2 Too few signals

A single signal is a single thing to defeat. Three to six uncorrelated signals make bypass significantly harder.

9.3 Posture rules not versioned

Posture rules change. A ZTNA that keeps only the current set loses the audit trail. Version the rules like code.

9.4 No remediation path

A policy that denies access with no explanation and no fix produces user helpdesk tickets. Every deny should include a message pointing the user to remediation.

9.5 Sensitive-resource posture applied to all resources

If the policy for database access applies to the user’s Confluence, users will rage-quit the ZTNA. Tier your resources and apply appropriate posture per tier.

9.6 Posture that trusts the device’s self-report alone

If the device says “I am encrypted”, the ZTNA should cross-check with MDM or with a second source. A compromised device will lie about its own state.

10. What auditors ask about posture

Practical questions that come up in SOC 2, ISO 27001, and HIPAA audits (HIPAA details here).

1. What posture signals are required for access to which resources? Expect a written policy.
2. How is posture verified? Agent, MDM, EDR, combination.
3. How often is posture re-evaluated? Continuous is the strong answer.
4. What happens when posture fails? Deny, remediate, or step-down.
5. How are posture policy changes managed? Change control with ticket and approver.
6. Sample recent posture failures. Pick five. What did the user see? What was the resolution time?
7. BYOD posture. Different from managed-device posture? Why?
8. Posture signals tamper-resistance. Can a user disable EDR and still pass?
9. Relationship to incident response. Does a posture failure generate an alert?
10. Training. Are users trained on posture expectations?

A mature deployment answers all ten with documented artefacts. A new deployment answers the top five and acknowledges work-in-progress on the others.

Further reading

• NIST SP 800-46 Rev. 3 — Guide to Enterprise Telework, Remote Access, and BYOD Security.
• NIST SP 800-207 — Zero Trust Architecture.
• CIS Benchmarks for OS baseline configurations.

Related reading on this blog

• SOC 2 Controls for Remote Access
• HIPAA-Compliant VPN in 2026
• NIS2 Remote Access Requirements
• Open-Source vs Managed ZTNA

Try QuickZTNA

QuickZTNA ships continuous device posture (disk encryption, OS version, EDR, firewall, screen lock, MDM, certificate presence) and integrates with major MDM and EDR vendors. Policy modes support observe, remediate, and fail-closed per resource. Start on Free to evaluate — posture rules are available on every tier.