Skip to main content
Device trust lets an authentication policy take the device into account before granting access. Instead of only asking who is signing in, a policy can also ask what they are signing in from - and require that the device be known, healthy, and managed.
Device trust is one of the conditions an authentication policy can enforce. This page explains where device information comes from and the signals a policy can require.

​
Where device information comes from

Device health comes from the Iru Access app - the same app your people use to sign in - running on the device. When a device is first set up, Iru confirms it is a genuine, registered device; from then on, Iru Access reports the device’s health signals to Iru, where your authentication policies can use them. Iru Access reports these signals when a device is registered, each time the person signs in, and - on computers - on a regular background check-in.
Device signals are available only for devices that have Iru Access registered, so roll it out before requiring device trust. See Authenticators for how people set up Iru Access.
Iru recognizes laptops, desktops, phones, and tablets across macOS, Windows, and iOS.

​
What “trusted” can mean

A device-trust requirement is a combination of signals you choose. In plain terms, a policy can require that a device is:

Known and verified

The device is a genuine, recognized device rather than an unknown or spoofed one. Iru can confirm a device is attested before trusting its signals.

Managed

The device is enrolled in your organization’s device management. Iru determines this from the management evidence Iru Access reports - such as an enrollment profile on a Mac, MDM enrollment on a Windows PC, or managed-app configuration on a mobile device.

Encrypted

The device’s disk encryption is turned on, so data at rest is protected if the device is lost or stolen.

Healthy

The device meets the posture you require - for example, its protective features are on and it is running an acceptable operating-system version.
Device-trust signals are only available for devices that have the Iru Access agent registered. A policy that requires a healthy device will deny sign-in from devices Iru has no trusted signals for, so roll out Iru Access across your fleet before applying such a policy broadly.

​
How a policy uses device trust

A policy first considers which platform a device is on, then applies the requirements you set for that platform. The available signals differ by platform because each operating system exposes different protections.
On a Mac, Iru Access reports a rich set of signals: disk encryption (FileVault) on, the firewall on, System Integrity Protection on, a sealed (verified) system volume, and the operating-system version. Require the combination your policy needs.
On Windows, Iru Access reports a rich set too: disk encryption (BitLocker) on, the firewall on, Microsoft Defender antivirus protection on, Secure Boot on, memory integrity on, a hardware security chip (TPM) present, and the operating-system build. If your organization runs a third-party antivirus instead of Microsoft Defender, test that signal before enforcing it.
On a mobile device, Iru Access reports a smaller set: whether a passcode (screen lock) is set, and the operating-system version.
What some macOS signals mean: System Integrity Protection (SIP) stops even an administrator from modifying protected system files; a Signed System Volume (SSV) is a cryptographically sealed, tamper-evident system volume; and the single sign-on (SSO) extension is the macOS component that lets Iru broker app sign-ins on the device. Requiring these confirms the device’s core protections are intact.
For each signal, you decide whether it must be on, must be off, or should be ignored - and for versions, you choose the comparison and target. If a device does not meet a required signal, the sign-in fails and the unmet requirement is recorded as a violation. See Authentication policies for how decisions and violations work.
Only the platforms you enable in a policy are allowed to sign in to the applications it governs. If a platform is left disabled, devices on that platform are denied access.

​
Build a device-trust requirement

Roll out Iru Access

Make sure the devices you want to trust have Iru Access installed and registered - you can deploy it through your MDM, and people finish setup from an invitation. Without it, Iru has no signals for the device. See Authenticators.On managed devices, you can pre-provision the tenant’s MDM secret with the Iru Access command line - on macOS, for example:
iru-access manage --secret <secret> --domain <tenant>.iru.com

Open or create a policy

In Policies → Authentication policies, edit the policy that should enforce device trust.

Enable the platforms you allow

Turn on each device platform that should be permitted, and leave the rest off to deny them.

Set the required signals

For each platform, require the device health signals you need - such as encryption on, managed, and a minimum operating-system version.

Assign and verify

Assign the policy to the relevant applications and test sign-in from a managed device to confirm the outcome.

​
Where to go next

Authentication policies

Combine device trust with authenticator and risk requirements.

Authenticators

Iru Access is both how people sign in and how device signals are collected.

Risk and adaptive access

Add context-aware risk on top of device trust.

System architecture

See how device signals flow through Iru.