> For the complete documentation index, see [llms.txt](https://docs.securepass.me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.securepass.me/documentation/setup-journey/the-setup-journey.md).

# The Setup journey

The Admin User Guide has a page for each thing you configure. This page is the thread between them — what order to do it in, and why that order.

The order is not a preference. It comes from a single fact: **granting access asks for everything at once.** Creating an access control means choosing a user, an application, a resource within it, a role, and the authentication required. All five have to exist before you can grant anything, and everything before that step exists to make those five available.

## The chain

```
1  Sources         →  where identities come from
2  Users           →  the people
3  Groups & roles  →  the structures access is granted to
4  Applications    →  the things to be accessed
5  MFA             →  the factors an application may demand
6  Policies        →  the baseline every session runs under
7  Access control  →  who reaches what  ← everything above feeds this
8  Approvals       →  the path for access that must be requested
9  Privileged access → the same idea for servers and databases
10 Governance      →  proving it is still correct
```

Steps 1 to 6 are preparation. Step 7 is the point of the exercise. Steps 8 to 10 keep it working after day one.

This assumes the platform is already deployed and its email and SMS gateways are configured — see *Email and SMS gateways*. Without a working gateway nothing can send a one-time password or a notification, so confirm that before starting here.

## Step by step, and what each needs

### 1. Connect the identity sources

Most organisations do not type their users in. They connect the directory that already holds them — Active Directory, OpenLDAP, Azure AD — under **Integrations**, and let SECUREpass read from it.

Connecting a source also settles the attribute mapping: which directory field becomes which SECUREpass field. Get that wrong and it propagates to every user the connection imports.

**Needs:** a working email gateway, if you want sync notifications. **Unblocks:** onboarding at scale.

### 2. Onboard the users

Import from the connected source, from an Excel or JSON file, or create individuals by hand.

At this point the users exist and can be signed in as — but they can reach nothing, because no access has been granted.

**Needs:** a connected source, for anything beyond manual creation. **Unblocks:** everything that names a user.

### 3. Set up groups, departments and roles

Access is granted to structures, not to people. A group assigned to an application once covers everyone in it, including whoever joins next week.

This is the step people skip, and it is the one that decides whether the deployment is maintainable. Grant to fifty individuals and every joiner, mover and leaver is fifty pieces of manual work; grant to a group and the group takes care of it.

**Needs:** users. **Unblocks:** access control that does not need constant maintenance, approval routing, review campaigns.

### 4. Register the applications

An application has to exist in SECUREpass before anyone can be given access to it. Registering it means choosing its protocol — SAML, OpenID or OAuth — configuring the exchange with the application itself, and defining the roles it recognises.

Those roles matter for step 8: the access control asks which role the user holds, and it can only offer roles defined here.

**Needs:** nothing strictly, but the roles you define should reflect the groups from step 4. **Unblocks:** access control, SSO.

### 5. Configure MFA

Decide which authentication methods exist in the tenant at all — that is **Authentication Modes**, and it sets the menu. Then each application chooses from that menu which factors it demands.

The order is one-directional: a method must be enabled tenant-wide before any application can require it, and enabling it tenant-wide does not by itself make any application use it.

**Needs:** a working SMS or email gateway, for OTP methods. **Unblocks:** the *Auth Types* column on every access control.

### 6. Set the security policies

Password rules, session timeouts, lockout thresholds, IP restrictions, and the dormant-account thresholds that warn and then deactivate unused accounts.

These are the baseline every session runs under, whoever the user is. Set them before people start signing in, because tightening a password policy afterwards invalidates passwords already set.

Adaptive authentication and risk profiles sit on top: policies set the fixed requirement, adaptive raises or lowers it by context.

**Needs:** nothing. **Unblocks:** a defensible baseline.

### 7. Grant the access

Now the access control can be created, because everything it asks for exists.

| The form asks for                    | Which came from    |
| ------------------------------------ | ------------------ |
| User or group                        | Steps 2 and 3      |
| Application                          | Step 4             |
| Resource within the application      | Step 4             |
| Role                                 | Step 4             |
| Access type — permanent or temporary | Your decision here |

Grant it, and the user sees the application in their portal and can sign into it through SECUREpass.

**This is the first point at which anything actually works for a user.** Everything before it was preparation.

### 8. Set up approvals

Not all access should be granted up front. Anything sensitive, temporary or exceptional is better requested, justified and approved — and recorded.

Approval workflows are configured for access requests, group requests, authentication type changes and profile updates, each with its own approver chain.

**Needs:** users, groups and applications to route between. **Unblocks:** access that grows on demand rather than by ticket.

### 9. Set up privileged access

Servers, databases, cloud resources and network devices follow the same shape as applications, with a vault in the middle: onboard the target, vault its credential, map users to it, and record the sessions.

The mapping step is the same access control screen, on the **Systems** tab. Which is why PAM comes after step 7 — it reuses the same mechanism.

**Needs:** everything up to step 7. **Unblocks:** privileged access without anyone holding a server password.

### 10. Govern it

Everything above grants access. This step proves it is still the right access.

**Access reviews** ask a named person to confirm or revoke what someone holds, on a schedule. **Reports** are the evidence — who signed in, with what, what failed, what access exists.

Neither adds capability. Both are what turns a working deployment into a defensible one, and both read what steps 7 to 9 created.

**Needs:** granted access to review. **Unblocks:** the audit conversation.

## What happens then, for a user

The administrator's chain ends where the user's begins.

```
Signs in  →  proves identity with MFA  →  sees their portal
                                             │
                    ┌────────────────────────┴──────────────────────┐
                    │                                              │
          Opens an application                          Needs something more
          (SSO — no second password)                     │
                                                Requests it → approver decides
                                                → granted automatically
```

And over time the same identity moves through three lifecycle events:

**Joiner** — the account is created and birthright access granted automatically from department and role.

**Mover** — role or department changes, access is adjusted, and the new access can be sent for re-certification. This is the one organisations get wrong: the new access gets added and the old access does not get removed.

**Leaver** — access is revoked immediately, and the account is disabled and archived rather than deleted, so the audit trail survives the person.

## Where the detail lives

| Step | Page                                                          |
| ---- | ------------------------------------------------------------- |
| 1    | Integrations and connectors                                   |
| 2    | Connect sources and onboard users                             |
| 3    | Groups, departments and roles                                 |
| 4    | Register and configure applications                           |
| 5    | Configure MFA                                                 |
| 6    | Security policies · Adaptive authentication and risk profiles |
| 7    | Access policies and approvals → access control                |
| 8    | Access policies and approvals → Approvals                     |
| 9    | Privileged access (PAM) setup                                 |
| 10   | Governance and reporting                                      |

Before step 1: *Email and SMS gateways*.

## If you only remember one thing

Work outward from the access control. It names a **user**, an **application**, a **resource**, a **role** and an **authentication requirement** — so those five must exist first, and every earlier step is there to produce one of them.