Device posture checks verify the security state of every endpoint before granting access to applications and data. For organisations subject to NIS2, they provide documented evidence that access decisions consider device health, not just user identity. With Belgium’s CyberFundamentals verification deadline set for April 2026, configuring posture checks correctly is no longer optional for IT managers preparing for their first audit.
This guide covers what device posture checks are, which signals to evaluate, how to configure them step by step, and how they map to specific NIS2 and CyberFundamentals controls. The focus is practical: you will finish with a working configuration and the evidence trail your auditor expects.
How to configure device posture checks for NIS2
- Define a posture baseline with three mandatory signals: OS currency, disk encryption, and device registration status.
- Connect your identity provider and sync user groups with role-based access policies.
- Create posture profiles in your ZTNA platform, mapping each signal to a pass or fail condition.
- Apply posture profiles to application access policies so that non-compliant devices are blocked or given restricted access.
- Enable logging for every posture evaluation, including the signals checked, the result, and the access decision.
- Export posture compliance reports and link them to your CyberFundamentals evidence pack.
Why device posture matters more than identity alone
Verifying a username and password, even with multi-factor authentication, answers only one question: is this the right person? It says nothing about whether that person’s laptop is running an outdated operating system, lacks disk encryption, or has disabled its firewall.
According to the Verizon Data Breach Investigations Report, vulnerability exploitation accounted for roughly 20 percent of confirmed breaches in recent analysis, with a notable year-over-year increase. Separately, industry research suggests that more than half of ransomware incidents in 2025 and 2026 trace back to unpatched or poorly maintained systems. These are not abstract risks. An employee with valid credentials connecting from a compromised device gives an attacker a verified, trusted entry point into your environment.
Device posture checks close this gap. They evaluate the endpoint’s security state at the moment of connection and continuously during the session. If the device fails the check, access is denied or restricted to a lower-trust scope. This is the difference between a Zero Trust model that actually works and one that only looks good on paper. Our Zero Trust architecture guide covers how posture checks fit within the broader architecture.
What NIS2 and CyberFundamentals expect from access control
Belgium’s NIS2 law has been active since April 2024. Essential entities must obtain at least a Basic or Important CyberFundamentals (CyFun) verification by 18 April 2026. Important entities can undergo the same process voluntarily to demonstrate conformity. The CyFun 2025 edition aligns with NIST CSF 2.0 and organises controls across six functions: Govern, Identify, Protect, Detect, Respond, and Recover.
Device posture checks map directly to several CyFun controls under the Protect function.
| CyFun control area | What the auditor checks | How device posture helps |
|---|---|---|
| Access control | Least-privilege enforcement, identity-based access decisions | Posture adds device context to every access decision, not just identity |
| Asset management | Inventory of devices accessing the network | Posture checks require device registration, creating a live inventory |
| Data security | Encryption of data at rest and in transit | Disk encryption is a standard posture signal |
| Protective technology | Endpoint security controls are active and current | OS version, endpoint protection status, and firewall state are verifiable signals |
| Configuration management | Devices meet a defined security baseline | Posture profiles encode your baseline and enforce it automatically |
The key point for auditors is demonstrability. A posture check that runs automatically, logs every result, and blocks non-compliant devices provides stronger evidence than a policy document that describes what should happen. Our NIS2 compliance checklist covers the full set of controls you need to prepare.
Which posture signals to check
Not every posture signal carries equal weight. Start with the signals that are easy to verify, hard to bypass, and directly relevant to your risk profile. You can expand later.
Mandatory baseline (start here)
Operating system version and patch level. This is the single most impactful signal. An endpoint running an OS version that no longer receives security updates is an open target. Define a minimum supported version for each platform (Windows, macOS, Linux, iOS, Android) and update the threshold quarterly.
Disk encryption. Full-disk encryption (BitLocker on Windows, FileVault on macOS) protects data if a device is lost or stolen. For NIS2, this demonstrates that data-at-rest protection extends to the endpoint layer.
Device registration or management status. Is the device enrolled in your endpoint management system or registered in your ZTNA platform? This separates known devices from unknown ones and gives you a foundation for everything else.
Recommended additions (phase two)
Endpoint protection status. Check whether the device has active endpoint protection with current definitions. This does not require a specific product; it requires proof that the device is defended.
Screen lock and inactivity timeout. A device left unlocked in a coffee shop is a device that anyone can use. Require a screen lock with a maximum inactivity timeout.
Firewall status. The local firewall should be enabled. This is a lightweight check that closes a common gap.
Secure boot. On supported hardware, secure boot prevents rootkits and boot-level malware from loading before the operating system starts.
Advanced signals (phase three)
Certificate-based device identity. Issue device certificates through your endpoint management system. This binds a specific device to a specific identity, making it far harder to spoof device registration.
Jailbreak or root detection. For mobile devices, check whether the OS has been modified in ways that bypass built-in security controls.
Browser version. Outdated browsers are a common attack vector. If your applications are accessed via web browser, browser currency matters.
Step-by-step configuration
This section walks through the configuration process. The steps are platform-agnostic but align with how SASE platforms with integrated ZTNA handle posture.
Step 1: Inventory your devices
Before you write a single posture rule, list what connects to your environment. Separate devices into three categories.
Managed endpoints are company-owned laptops and desktops enrolled in your endpoint management system. You have full control over their configuration.
BYOD and personal devices are employee-owned devices used for work. You can check their posture but may not be able to enforce remediation directly.
Agentless devices are printers, IoT sensors, meeting room systems, and industrial equipment. These cannot run a posture agent. They need a different approach, specifically inline isolation through hardware like NIAC appliances that restrict their communication to approved flows. Our guide on microsegmentation covers how to handle these devices within a Zero Trust model.
Step 2: Define your posture profiles
Create at least two profiles.
Standard profile (for managed devices accessing business applications): OS version is current and supported. Disk encryption is enabled. Device is registered. Endpoint protection is active. Firewall is enabled.
Restricted profile (for BYOD or devices that fail the standard check): Browser-based access only. Limited application scope. No access to sensitive data stores. TLS inspection may apply.
For administrative access to network infrastructure or sensitive systems, create a third elevated profile that adds secure boot verification, certificate-based device identity, and a maximum session duration.
Step 3: Connect your identity provider
Device posture checks are most effective when combined with identity context. Connect your identity provider (Microsoft Entra ID, Okta, Google Workspace, or another SAML/OIDC-compatible IdP) to your ZTNA platform. Sync user groups so that access policies can combine who the user is, what group they belong to, and what state their device is in. Our identity provider integration guide covers the technical steps.
Step 4: Build access policies that reference posture
This is where posture becomes enforcement, not just visibility. For each application, define an access policy that includes three conditions: user identity (group membership), authentication strength (MFA method), and device posture (which profile the device must satisfy).
A practical example for a finance application:
| Condition | Requirement |
|---|---|
| User group | Finance team |
| Authentication | Phishing-resistant MFA |
| Device posture | Standard profile (managed, encrypted, current OS, endpoint protection active) |
| Access scope | Finance application and required APIs only |
| Session logging | Full audit trail |
If the device fails the posture check, access is denied. The user receives a remediation message explaining what needs to change: update the OS, enable encryption, or enrol the device.
Step 5: Deploy in monitor mode first
Run your posture policies in monitor mode for one to two weeks. This means the policy evaluates posture and logs the result, but does not block access. Review the logs to identify:
- Devices that would fail and need remediation before enforcement
- Policies that are too strict and would block legitimate work
- Gaps in your device inventory (devices you didn’t know about)
Adjust your profiles based on what you learn. Then switch to enforcement mode, starting with low-risk applications and expanding to business-critical systems over two to four weeks. Our guide on common ZTNA mistakes covers why phased rollout prevents project derailment.
Step 6: Configure logging and compliance reporting
Every posture evaluation should generate a log entry containing: the timestamp, the user identity, the device identifier, each posture signal checked and its result, the overall pass or fail outcome, and the access decision (granted, denied, or restricted).
Stream these logs to your SIEM or central logging platform. Create two standard reports.
Weekly posture compliance summary. Shows the percentage of sessions that passed posture checks, the top reasons for failure, and trends over time.
Monthly access governance report. Maps posture compliance to CyFun controls, showing auditors that your technical controls are active, measured, and improving.
These reports become part of your CyberFundamentals evidence pack. When your conformity assessment body (CAB) reviews your Protect controls, you can demonstrate that device posture is enforced automatically, logged centrally, and reviewed regularly.
Handling the devices that cannot run an agent
Printers, IoT sensors, meeting room displays, and industrial equipment present a different challenge. They cannot run a posture agent, which means traditional posture checks do not apply. Leaving them on the same network as managed endpoints creates exactly the lateral movement paths that NIS2 expects you to close.
The answer is inline isolation. Place agentless devices behind a network isolation appliance that restricts their communication to explicitly defined flows. A printer can reach the print server. A sensor can reach its data collector. Nothing else. This is not “OT security” in the strict sense; it is a secure bridge between IT and OT that brings agentless assets under Zero Trust controls.
For environments with industrial equipment, purpose-built industrial network controllers handle the specific protocols and uptime requirements of production lines without disrupting operations. The hospital ransomware analysis shows what happens when agentless medical devices are left on flat networks.
Posture checks in practice: two Belgian scenarios
Scenario 1: A manufacturing company with 120 employees across two sites. The IT team manages 95 Windows laptops and 15 macOS devices. The factory floor has 30 PLCs, HMIs, and sensors that cannot run agents. The company is classified as an important entity under NIS2.
Configuration: Managed devices must pass the standard posture profile (current Windows 11 or macOS 14+, BitLocker or FileVault enabled, endpoint protection active). Factory equipment sits behind NIAC appliances with flows restricted to the MES system and update servers. Admin access to network infrastructure requires the elevated profile with certificate-based device identity and session time limits. All posture logs stream to a central SIEM. The IT manager exports a monthly compliance report for the board, satisfying CyFun governance requirements.
Scenario 2: An MSP managing 12 mid-market customers from a single console. Each customer has between 30 and 200 users, a mix of managed and personal devices, and varying compliance requirements.
Configuration: The MSP creates baseline posture profiles as templates in the multi-tenant console. Each customer gets the standard and restricted profiles, with the option to add customer-specific signals (for example, a healthcare customer requires secure boot). Policy templates reference the customer’s identity provider and application inventory. Posture compliance dashboards are available per tenant, and evidence exports are generated ahead of each customer’s audit cycle. The MSP can demonstrate uniform policy enforcement across its portfolio without managing separate tools for each customer.
Common mistakes with device posture
Setting posture requirements too high on day one. If 40 percent of your devices fail the check, you will face a wave of support tickets and pressure to disable the policy. Start with three signals, prove the process works, then raise the bar.
Checking posture only at connection time. A device that was compliant when the session started may become non-compliant during the session (for example, if a user disables the firewall). Continuous evaluation catches this.
Ignoring personal devices. If your employees use personal phones to approve transactions or access email, those devices are part of your attack surface. Apply the restricted profile with browser-based access and scoped permissions.
Forgetting to document the baseline. The posture profile itself is documentation, but you also need a written policy that explains why each signal was chosen, who approved it, and when it was last reviewed. Auditors look for governance, not just technology.
Treating agentless devices as exceptions. Every device you leave outside posture enforcement or isolation is a gap an auditor will find and an attacker will exploit.
How Jimber makes device posture simple
Jimber’s SASE platform treats device posture as a built-in enforcement layer, not an optional add-on. When a user connects through Zero Trust Network Access, the platform checks their identity, evaluates device posture against the configured profile, and grants access to specific applications only if both conditions pass.
Posture signals are collected through the Jimber agent on managed devices. For personal devices, browser-based access with scoped permissions provides a controlled alternative. For agentless equipment, NIAC hardware provides inline isolation that restricts communication to approved flows, closing the gap that traditional approaches leave open.
All posture evaluations, access decisions, and policy changes are logged in the single management console. Reports can be exported for CyFun evidence packs, streamed to a SIEM, or reviewed in real time. For MSPs, the multi-tenant console applies posture templates across customer environments with consistent enforcement and transparent reporting.
The result is a posture check workflow that runs automatically, generates the evidence NIS2 demands, and stays manageable for a small IT team.
Ready to configure device posture checks that satisfy your next audit? Book a demo and see how posture enforcement works in Jimber’s single cloud-managed console.
FAQ
Do device posture checks slow down the user experience?
No. Posture evaluation happens in milliseconds during the connection handshake. Users see a seamless login. If their device fails a check, they receive a clear message explaining what to fix, which is faster than troubleshooting a blocked VPN connection.
Can I enforce different posture requirements per application?
Yes. Sensitive applications like finance systems or admin consoles should require stricter posture (encryption, secure boot, certificate-based identity). Lower-risk applications can use a lighter baseline. This prevents over-blocking while maintaining strong controls where they matter.
What happens if a device becomes non-compliant during a session?
With continuous posture evaluation, the platform re-checks device state at defined intervals. If a device drops below the required baseline, the session can be restricted or terminated automatically, and the event is logged for audit purposes.
How do device posture checks relate to CyberFundamentals in Belgium?
CyFun controls under the Protect function require access control, asset management, and protective technology measures. Device posture checks provide automated enforcement and documented evidence for all three areas. The logs and compliance reports map directly to what conformity assessment bodies expect during verification.
What about contractors and third-party users?
Apply the restricted posture profile with browser-based access, time-limited sessions, and approval workflows. Require step-up authentication for sensitive resources. Log all access for audit purposes. This satisfies NIS2’s supply chain security expectations.
Do I need EDR to implement device posture checks?
EDR deepens endpoint visibility and enables automated isolation during incidents, but you can implement effective posture checks without it. Start with OS version, encryption, and device registration. Plan for EDR integration as a future enhancement that will add endpoint telemetry to your posture evaluation.
