> ## 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. # Authenticators > The credentials users use to prove who they are in Iru: passkeys, the Iru Access app, and connected federated providers, and how you oversee them. An **authenticator** is something a user 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 users use. Users prove who they are to Iru in one of these ways: 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. 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](/en/identity/authentication/device-trust) for device-trust policies. 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](/en/identity/connections/connections-overview), 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. A passkey is bound to Iru, so there is no shared secret an attacker can trick someone into entering on a look-alike site. 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 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. 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**: | Status | What it means | | ------------- | ------------------------------------------------------------------------------------------------------ | | **Active** | The authenticator can be used to sign in. | | **Suspended** | The authenticator is kept on the user'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 users who use them, with administrator oversight for when something needs attention. 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](/en/identity/administration/end-user-experience). As an administrator, you can **review** the authenticators registered to a user, **suspend** one to block its use, or **remove** one (for example, when a device is lost or someone leaves. Administrators do not see the secret behind an authenticator; they manage which authenticators exist and whether they are active. For **Iru Endpoint** tenant administrator passkeys, see [Passkeys & Social Login](/en/iru/access/passkeys-and-social-login). If someone is locked out, see [Iru Account Recovery](/en/iru/access/iru-account-recovery). Make sure users can register more than one authenticator where possible, so losing a single device does not lock someone out. Removing or suspending a user'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, 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](/en/identity/authentication/authentication-policies) then layers **device trust** on top, deciding which devices may complete the sign-in and the health they must be in. ```mermaid theme={null} flowchart LR user["User signs in"] --> auth["Authenticator or
federated provider"] auth -->|"proves identity"| policy["Authentication policy
checks device trust"] policy -->|"conditions met"| app["Access to app"] ``` ## Where to go next Layer device-trust conditions on top of the authenticator every sign-in uses. See how users use their authenticators when they sign in. Let users sign in through Google, Microsoft, or a SAML or OIDC provider. How Iru protects the credentials behind authenticators and the sessions they create. What self-service looks like for users in your directory. Passkeys for Iru Endpoint tenant administrator sign-in End-user guide for passkeys, Iru Access, and backup devices Help team members regain access when they lose a passkey