How credentials are protected
People prove who they are with authenticators, and a passkey is the primary one. Passkeys are designed to resist phishing, which is the most common way credentials are stolen.The secret never leaves the person
A passkey keeps the secret that proves identity bound to the person’s device.
Signing in proves they hold it without ever transmitting the secret itself,
so there is nothing reusable for an attacker to capture.
Bound to Iru
A passkey only works when the person is genuinely signing in to Iru. A
look-alike phishing page cannot trigger it, because the passkey is tied to
the real Iru sign-in and will not respond to an impostor.
Protected at rest
What Iru keeps to verify an authenticator is protected while it is
stored, and is never enough on its own to impersonate the person.
Managed by the right people
People manage their own authenticators in self-service. If someone loses
access to theirs, an administrator can reset them so the person can register
a new one. See Users.
Which authenticators your people may register, and which a policy will accept
for a given app, is up to you. See
Authenticators and
Authentication policies.
What an application receives - and what it never sees
When a person reaches an app through Iru, the app learns who they are without ever learning how they proved it. This separation is what keeps a single stolen credential from spreading across your apps.The app receives
A signed statement that confirms who the person is, plus the profile details
you chose to map into that app’s sign-on. Because the statement is signed,
the app can verify it really came from Iru and was not tampered with.
The app never receives
The person’s passkey or any other authenticator secret. Apps never hold the
means to prove the person’s identity, so a breach of one app cannot be
replayed against Iru or your other apps.
You decide which profile attributes are shared with each application, so an
app sees only the details it needs to identify the person. See
Assigning access.
How sessions are protected
After a successful sign-in, Iru establishes a session so the person isn’t asked to prove themselves again on every click. Sessions are protected so they can’t be borrowed or stretched indefinitely.Sessions expire
Sessions expire
A session does not last forever: it ends after a period of inactivity and
again at a maximum age, after which the person signs in and the governing
policy is evaluated afresh. The session length presented to a connected app is
configurable - per SAML app and
per application role.
Each app sign-in is checked against policy
Each app sign-in is checked against policy
Signing in to a connected app runs through that app’s authentication policy,
so a sensitive app can require a trusted device even when the person is
already signed in to Iru. (A passkey or Iru Access is required for every
sign-in either way.) See
Authentication policies
and Device trust.
Sessions can be ended on demand
Sessions can be ended on demand
A person’s active sessions can be ended, which forces them to sign in again
before they can continue. This is how you cut off access even when someone is
already signed in.
Ending access immediately
When access needs to stop, you don’t have to wait for a session to expire. Pick the action that matches the situation; each one is recorded in the activity log.| Action | What it does | Reversible? |
|---|---|---|
| End sessions | Ends the person’s active sessions so they must sign in again. | Yes - they can sign in again if still active. |
| Suspend the user | Blocks all sign-in while preserving the record and history. Existing access is cut and new sign-ins are refused. | Yes - reinstating restores their previous status. |
| Remove access to an app | Revokes an assignment; for apps that support provisioning, the account there can be removed too. | Yes - reassign to restore. |
| Remove the user | Deletes the directory record entirely. | No - this cannot be undone. |
Ending a session inside a connected app depends on the app. Ending sessions
and suspending a user stop further sign-ins through Iru right away. Whether a
person’s existing session inside a connected app also ends is up to that app
and its protocol:
- Apps that check with Iru on each access stop letting the person in at the next check.
- For apps provisioned with SCIM,
suspending or unassigning the person sends a deactivate (the account’s
activeflag set tofalse) or a delete to the app. Whether that immediately ends the app’s active sessions is determined by how the app handles that signal. - Some apps keep an existing session until it expires unless they support session revocation or single logout.
How a compromised credential is contained
The pieces above work together so that one stolen credential can’t cascade:- Passkeys give attackers nothing reusable to phish in the first place.
- Apps never receive the means to prove identity, so a breached app can’t be replayed against Iru.
- If something does go wrong, suspending the user and ending their sessions cuts access immediately - and every step is recorded for review.
Where to go next
Security and privacy
The full security and privacy posture, expressed as plain guarantees.
Authenticators
Choose which authenticators your people register and use.
The sign-in experience
What people see when they sign in through Iru.
Users
Suspend, reinstate, reset authenticators, and manage the people in your
directory.