Devices and MDM (Fleet)

IdRa knows two kinds of devices:

• Browsers: every browser a person signs in from, listed on Directory → Devices and on each person's page. A browser is managed when an MDM record vouches for it, or when it presents a client certificate.
• Managed hosts: computers synced from an MDM (Fleet), with owner, platform, OS version, serial, disk encryption, failing policies and last seen.

Device checks only matter once you use them in a policy: create a device assurance policy, then add Device assurance policy is any of … to an authentication policy rule.

Device assurance policiesCopy Anchor Link

Security → Device Assurance → Policies. Each policy targets one Platform and can require:

• Minimum OS version (the MDM-reported version when known; browser-reported versions are low assurance, macOS browsers always report 10.15.7);
• Device is managed (a match on the user's email and platform counts only if the integration has Accept user + platform matches (weaker) on; it's off for new integrations, and IdRa has no serial numbers for browsers yet, so without it this needs a client certificate);
• Disk encryption is on (reported by an MDM only) and Firewall is on (reported by Jamf only: on other MDMs this never passes). Screen lock can't be required, because no MDM integration reports it; a policy that already requires it never passes until you save it again, which clears the requirement;
• No failing MDM policies (Fleet only);
• MDM check-in within (hours).

MDM integrationsCopy Anchor Link

Security → Device Assurance → MDM integrations → Add: Jamf Pro, Microsoft Intune, Kandji or Fleet. IdRa reads device records from the MDM's API hourly, and on demand with the sync button (↻) on the integration's row, and matches them to people's browsers by serial, else by person and platform.

FleetCopy Anchor Link

Fleet is optional; IdRa works the same without it.

1. Connect: enter the Fleet server URL (public https; private IPs and plain http are refused) and an API-only user's token (fleetctl user create --api-only). Observer is enough to sync; lock, unlock, wipe and refetch need Maintainer or Admin. The token is encrypted at rest. Test connection shows the Fleet version and the token's role.
2. Sync: hourly and on demand (↻), every host goes into Directory → Devices → Managed hosts. The owner is matched by Fleet's device mapping or IdP email. Unmatched hosts are listed as Unassigned; hosts removed from Fleet disappear on the next full sync.
3. Webhook: the add dialog shows a webhook URL once, <BASE_URL>/api/hooks/fleet/<secret> (New webhook URL replaces it). Point Fleet's failing-policies, host-status and activities webhooks at it for near-real-time updates. IdRa only reads host ids from the payload and re-reads those hosts from Fleet. On large fleets set the failing-policies webhook's host_batch_size (e.g. 100): bodies are capped at 1 MB.

What a Fleet host does in IdRa:

• Policies: a matched host vouches for its owner's browsers on the same platform (for Device is managed, see the setting above). A host with only the fleetd agent still reports posture but doesn't count as managed.
• Risk: a host is compliant when no Fleet policy fails and its disk isn't reported unencrypted. Losing compliance logs user.device.compliance_change, records a medium mdm:device_noncompliant risk signal (usable in entity risk rules) and notifies Shared Signals receivers.
• Actions: on Managed hosts (and the person's page): refetch, lock, unlock and wipe call Fleet, with a confirmation for lock and wipe. Each is logged as device.fleet.<action>. Lock and wipe need Fleet Premium with MDM (or scripts on Linux). A Mac's unlock PIN is shown once and never logged.
• Disconnect (delete the integration): its hosts leave IdRa and the browsers they vouched for stop counting as managed. Nothing changes in Fleet.

Client certificates (mTLS)Copy Anchor Link

If your MDM pushes a client certificate to devices, your TLS proxy can verify it and tell IdRa. Turn on Client certificate (mTLS) under Security → Device Assurance → Client certificates; a request then counts as managed when the proxy sends X-Client-Cert-Verified: SUCCESS and an X-Client-Cert-Serial. This only works with TRUST_PROXY set to cloudflare or forwarded; railway ignores these headers, because Railway's edge doesn't strip them.

tls {
  client_auth {
    mode verify_if_given
    trust_pool file /etc/caddy/mdm-ca.pem
  }
}
request_header -X-Client-Cert-Verified
request_header -X-Client-Cert-Serial
@cert expression {http.request.tls.client.serial} != ""
request_header @cert X-Client-Cert-Verified SUCCESS
request_header @cert X-Client-Cert-Serial {http.request.tls.client.serial}
reverse_proxy idra:3000

LimitsCopy Anchor Link

• Matching is by serial, else by person + platform: one compliant host vouches for all of that person's browsers on the platform.
• Native device agents (Windows/macOS desktop MFA, desktop password sync) aren't part of IdRa.