> ## 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.

# Security and privacy

> Iru Identity's security and privacy posture, expressed as plain guarantees about how your tenant, your sign-ins, and your data are protected.

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:

<CardGroup cols={3}>
  <Card title="Platform architecture" icon="server" href="/en/identity/security/platform-architecture">
    Two-plane services, AWS hosting, and two-region data residency.
  </Card>

  <Card title="Multi-tenant isolation" icon="database" href="/en/identity/security/multi-tenant-isolation">
    Row-level security and append-only auditing in the database engine.
  </Card>

  <Card title="Authentication architecture" icon="signature" href="/en/identity/security/authentication-architecture">
    Phishing-resistant sign-in, signed requests, and rotating SSO keys.
  </Card>
</CardGroup>

## What protects your tenant

<CardGroup cols={2}>
  <Card title="Tenant isolation" icon="box">
    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.
  </Card>

  <Card title="Verifiable single sign-on" icon="signature">
    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.
  </Card>

  <Card title="Phishing-resistant sign-in" icon="fingerprint">
    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.
  </Card>

  <Card title="Encrypted everywhere" icon="lock">
    Information is protected while it travels between your people, Iru, and your
    apps, and while it is stored.
  </Card>

  <Card title="Least-privilege administration" icon="user-shield">
    Administration is governed by roles, so each administrator has only the
    access their job requires. See
    [Administrators & roles](/en/identity/administration/administrators-and-roles).
  </Card>

  <Card title="Recorded and reviewable" icon="clipboard-list">
    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](/en/identity/administration/activity-log).
  </Card>
</CardGroup>

## 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.

```mermaid theme={null}
flowchart LR
  subgraph outside["Outside the boundary"]
    people["Your people"]
    idp["Connected providers<br/>and HR systems"]
    apps["Your applications"]
  end
  subgraph iru["Your Iru tenant"]
    direction TB
    dir["Directory"]
    policy["Authentication policies"]
    log["Activity log"]
  end

  people -->|"phishing-resistant sign-in"| iru
  idp -->|"federated sign-in and synced people"| iru
  iru -->|"verifiable, signed single sign-on"| apps
  iru -.->|"encrypted in transit and at rest"| iru
```

<Info>
  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](/en/identity/getting-started/system-architecture).
</Info>

## 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.

<CardGroup cols={2}>
  <Card title="Phishing-resistant by default" icon="key" href="/en/identity/authentication/authenticators">
    Every sign-in requires a phishing-resistant authenticator - a passkey or Iru
    Access - so there are no passwords to steal or replay.
  </Card>

  <Card title="Require trusted devices" icon="laptop-medical" href="/en/identity/authentication/device-trust">
    Policies can require that a person is on a known, healthy device before
    access is granted.
  </Card>

  <Card title="Weigh risk" icon="gauge-high" href="/en/identity/authentication/risk-based-access">
    Policies can take the risk of a sign-in into account and ask for more
    assurance, or deny access, when something looks unusual.
  </Card>

  <Card title="Choose authenticators" icon="fingerprint" href="/en/identity/authentication/authenticators">
    Decide which authenticators your people may register and which a policy will
    accept.
  </Card>
</CardGroup>

## 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.

<AccordionGroup>
  <Accordion title="You decide what you store" icon="table-list">
    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](/en/identity/directory/schema).
  </Accordion>

  <Accordion title="Data is used to operate your identity service" icon="circle-info">
    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.
  </Accordion>

  <Accordion title="You control what each app receives" icon="arrow-right-arrow-left">
    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](/en/identity/applications/assigning-access) and
    [Provisioning](/en/identity/applications/provisioning).
  </Accordion>
</AccordionGroup>

<Info>
  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](/en/identity/end-user/your-privacy).
</Info>

## Removing access quickly

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

<CardGroup cols={3}>
  <Card title="Suspend a user" icon="user-lock" href="/en/identity/directory/users">
    Suspending a user blocks their sign-in while preserving their record and
    history, so it is reversible if they return.
  </Card>

  <Card title="End active sessions" icon="right-from-bracket" href="/en/identity/security/credentials-and-sessions">
    Existing sessions can be ended, so access is cut even where someone is
    already signed in.
  </Card>

  <Card title="Remove app accounts" icon="trash-can" href="/en/identity/applications/provisioning">
    Removing access can remove the matching account in apps that support
    provisioning, not just block future sign-on.
  </Card>
</CardGroup>

<Tip>
  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.
</Tip>

## 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](https://trust.iru.com) 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

<CardGroup cols={2}>
  <Card title="Credentials and sessions" icon="key" href="/en/identity/security/credentials-and-sessions">
    How passkeys and sessions are protected, and how to end sessions and suspend
    people.
  </Card>

  <Card title="Authentication policies" icon="shield-halved" href="/en/identity/authentication/authentication-policies">
    Decide who can sign in to each app and what they must prove first.
  </Card>

  <Card title="Administrators & roles" icon="user-shield" href="/en/identity/administration/administrators-and-roles">
    Govern who can manage Iru, and with how much access.
  </Card>

  <Card title="Activity log" icon="clipboard-list" href="/en/identity/administration/activity-log">
    Review significant events and the outcomes of sign-in decisions.
  </Card>
</CardGroup>