> ## Documentation Index > Fetch the complete documentation index at: https://docs.iru.com/llms.txt > Use this file to discover all available pages before exploring further. # Device trust > Require sign-in from known, healthy, managed Mac computers, iPhone devices, iPad devices, and PCs using signals reported by the Iru Access agent. **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](/en/identity/authentication/authentication-policies) 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. ```mermaid theme={null} flowchart LR agent["Iru Access
on the device"] -->|"device and health signals"| iru["Iru Identity"] iru -->|"available to"| policy["Authentication policies"] ``` Device signals are available only for devices that have **Iru Access** registered, so roll it out before requiring device trust. See [Authenticators](/en/identity/authentication/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: 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. 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. The device's disk encryption is turned on, so data at rest is protected if the device is lost or stolen. 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](/en/identity/authentication/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 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](/en/identity/authentication/authenticators). On managed devices, you can pre-provision the tenant's MDM secret with the Iru Access command line - on macOS, for example: ```bash theme={null} iru-access manage --secret --domain .iru.com ``` In **Policies → Authentication policies**, edit the policy that should enforce device trust. Turn on each device platform that should be permitted, and leave the rest off to deny them. For each platform, require the device health signals you need - such as encryption on, managed, and a minimum operating-system version. Assign the policy to the relevant applications and test sign-in from a managed device to confirm the outcome. ## Where to go next Combine device trust with authenticator and risk requirements. Iru Access is both how people sign in and how device signals are collected. Add context-aware risk on top of device trust. See how device signals flow through Iru.