Passkey
The primary authenticator. A passkey lets someone sign in with the
fingerprint, face, or screen lock they already use on their device, with no
password to remember or reuse. Passkeys are phishing-resistant: they only
work with Iru, so they cannot be captured and replayed on a fake sign-in
page.
Iru Access
The Iru Access app, installed on a user’s computer or mobile device. Users
register it from an invitation and then use it to confirm sign-in; like a
passkey, it is tied to the device and unlocked with the device’s biometric or
screen lock. Iru Access also reports
device health for device-trust
policies.
Federated provider
Instead of an Iru authenticator, a user can sign in through an identity
provider you have connected (Google, Microsoft, or any SAML or OIDC provider).
The external provider verifies them and Iru trusts the result. This is set up
under Federated Authentication,
not enrolled per user.
Passkeys and Iru Access are phishing-resistant authenticators Iru manages
directly, and are the recommended way to sign in. When someone signs in through
a federated provider instead, the strength of that sign-in depends on the
controls that provider enforces.
Why passkeys
Passkeys are the recommended way for users to sign in to Iru.Nothing to phish
A passkey is bound to Iru, so there is no shared secret an attacker can trick
someone into entering on a look-alike site.
Nothing to remember
Users unlock their passkey with the biometric or screen lock already on
their device, so there is no password to create, rotate, or forget.
The secret never leaves the device
The part of the passkey needed to sign in stays on the user’s device and is
never sent to Iru or to the apps they open.
Built for everyday sign-in
Signing in with a passkey is a single quick gesture, which makes a strong
requirement easy for users to live with.
Status: active or suspended
Every authenticator has a status:
Suspending an authenticator blocks its use without removing it, which is useful
while you investigate something. Removing an authenticator deletes it entirely.
Self-service and admin oversight
Authenticators are owned by the users who use them, with administrator oversight for when something needs attention.- What end users do
- What administrators do
Users manage their own authenticators from their account in Iru. They can
add a passkey, see the authenticators registered to them, and remove one they
no longer use. Because passkeys live on personal devices, self-service
enrollment is the normal way users get set up. See
End-user experience.
How authenticators and policies fit together
Every sign-in is proven before access is granted, whether with an Iru authenticator (passkey or Iru Access) or through a connected federated provider. A strong authenticator is the built-in default; it is not something you switch on in a policy. An authentication policy then layers device trust on top, deciding which devices may complete the sign-in and the health they must be in.Where to go next
Authentication policies
Layer device-trust conditions on top of the authenticator every sign-in uses.
The sign-in experience
See how users use their authenticators when they sign in.
Federated Authentication
Let users sign in through Google, Microsoft, or a SAML or OIDC provider.
Credentials and sessions
How Iru protects the credentials behind authenticators and the sessions they
create.
End-user experience
What self-service looks like for users in your directory.
Passkeys & Social Login
Passkeys for Iru Endpoint tenant administrator sign-in
Manage authenticators
End-user guide for passkeys, Iru Access, and backup devices
Iru Account Recovery
Help team members regain access when they lose a passkey