Understanding NetBird Posture Checks

Updated August 18, 2026

Posture Checks is a security feature that enhances network protection by implementing automated assessments of a device's security status before granting network access, thus ensuring that only compliant devices can access your network resources.

In this regard, NetBird posture checks verify various aspects of a connecting device, offering granular control over network access. These checks include verifying the NetBird client version, allowing you to restrict access to peers with specific versions of the client software. Additionally, you can implement geographical restrictions based on country or region, giving you control over where connections can originate from.

The feature also allows for network-level restrictions by enabling you to allow or block specific peer network ranges. Furthermore, you can set constraints based on the operating system of the connecting device, ensuring that only approved OS versions can gain access. For an even more detailed level of control, Posture Checks can examine the running processes on a peer device, allowing or denying access based on the presence of specific applications or services.

By using these diverse checking capabilities, NetBird empowers you to create a robust and finely-tuned security posture for your network, significantly reducing the risk of unauthorized access and potential security breaches.

Setting Up Posture Checks

Setting up posture checks in NetBird is straightforward. Follow the guide and examples below:

Log in to your NetBird dashboard and navigate to Access Control > Posture Checks in the left menu. Click Create Posture Check or edit an existing one.

A pop-up window will open with two tabs: Checks and Name & Description.

From here, you can manage access with posture checks based on several aspects:

NetBird Client Version

Restrict access to peers with specific NetBird client versions, thus ensuring that all devices connecting to the network use up-to-date, secure client software.

Country and Region

Limit network access based on geographical location, helping comply with data regulations or restrict access from high-risk areas. Note that you have two tabs available for this: Allow (green) and Block (red), making it easy to set up your preferred access rules.

Peer Network Range

This posture check lets you precisely control network access by specifying which IP ranges can connect to your network. You can create policies allowing only connections from approved locations, such as office networks or trusted remote work setups. Additionally, you can enhance security by blocking high-risk IP ranges working in tandem with geo-based posture checks. This granular control helps create a more secure network environment by limiting access to known, trusted sources while preventing connections from potentially risky or unauthorized IP addresses.

The check evaluates a peer against two sources of address information:

• The peer's local network interfaces — the IP addresses configured on the device's NICs (e.g. the office LAN 192.168.1.0/24 the device is plugged into).
• The peer's public connection IP — the source IP the NetBird management server observes when the peer connects (i.e. the egress / NAT'd IP).

A configured range matches when it fully contains one of these, so the same check covers both private subnets and public CIDRs. Note that a local interface contributes its whole subnet (e.g. a /24), not a single address, so a configured range must be no more specific than that subnet to match it. A /32 rule will not match a NIC sitting in a /24, though it does match the connection IP, which is compared as a single host. Both IPv4 and IPv6 are supported. A few examples:

• Block a single office public IPv4: 203.0.113.10/32
• Allow a public ISP/office block: 1.0.0.0/24 or 3.0.0.0/23
• Block an entire private network: 192.168.1.0/24
• Block a single IPv6 host: 2001:db8::1/128
• Block an IPv6 prefix: 2001:db8::/48

Operating System

Restrict access based on the connecting device's OS, ensuring only approved and potentially more secure operating systems can connect.

The check evaluates the actual OS version for Android, macOS, and iOS, while for Linux and Windows, it assesses the kernel version.

Below are some examples of OS versions for each operating system:

• Android 14 Upside Down Cake: 14, 14.3
• macOS 13 Ventura: 13, 13.6.4
• macOS 14 Sonoma: 14, 14.3.1
• iOS 16 / iPadOS 16: 16, 16.7.5
• Linux kernel: 6, 6.7.5
• Windows 10, version 22H2: 10.0.19045
• Windows 11, version 23H2: 10.0.22631
• Windows Server 2022, Version 21H2: 10.0.20348

Process

Limit network access based on specific applications or services running on the connecting device. By verifying specific applications or processes, you ensure that only devices running essential security software, such as antivirus, firewalls, or endpoint protection agents, can connect to your network, reducing the risk of malware entering your network through unprotected devices. It also aids in maintaining compliance with regulatory requirements by enforcing consistent security measures across all devices.

Furthermore, this process-based posture check allows you to create specific policies for different user groups or network segments based on their unique security needs. Working in conjunction with other posture checks in NetBird, this setting offers a comprehensive and user-friendly approach to network security.

Name & Description

After enabling the desired posture check, go to the Name & Description tab. Here, enter a descriptive name for your newly created posture check and save it.

You'll notice a gray dot to the left of the posture check name, indicating it's inactive. To activate the posture check, you need to link it to an access control policy.

Applying Posture Checks to Access Control Policies

To apply a posture check:

• Create or edit an access control policy.
• Find the Posture Checks tab within the policy settings.
• Choose Browse Checks to select an existing check or New Posture Check to create one.

Note that you can add multiple posture checks to a single policy as needed for comprehensive security.

After adding the posture check, it will appear in the POSTURE CHECKS column. For easy management, you can click on it to edit the access control policy, allowing you to add or remove posture checks as needed.

If you revisit the Posture Checks dashboard, you'll notice a green dot next to your recently configured posture check. This color shift indicates that the posture check is now active and integrated into your network security framework, actively contributing to your system's protection.

Following these steps, you can effectively implement and manage NetBird's Posture Checks, significantly enhancing your network's security posture.

When Posture Checks Are Evaluated

NetBird evaluates posture checks when a peer connects or logs in. Checks are also re-evaluated during an active session whenever a peer reports changed system metadata. The management server replays each check against the peer's previous and current metadata, and when a check's verdict flips, it recomputes the network map and distributes the update to the affected peers.

When you add or change a posture check on a policy, the updated configuration is distributed to connected peers immediately. A peer that is already connected is evaluated against the new check on its next connection. There is no periodic redistribution interval; distribution is driven by configuration changes and peer metadata changes, not a timer. For more on how changes reach peers, see How Policy Changes Are Distributed.

Known Limitations

Peer Network Range Check on Android

The Android client does not report the device's local network interfaces to the management server, so ranges intended to match a peer's local NIC IPs (e.g. an office LAN like 192.168.1.0/24) cannot be evaluated on that platform.

Ranges that target the public connection IP still work on Android, because the management server observes that source IP itself and does not depend on anything the client reports. So public CIDRs (e.g. 203.0.113.10/32, 1.0.0.0/24) and public-IP-based deny/allow rules behave the same on Android as on desktop.

Impact:

A local NIC range never matches on Android, so the outcome depends on the check's action:

• An Allow check built on local NIC ranges is never satisfied by an Android peer. Those peers fail the check, and routes gated by that policy become unavailable to them.
• A Deny check built on local NIC ranges is never triggered by an Android peer, so those peers always pass it. The block silently does not apply on those devices.

Checks built on the public connection IP are unaffected and behave on Android exactly as they do on desktop.

Recommendation:

If your deployment includes Android clients and you need to gate on local network membership, consider one of the following:

• Create separate policies for Android clients that do not include local-NIC-based Peer Network Range posture checks
• Use alternative posture checks (such as Geo Location) that are supported on every platform
• Use Peer Network Range checks based on the public connection IP, which work on every platform
• Apply local-NIC-based Peer Network Range posture checks only to policies targeting platforms that report them (Windows, macOS, Linux, and iOS 0.69.0+)

Get started with NetBird

• Make sure to star us on GitHub
• Follow us on X
• Join our Slack Channel
• NetBird latest release on GitHub