Continuous device posture: signals, scoring and re-evaluation between connections

Continuous device posture evaluates endpoint security state on an ongoing basis, not just at login. Modern SASE and ZTNA platforms collect 15 to 20 signal types, score them with binary or risk-based models, and re-evaluate on time, event or risk triggers. Hardware attestation distinguishes verified signals from self-reported claims. Done well, it reduces breach blast radius without disrupting the user.

A laptop that passes every check at 9am can be compromised by 9:15am. If the access decision was cached at login and not revisited until the next morning, that device sits on your network for hours with full privileges and an active threat. Point-in-time device posture, the model most organisations still run, creates exactly this window.

If you have read our NIS2 device posture guide, this post goes one level deeper into the technical mechanics. Where that guide covers what to check and how it maps to CyFun controls, this one covers the signal taxonomy, scoring models, re-evaluation triggers and failure modes that determine whether posture enforcement actually holds under pressure.

The 20+ device posture signals modern platforms evaluate

Signals fall into seven categories: hardware, operating system, storage, security tools, network, identity/browser and mobile-specific. Most enterprise SASE platforms evaluate 15 to 20 distinct signal types, though few organisations enforce all of them simultaneously. The taxonomy below maps each signal to its verification mechanism and defining standard.

SASE agents collect these signals through three primary mechanisms. Native OS APIs let agents query the Windows Security Center API or macOS System Configuration directly. Vendor agent self-reporting bundles telemetry from registry keys, active processes and certificate footprints and sends it to the cloud control plane. Third-party integrations pull compliance state from MDM or EDR platforms via API, as when Cato Networks queries Microsoft Intune or Zscaler calls CrowdStrike Falcon for device health ratings.

A fourth path, browser-based collection, applies in agentless scenarios. The platform parses User-Agent headers and Client Hints but cannot inspect kernel integrity, disk encryption or local processes. Visibility is limited. For organisations with contractor or third-party access requirements, this is where browser isolation as fallback becomes relevant.

Signal collection: agent self-reporting vs verified attestation

An agent reading a registry key to report “BitLocker is enabled” is a self-report. If malware with administrative privileges compromises the endpoint, it can hook OS APIs, modify registry values or manipulate the agent process to return a compliant status regardless of actual state. Self-reports are convenient. They are not proof.

Hardware attestation uses a hardware root of trust, the TPM 2.0 or Apple Secure Enclave, to sign reported measurements cryptographically. During Windows Device Health Attestation, the boot sequence is measured into Platform Configuration Registers within the TPM. These registers cannot be modified by the OS or local software. The TPM generates a signed quote using its private Attestation Identity Key, bound to the physical hardware. A remote attestation service such as Azure Attestation verifies the signature against the manufacturer’s Endorsement Key and compares PCR values to known-good baselines. If verified, the service issues a Health Attestation Certificate that the SASE platform can evaluate.

Apple Managed Device Attestation follows a similar pattern. The Secure Enclave generates hardware-bound key pairs, allowing macOS and iOS devices to sign statements verifying that the operating system has not been tampered with and that device identity is cryptographically tied to the hardware.

When is self-reporting sufficient? On managed devices in controlled environments where the agent runs on corporate-owned hardware with MDM enforcement, the risk of signal spoofing is lower. When does attestation matter? On BYOD devices, for access to high-value resources, and anywhere the threat model includes administrative-level compromise of the endpoint.

Scoring models: binary, multi-state and risk-based

Three scoring approaches dominate in 2026. Binary (compliant or non-compliant) suits simple deployments. Multi-state (compliant, warning, blocked) supports graduated response. Risk-based scores (0 to 100 with tiers) enable nuanced conditional access policies. Each carries operational trade-offs.

Binary scoring applies a strict rule set. If any mandatory signal fails, access is denied. Microsoft Entra Conditional Access uses this model in its basic configuration: a device is either compliant or it is not. The advantage is simplicity. The disadvantage is operational disruption. A single expired certificate or missed patch locks out an otherwise healthy device.

Three-state scoring adds a warning tier. If a non-critical signal fails, say an OS patch is seven days overdue, the platform restricts access to high-sensitivity resources while keeping basic collaboration tools available. The user receives a remediation prompt. This reduces helpdesk tickets without abandoning enforcement.

Risk-based scoring aggregates telemetry into a numeric index. The CrowdStrike Zero Trust Assessment (ZTA) score calculates risk from observed vulnerabilities, configuration state and runtime security events, producing a score from 1 to 100. SASE partners including Zscaler and Cloudflare evaluate this score in their conditional access policies. Organisations define threshold tiers: a device scoring above 70 gets full access, between 40 and 70 gets restricted access, below 40 gets blocked.

A fourth variation, per-resource conditional access, decouples global compliance from specific applications. An unmanaged device can reach the corporate intranet but accessing financial systems requires perfect scores on disk encryption, hardware attestation and active EDR presence.

When platforms re-evaluate: time, event, risk and user triggers

Four re-evaluation patterns keep posture verdicts current. Time-based triggers poll on a fixed cadence. Event-based triggers fire when signals change. Risk-based heuristics re-evaluate when behavioural analytics detect anomalies. User-initiated triggers invalidate sessions on explicit actions. Modern platforms combine all four.

Specific re-evaluation intervals vary by vendor. Cato Networks supports continuous device check policies at a recommended interval of 10 minutes, with an allowed range of 5 to 1,440 minutes (Cato Networks, Device Posture Check Policy documentation). Zscaler Client Connector evaluates posture profiles on a default frequency of 15 minutes, with a configurable minimum of 2 minutes on Windows version 4.4+ and macOS version 4.5+ (Zscaler, Client Connector Administration documentation). For specific vendor integration checks involving CrowdStrike, SentinelOne or Microsoft Defender, Zscaler bypasses the polling interval and re-evaluates immediately when a state change occurs.

Microsoft Entra Continuous Access Evaluation takes a different architectural approach. Rather than periodic polling, CAE-compatible client applications subscribe to event streams from Entra ID. When a critical event occurs, such as a password change, user disablement or IP location shift, the resource provider rejects the existing token in near real-time, with observed latency up to 15 minutes for some events and immediate enforcement for IP location changes (Microsoft, Entra Continuous Access Evaluation documentation).

The trade-offs are predictable. Tight intervals (2 to 5 minutes) detect posture drift quickly but generate high agent-to-cloud telemetry traffic. Loose intervals (30 to 60 minutes) reduce overhead but leave a wider window for undetected compromise. Event-driven evaluation adds security depth with moderate overhead, since traffic bursts occur only during actual state changes.

For organisations progressing through the Zero Trust maturity model, combining event-driven and time-based triggers at a 10 to 15 minute cadence provides a reasonable balance for most mid-market environments.

Signal freshness and TTL: how long is a posture verdict valid?

Signal freshness, the time-to-live of a posture verdict, determines how long an access decision remains trustworthy after the last check. A verdict that was valid four hours ago may not reflect current reality. The device could have left the corporate network, disabled its firewall or been infected by malware.

Industry practice in 2026 clusters around these re-validation windows. Hardware signals (TPM attestation, Secure Boot) change rarely and a 24-hour TTL is common. OS patch signals shift more often, particularly after Patch Tuesday, and 6 to 12 hour TTLs are typical. EDR signals should be evaluated continuously or near-continuously, since an active threat can emerge at any moment. Network signals (firewall state, certificate store) are checked on every new connection or on the time-based polling cadence.

When a signal expires, three response patterns are common. Graceful downgrade maintains access to productivity tools (email, chat) but revokes access to databases and admin consoles until the agent checks in. Soft block redirects the user to a captive portal explaining that the security agent has not reported its status, with a manual “Refresh Connection” option. Hard lockout terminates the session immediately. The right choice depends on the resource being protected: a soft block for collaboration tools, hard lockout for financial systems or production control interfaces.

NIST SP 800-207 Section 3.4.1 addresses signal freshness through its Continuous Diagnostics and Mitigation requirements. The framework specifies that access is granted on a per-session basis, with authorisation dynamically recalculated throughout the connection lifecycle. The CISA Zero Trust Maturity Model 2.0 reinforces this at the “Optimal” stage of the device pillar, requiring real-time, continuous device posture checks with automated revocation when posture degrades.

Failure modes and edge cases

Continuous posture checking at scale introduces operational friction that IT teams need to anticipate. The most disruptive failures are not attacks. They are false positives that lock out healthy devices.

Captive portal collisions. A user on a flight connects to airline Wi-Fi. The SASE agent tries to reach its cloud gateway but the captive portal intercepts all HTTPS traffic. The telemetry check fails, the signal goes stale, and the endpoint gets locked out, preventing access to even offline-available corporate materials. Well-designed agents detect active captive portals and temporarily suspend hard compliance blocks while restricting access to browser-isolated SaaS applications.

Mid-session OS updates. A background patch finishes installing and changes active system binaries. If the agent runs an attestation check before the reboot, TPM PCR values may conflict with expected baselines. The device is temporarily non-compliant despite being fully patched. This is a timing problem, not a security problem, but it generates helpdesk tickets.

BYOD visibility limits. A personal Mac without MDM enrolment gives the SASE agent limited visibility. Apple MDM-only APIs are inaccessible. The platform falls back to software-level file path checks, which produce less reliable compliance signals. The practical mitigation: route BYOD traffic through browser isolation rather than attempting agent-based enforcement on devices you do not manage.

Signal spoofing. Malware with administrative privileges can hook the Windows Security Center API so that the agent queries return “compliant” regardless of actual state. Attackers can also capture a valid posture token from a healthy device and replay it from a compromised machine. Hardware attestation is the primary defence: by forcing endpoints to sign posture payloads with a TPM-locked private key, platforms prevent token replay on different hardware.

Real-world bypass cases illustrate the stakes. The Intune platform spoofing technique exploits gaps in Microsoft Entra ID conditional access by spoofing a User-Agent string to represent a platform with no configured policies, obtaining a token without MFA, then registering a simulated compliant device. The EvilTokens phishing kit, which surfaced in early 2026, compromised over 340 Microsoft 365 tenants by exploiting the OAuth device authorisation grant (RFC 8628) to register rogue devices under legitimate user identities. Both bypasses succeed because posture checks are tied to software-reported compliance rather than hardware-bound device identity.

Privacy boundaries for EU deployments

What a ZTNA agent can and cannot collect is not just a technical question in Europe. It is a legal one. EDPB Guidelines 05/2020 on consent in the workplace establish that the employer-employee power imbalance means consent is almost never a valid lawful basis for employee monitoring. Organisations must rely on Article 6(1)(f) GDPR (Legitimate Interest), supported by a documented Legitimate Interest Assessment and Data Protection Impact Assessment.

National-level requirements add further constraints. In Belgium, Collective Labour Agreements CCT No. 81 and No. 96 govern electronic workplace monitoring: monitoring must be transparent, serve a defined and legitimate purpose such as security or system integrity, and must not infringe on the private life of the employee. In Germany, Section 87(1) No. 6 of the Works Constitution Act grants the Betriebsrat co-determination rights over any technical installation designed to monitor employee behaviour. In the Netherlands, the Ondernemingsraad holds similar advisory and co-determination authority.

In practice, the separation is clear. Posture agents should collect device security state: OS version, patch level, encryption status, firewall status, EDR presence, device registration. They should not log personal browsing URLs beyond category-level web filtering, scan personal file content, record keystrokes, or continuously track GPS location. Coarse egress IP geolocation at authentication time is acceptable for impossible-travel detection. Continuous location tracking is not.

For organisations deploying across multiple EU jurisdictions, the safest approach is to design the signal collection scope around the most restrictive national framework and apply it uniformly. This avoids the operational complexity of jurisdiction-specific agent configurations.

How Jimber handles continuous device posture

Jimber’s SASE platform evaluates device posture natively as part of the access decision pipeline. When a user connects, the Jimber SASE platform checks identity through IdP integration (Microsoft Entra ID, Google Workspace, or other SAML/OIDC providers) and evaluates device signals against the organisation’s posture baseline. Access is per-application, not per-network, so the posture verdict applies to each resource independently.

For managed devices running the Jimber agent, the platform collects hardware signals, OS state, encryption status and security tool presence. Posture evaluation feeds into the same policy engine that handles Zero Trust Network Access and web filtering decisions. Policy changes propagate from the single management console to all enforcement points.

For devices that cannot run an agent, printers, IoT sensors, industrial controllers, posture-equivalent enforcement happens through NIAC hardware. Jimber’s ZTNA module and NIAC sit inline between the device and the network, restricting communication to explicitly permitted paths. The device does not need to report its own state because the network enforces boundaries around it. This is the IT-OT bridge that covers the gap most SASE platforms leave unaddressed.

For non-compliant or unmanaged devices, browser isolation serves as a graduated fallback. Rather than blocking access entirely, the platform routes the session through a disposable cloud container. The user can work. Malicious code never reaches the endpoint. The organisation maintains both productivity and security, without the binary lockout that generates helpdesk tickets.

Frequently asked questions

What is the difference between point-in-time and continuous device posture? Point-in-time checks evaluate device state once, at login. Continuous posture re-evaluates throughout the session using time-based, event-driven and risk-based triggers, so a device that becomes non-compliant after authentication gets detected and restricted.

How often should a ZTNA platform re-evaluate device posture? Most vendors default to 10 to 15 minute intervals. Zscaler supports a minimum of 2 minutes. Event-driven checks for EDR state changes should trigger immediately. The right cadence balances security depth against agent overhead.

What signals does device posture typically collect on a Windows laptop? Common signals include TPM 2.0 presence, Secure Boot status, OS version and patch level, BitLocker encryption state, host firewall status, EDR agent presence, Microsoft Entra ID join status, MFA enrolment and browser version.

Can a device posture agent monitor employee browsing history under GDPR? Not beyond category-level filtering. EDPB Guidelines 05/2020 and national instruments like Belgian CCT No. 81 restrict workplace monitoring to proportionate, purpose-limited data collection. URL-level personal browsing logs exceed this scope.

What is hardware attestation and why does it matter for device posture? Hardware attestation uses the TPM or Secure Enclave to cryptographically sign posture measurements. Unlike software self-reports, attested signals cannot be spoofed by malware with administrative privileges. It provides mathematical proof of device state.

How does device posture work for BYOD devices without MDM? Visibility is limited. Without MDM, the agent cannot access platform-specific management APIs. Organisations typically compensate with browser-based access through remote isolation, enforcing security at the session level rather than the device level.

What happens when a device posture verdict expires? Three common responses: graceful downgrade (restrict to low-sensitivity apps), soft block (prompt user to reconnect), or hard lockout (terminate session). The response should match the sensitivity of the resource being accessed.

Continuous device posture has moved from theoretical Zero Trust architecture principle to operational baseline. The platforms that handle it well distinguish verified signals from self-reports, combine multiple re-evaluation triggers, and respect EU privacy boundaries while maintaining security depth. For mid-market teams, the practical question is no longer whether to check device posture but how often, on which signals, and what happens when verdicts expire. Ready to see how continuous posture enforcement works in a single-console SASE platform? Book a demo and walk through the configuration with our team.