Endpoint posture freshness: polling, events, and access decisions

A compliant result always has an age

A device-compliance result is based on evidence observed at a particular time. Disk-encryption protection can become suspended, an endpoint-agent heartbeat can become stale, management enrollment can be removed, device risk can increase, or patch evidence can age after the last successful evaluation.

That does not make scheduled device management ineffective. It means every posture decision has a freshness boundary. Security teams should know which component observed each control, when it observed it, how the result reached policy, and when an access system acted on the change.

Near-real-time posture verification reduces that delay for supported signals. It cannot prove the device's literal current state: devices go offline, agents fail, events arrive late, and some controls expose only periodic evidence. The defensible goal is the latest trusted evidence with explicit freshness and a measured path to enforcement.

Measure the complete exposure window

A single check-in interval does not describe the full control. The useful measurement is the time from a material endpoint change to the verified access or remediation outcome.

Total exposure window =
  observation latency
+ reporting latency
+ policy-evaluation latency
+ enforcement latency

• Observation latency. How long the endpoint, management service, security agent, or attestation system takes to notice the change.
• Reporting latency. How long the evidence takes to reach the service that normalizes or evaluates posture.
• Policy-evaluation latency. How long the compliance or authorization engine takes to calculate a new result.
• Enforcement latency. How long applications, gateways, session services, or endpoint controls take to apply and verify the response.

What the Intune maintenance cadence does—and does not mean

Microsoft documents an estimated Intune policy and profile maintenance check-in of about eight hours across supported platforms, with newly enrolled devices checking more frequently. Microsoft also documents a maintenance-sync restriction of one sync per 6.5-hour window. These estimates are useful when a control depends on ordinary MDM refresh.

The maintenance cadence is not the only possible evaluation path. Users and administrators can request synchronization, targeted policy changes can prompt device check-in, application-protection controls can evaluate when an application opens or resumes, and integrations such as Microsoft Defender for Endpoint can feed device-risk signals into Intune compliance and Conditional Access.

The accurate question is therefore not whether a platform is polling or real time. Ask which source evaluates each control, which faster paths apply to that signal and platform, and what latency remains when those paths are unavailable.

Posture sources have different timing and trust properties

Use a hybrid verification model

• Event-driven transitions. Emit supported state changes when they occur, such as device-risk increases, management removal, or an endpoint control entering an error state.
• Liveness heartbeats. Require sources that should report continuously to prove they are still running. Convert an overdue heartbeat into stale or unknown posture rather than leaving the last healthy state valid indefinitely.
• Periodic reconciliation. Compare full observed state with the declared baseline so missed, suppressed, or unsupported events do not create permanent blind spots.
• On-demand verification. For sensitive access, request or require evidence with a freshness threshold appropriate to the resource and platform where the integration supports it.
• Bounded cached state. Cache evaluated posture only with source, observation time, expiry, and policy version. Do not reduce posture to an unqualified compliant boolean.

Fast evidence is not automatically trustworthy

• Bind telemetry to an authenticated device and tenant identity. Prevent one endpoint or tenant from updating another subject's posture.
• Protect events from tampering and replay with authenticated transport, signatures or equivalent integrity controls, stable identifiers, and duplicate detection.
• Use trustworthy observation times and define acceptable clock skew. Arrival time alone does not establish when the device state changed.
• Use hardware- or platform-backed attestation where it materially strengthens a control, but document exactly what the evidence proves and how long it remains acceptable.
• Correlate independent MDM, endpoint-security, identity, and platform evidence where appropriate. A compromised agent may suppress or falsify its own status.
• Record source precedence and conflict policy. A fast healthy event should not silently override newer or stronger evidence of compromise.

Model stale, missing, unknown, and conflicting states

A device should not remain compliant forever because it stopped reporting while healthy. Set a maximum acceptable age per signal: MDM check-in, endpoint-agent heartbeat, encryption evidence, risk score, patch inventory, attestation, certificate state, and any other input.

Define separate outcomes for stale, missing, unknown, error, conflicting, noncompliant, and restored evidence. Depending on resource sensitivity, the response may be denial, a limited session, step-up authentication, a grace period, user notification, remediation, or analyst review.

• Offline devices. An offline endpoint cannot deliver a new event. Expire trust according to the last evidence and deny or limit new sensitive access when freshness requirements are no longer met.
• Failed sources. Distinguish a healthy device from an unavailable management or security service. Monitor source health and avoid treating a telemetry outage as proof of compliance.
• Recovery. Require evidence that the affected control is restored and stable before returning full access. Protect recovery from stale or out-of-order events.

From posture evidence to access enforcement

A new posture result does not automatically affect an active application session. The decision system must correlate the device, user, tenant, resources, and sessions; evaluate policy; then propagate and verify the response at each enforcement point.

The OpenID Shared Signals Framework and Continuous Access Evaluation Profile can carry supported state changes between cooperating systems. CAEP is descriptive: a device-compliance event becomes a policy input, while the receiver decides whether to deny, revoke, challenge, constrain, or observe.

• For the downstream event and session path, see Continuous access evaluation for device posture changes.

Worked example: endpoint-agent heartbeat becomes stale

At 09:00, a managed laptop reports healthy encryption, current endpoint protection, and a successful agent heartbeat. At 09:07, the agent stops reporting. The system does not claim that malware killed it; loss of telemetry has several possible causes.

At the defined heartbeat threshold, posture changes from healthy to stale. The event is authenticated, correlated to the device and tenant, deduplicated, and evaluated against resource policy. Low-risk applications retain limited access while source-code and administrative systems require fresh evidence. The help desk receives the source status and recovery steps.

When the agent reports again, the system does not restore access solely because one heartbeat arrived. It reconciles the relevant controls, verifies that the new evidence is later than the blocking state, records the restoration decision, and then returns access according to policy.

Metrics that make freshness testable

• Measure observation-to-report, report-to-decision, and decision-to-enforcement latency separately by platform, signal, network condition, and resource.
• Track the percentage of devices with posture evidence inside each required freshness threshold.
• Track missing events, duplicate events, out-of-order events, retry backlog, dead-letter volume, and reconciliation findings.
• Measure false blocks, unsafe grants, recovery time, exception volume, and recurrence after remediation.
• Test normal, offline, degraded-network, source-outage, clock-skew, agent-failure, and conflicting-evidence scenarios.

Questions to ask vendors

• Which posture signals are event-driven, periodic, heartbeat-based, or evaluated on demand for each supported platform?
• What are the measured observation-to-enforcement latencies under normal and degraded conditions?
• How does policy receive the evidence source, observation time, freshness, confidence, and version instead of only a compliant flag?
• What happens when a device is offline or when MDM, endpoint security, attestation, or the streaming service is unavailable?
• How are device identity, tenant binding, event integrity, replay protection, ordering, deduplication, and key rotation handled?
• How does periodic reconciliation find events that were missed, suppressed, or never emitted?
• Which responses affect only future sign-ins, and which can change active sessions across applications and background channels?
• What evidence proves that a restored device actually converged before access returned?

How this maps to a Gideon evaluation

Evaluate Gideon Endpoint Management by selecting representative controls and measuring the complete evidence path. Confirm which source observes each control, how freshness and missing data are represented, when policy changes, what action follows, and how the resulting endpoint or access state is verified. Treat any latency target as a measured acceptance criterion for the tested platform and signal, not as an unsupported universal guarantee.

Related reading

• Use the Zero-touch endpoint management for security teams for the full endpoint lifecycle.
• Compare management and agent responsibilities in MDM plus native agent architecture.
• Define control thresholds with the Endpoint posture policy starter pack.
• Explore Gideon Endpoint Management for product capabilities and evaluation paths.

Primary references

• Microsoft documents estimated maintenance check-in timing and synchronization behavior in Questions with policies and profiles in Microsoft Intune.
• Microsoft documents compliance refresh, manual synchronization, and grace-period behavior in Create device compliance policies in Microsoft Intune.
• Microsoft documents device-risk integration with compliance and Conditional Access in Integrate Microsoft Defender for Endpoint with Intune for Device Compliance.
• Microsoft explains detection, compliance status, grace periods, and downstream actions in Configure actions for noncompliant devices.

How to use this resource

Choose one high-impact posture signal and map its observation, reporting, evaluation, enforcement, and recovery path. Set a freshness threshold and expected outcome, test normal and degraded conditions, and retain the measurements as acceptance evidence before expanding the control.