Skip to main content
An authenticator is something a person uses to prove who they are when they sign in. Iru is built around strong, phishing-resistant authenticators, so the secret needed to sign in never has to be typed or shared with the apps people use. People prove who they are to Iru in one of these ways:

Passkey

The primary authenticator. A passkey lets someone sign in with the fingerprint, face, or screen lock they already use on their device - 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 person’s computer or mobile device. People 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 person 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 person.
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 your people 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

People 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 person’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 people to live with.

Status: active or suspended

Every authenticator has a status:
StatusWhat it means
ActiveThe authenticator can be used to sign in.
SuspendedThe authenticator is kept on the person’s account but cannot be used to sign in until it is reactivated.
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 people who use them, with administrator oversight for when something needs attention.
People 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 people get set up. See End-user experience.
Make sure people can register more than one authenticator where possible, so losing a single device does not lock someone out. Removing or suspending a person’s only active authenticator will prevent them from signing in until they enroll a new one.

How authenticators and policies fit together

Every sign-in is proven before access is granted - 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 people use their authenticators when they sign in.

Federated Authentication

Let people 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 the people in your directory.