Platform / Device trust
Let the laptop’s state count in the decision.
Connect your MDM, define what a healthy device means, and use that definition in any app’s sign-in rule.
- Managed by your MDMYes
- Disk encryptionOn
- OS version
macOS 26.1 - Failing MDM policies2 failing
ResultAccess denied
Example. Rules decide what each signal means for each app.
Signals from the MDM you run
IdRa syncs device records through vendor APIs and matches them to people. There’s no agent of ours to install.
- Jamf, Microsoft Intune, Kandji and Fleet
- Managed-host view with owner and compliance, using Fleet
- Refetch, lock, unlock and wipe from the console, using Fleet (lock, unlock and wipe need Fleet Premium)
Device assurance as a policy
Build assurance policies from the attributes your MDM reports, and require one in an authentication rule.
- Managed, disk encryption, OS version
- No failing MDM policies (Fleet)
- Optional client certificate signal on self-managed deployments with a proxy that terminates mTLS (not on idra.team)
Compliance changes reach the rest of security
When a Fleet host stops complying, IdRa logs it, records a risk signal, and tells Shared Signals receivers.
- CAEP device-compliance-change
- A medium-risk signal your entity risk rules can act on
Standards it speaks
- CAEP
- mTLS signal
Not here yet
- Screen-lock checks: no MDM integration reports them yet
- A native device agent, Desktop MFA and Platform SSO
- Vendor APIs are tested against fixtures and fakes, not yet against live Jamf, Intune, Kandji or Fleet
We’d rather you read this now than find it in a pilot. See the full comparison.
Create your organization.
Pick an address and confirm your email, then sign in as its first admin. A setup wizard takes you through the rest.