Configuring the Atmos Agent Device Posture

The Atmos Agent Device Posture conditions access based on findings from the Atmos Agent, leveraging OSQuery to collect the data on the endpoint. To create an Atmos Agent device posture, make sure you have the Atmos Agent Installed.

📘
Important
If you are deploying device posture using the domain joined check option, see Key Considerations for using Device Posture and Domain Joined Check.

Click here to learn more about installing the Atmos Agent on a Windows computer
Click here to learn more about installing the Atmos Agent on a Macintosh computer
Click here to learn more about installing the Atmos Agent on an iOS device

The process of configuring the Atmos Agent Device Posture includes two steps:

Creating a Device Posture Object
Adding a Policy Rule

Creating a Device Posture Object

In the Management Console, go to Policy -> Device Trust -> New Device Trust.
Select Atmos Agent as your new device posture method.

New Atmos Agent Device Posture

Enter a name and a description (optional).

Platforms

Check the platform or platforms you wish to enable, and select their version.

Conditions

📘
Note
Conditions are available based on the selected platform(s). If a condition was selected for one platform, and there is a change in platform (another was added or replaced), the condition may be unavailable.

Click Add Condition to open a list of existing conditions. Note: the conditions will vary according to your selected platform(s).
Start typing to find a condition.
For each condition specify whether it is enabled or disabled.
Delete a condition by clicking the delete icon

The following table lists the conditions:

Condition Name	Description	Platform
Client Certificate	The {user.Axis Client} checks whether a valid certificate is available in the device’s registry. To pass this posture validation check, the device must have a Root CA certificate. The admin should upload the CA's Public certificate (not private or privately signed). Certificate file types can be: .PEM, .CRT, or .CER. Windows Only – Select the Enable TPM Check option to enforce hardware-backed certificate security on Windows devices. When enabled, the Atmos Agent validates that the private key for the client certificate is secured inside the device's Trusted Platform Module (TPM 2.0) via the Microsoft Platform Crypto Provider. If a certificate is software-stored, or if provider validation fails, the posture check fails. Non-Windows platforms (macOS) automatically bypass the TPM check and continue evaluating standard certificate criteria. For more information on TPM hardware security, refer to Microsoft's [Trusted Platform Module Technology Overview](https://learn.microsoft.com/en-us/windows/security/hardware-security/tpm/trusted-platform-module-overview).	Windows, MacOs, both
Crowdstrike	The {user.Axis Client} checks if Crowdstrike’s Falcon Sensor is installed on the device, and verifies that it is running and reporting. The {user.Axis Client} verifies with Crowdstrike API that it is running and reporting to the right Crowdstrike tenant. Note: This condition is only available if there is an integration between Crowdstrike and Axis Security. Click [here](doc:about-9) to learn more.	Windows, MacOs, both
Domain-Joined	The {user.Axis Client} checks whether a Windows device is domain-joined to an Active Directory domain. To pass this posture validation check, the device's server domain must be joined to the Active Directory domain that was configured in the Device Posture.	Windows
Firewall	The {user.Axis Client} inspects the firewall status for all three firewall profiles: public, private, and domain. To pass the posture validation check, at least one must be active.	Windows, MacOs, both
File path	The {user.Axis Client} searches for a file path that can be found on the users' systems. To pass the posture validation check the device must have that path. For example, you can enter: C:\Program Files\Git\bin\git.exe	Windows, MacOs, both
Full Disk Encryption	The {user.Axis Client} checks whether the device has full disk encryption enabled or disabled. To pass this posture validation check, full disk encryption must be enabled. Note: BitLocker encryption is only supported.	Windows, MacOs, both
Registry Key Path	The {user.Axis Client} checks against the registry key Path or the Value. To pass this posture validation check, the device must have the specified registry key. For the registry key path, ensure that the path begins with HKEY. For example, you can enter: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters After the path to Parameters, specify the registry entry name; for example, Domain located in the Name column and then the domain name itself, which is located in the Data column. In this example the path would be HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Domain then the registry key value would be theirdomainname.com ![Alt text](https://files.readme.io/eba0622-registry_key.png)	Windows
Windows Patches	The {user.Axis Client} checks the windows patches installed. To pass this device posture check the relevant patches must be installed. Note: The admin must explicitly mention every patch that should be checked.	Windows
Processes	The {user.Axis Client} checks whether a process is running on the computer. For example: explorer.exe	Windows, macOS, both
Password Protection	The {user.Axis Client} checks whether the mobile device has password protection.	iOS, Android
Screen Lock	The {user.Axis Client} checks whether the mobile device has any form of screen locks such as password, facial recognition, fingerprint and more.	iOS, Android
MDM Ownership Variable	The {user.Axis Client} device posture variable provides the capability to check for specific information on a mobile device to determine whether the device is managed by an organization’s MDM. Click [here](mdm-ownership-variable) to learn more.	iOS, Android
Search Domains	The {user.Axis Client} checks whether a search domain is configured on the machine at the network interface level.	Windows, macOS, both

Adding a Policy Rule

A Policy is a collection of rules which provide granular access to your apps depending on a range of parameters. For example, access can be defined based on the destination application groups of the requester. In this use case, the admin can use the device posture created above as a rule that will block or allow access to the application.

Click here to earn more about policy rules.

📘
Note
Under Device trust, select the device trust profile created in the previous section.

Click Submit.
Click Apply Changes in the top menu bar.

Managing Upgrades for Legacy Agents

For endpoints running older agent versions, the HPE Networking SSE agent versions prior to v3.107 do not capture or report providerName metadata in their certificate posture payload.

When Enable TPM Check is turned on in a policy rule:

Fail-Closed Behavior – The Policy Server fails closed when certificate provider metadata is absent, marking the device posture as Unhealthy.
Management UI State – In the Device Posture page, affected devices will display the error Provider Name Missing.
Access Disruption – Users on older agent versions will fail device posture checks and will be immediately blocked from accessing protected resources that require this policy.

Transition Workaround

To maintain a smooth transition while the Agent is upgraded to v3.107 or later, configure the following prioritized policy rules:

High-Priority Policy (TPM Check Enabled).
- Device Posture Condition – Client Certificate with Enable TPM Check set to True (checked), and evaluated first.
- Outcome – Endpoints running Agent versions v3.107 and newer, that present a certificate backed by the Microsoft Platform Crypto Provider, match this rule and gain secure access. Older agents fail this rule and automatically fall through to the next rule.
Low-Priority Policy (TPM Check Disabled).
- Device Posture Condition – Client Certificate with Enable TPM Check set to False, and evaluated second.
- Outcome – Older agents fall through from the high-priority rule and match this fallback rule, allowing them to remain connected without service interruption while their upgrade is pending.

Monitoring and Policy Clean-Up

Monitor Upgrades – Go to Settings → Enrolled Agents to monitor agent version distribution across your fleet and track devices still running pre-3.107 versions.
Enforce Strict TPM Compliance – Once all endpoints have been upgraded to version 3.107 or higher, disable or delete the low-priority policy rule. All devices will then be evaluated strictly against the high-priority rule.