Skip to main content
Iru Identity sits at the center of who can reach your applications, so it is built to be trustworthy by default. This page describes that posture as a set of plain guarantees - what Iru does for you. For the engineering behind them, follow the architecture deep-dives:

Platform architecture

Two-plane services, AWS hosting, and two-region data residency.

Multi-tenant isolation

Row-level security and append-only auditing in the database engine.

Authentication architecture

Phishing-resistant sign-in, signed requests, and rotating SSO keys.

​
What protects your tenant

Tenant isolation

Your directory, applications, policies, and settings live in your own tenant. One organization’s data is never visible to another, and access decisions in one tenant cannot affect another.

Verifiable single sign-on

The identity statements Iru sends to your applications are signed, so each app can confirm a sign-on genuinely came from Iru and was not altered along the way. An app will reject anything that does not carry Iru’s valid signature.

Phishing-resistant sign-in

Passkeys are the primary way people prove who they are. The secret that proves identity stays bound to Iru and the person’s device and is never handed to the apps they sign in to, which removes the credential a phishing page would try to steal.

Encrypted everywhere

Information is protected while it travels between your people, Iru, and your apps, and while it is stored.

Least-privilege administration

Administration is governed by roles, so each administrator has only the access their job requires. See Administrators & roles.

Recorded and reviewable

Significant events - sign-in decisions, changes to users and access, and administrative actions - are written to an activity log you can review and filter. See Activity log.

​
The trust boundary

Iru is the gatekeeper between the people who originate in your upstream systems and the applications they reach. Everything inside the boundary is isolated to your tenant; everything that crosses it does so under a guarantee above.
For a fuller picture of how identities, sign-in, and provisioning flow through Iru - including the role Iru plays for your apps - see System architecture.

​
Adaptive protection at sign-in

Strong credentials are only part of the story. Every sign-in to a connected app is evaluated against that app’s authentication policy before access is granted, and a policy can demand more when the situation warrants it.

Phishing-resistant by default

Every sign-in requires a phishing-resistant authenticator - a passkey or Iru Access - so there are no passwords to steal or replay.

Require trusted devices

Policies can require that a person is on a known, healthy device before access is granted.

Weigh risk

Policies can take the risk of a sign-in into account and ask for more assurance, or deny access, when something looks unusual.

Choose authenticators

Decide which authenticators your people may register and which a policy will accept.

​
Your data, under your control

Iru holds the directory and settings needed to run identity, sign-on, and provisioning for your organization - and no more than that.
Beyond the built-in profile fields, you choose which custom attributes to keep on your people, and you can mark them required or unique. Store what your policies, app mappings, and groups actually need, and leave out what they don’t. See Schema.
The profile and activity data Iru holds is used to run sign-in, evaluate policies, provision accounts, and produce your activity log - the functions that make Iru work for you.
An application only receives the profile details you map into its sign-on. You decide which attributes are shared with each app, so a given app sees only what it needs to identify the person. See Assigning access and Provisioning.
Iru Access makes this commitment to your people directly: on first launch it shows what it shares with their organization (sign-in, device type and security posture, coarse location from the public IP) and what it never touches (their personal content). Point your team to Your privacy.

​
Removing access quickly

When someone should no longer have access, Iru lets you act immediately, and the change is recorded.

Suspend a user

Suspending a user blocks their sign-in while preserving their record and history, so it is reversible if they return.

End active sessions

Existing sessions can be ended, so access is cut even where someone is already signed in.

Remove app accounts

Removing access can remove the matching account in apps that support provisioning, not just block future sign-on.
Suspending a user is the fastest way to cut off a person across everything at once. Reach for it the moment access should stop; you can always reinstate them later.

​
Compliance and data residency

Iru Identity is operated as part of the wider Iru platform’s security and compliance program. For your organization’s specific requirements:
  • Attestations and reports - request Iru’s current compliance reports and attestations through the Iru Trust Center or your Customer Success Manager.
  • Data residency and retention - confirm where your tenant’s data is stored and how long it is retained with your Customer Success Manager.

​
Where to go next

Credentials and sessions

How passkeys and sessions are protected, and how to end sessions and suspend people.

Authentication policies

Decide who can sign in to each app and what they must prove first.

Administrators & roles

Govern who can manage Iru, and with how much access.

Activity log

Review significant events and the outcomes of sign-in decisions.