Privileged access
Standing administrative access is the first thing an auditor asks about and the thing an estate accumulates without anyone deciding to. This page describes what RapidValue puts in its place, and — as deliberately — what it does not.
PAM-lite, and we use the word
This is PAM-lite. There is no session recording, no credential checkout or rotation for target systems, and no privileged-session proxy: the product never stands between an administrator and the system they are administering.
What it governs is entitlements and how long they last. That difference decides where the product sits in an architecture rather than being a footnote to it. If you need an administrator's keystrokes recorded, or a checked-out credential nobody knows, this belongs alongside a dedicated privileged-access product, not instead of one. Read the rest against that boundary.
Three shapes of temporary privilege
Elevation from an approved request
The common case is planned privileged work: a migration, a release, an investigation. The request carries a duration, not an end date, and on approval it becomes a scheduled session rather than a grant. The approval and the elevation are therefore the same decision: no second hand has to remember to switch the access on, and none to switch it off.
The request is bounded when it is submitted, not when it is approved. A duration outside the configured window is refused outright (shipped defaults: 15 minutes to 8 hours), and the entitlement's risk level must sit in the tenant's allowed set — by default only high and critical, so this cannot quietly become the way ordinary access is requested. A request still unapproved past the wait timeout (3 hours by default) is raised as an exception, not approved into a window that has gone stale.
In configuration and exports this validity mode is called SAPA (short-term access for privileged access); the interface calls it scheduled elevation.
Direct elevation
For "give Jan four hours of domain admin for tonight's maintenance" there is a one-click path ("Elevate now"), with no approval chain, a bounded duration (5 minutes to 12 hours) and a mandatory justification. Two kinds of caller may use it: administrators, managers and helpdesk, for anyone; and a person who has been pre-authorised, for themselves only.
A pre-authorisation is a standing approval an administrator grants ahead of time to a person or a group for one privileged entitlement, with a per-session maximum that can never exceed the tenant's scheduled-elevation maximum, and an optional expiry. The row is the approval: an eligible engineer elevates without a platform role and without waiting, and the session records which pre-authorisation covered it and who authored it. A lapsed one, or a request longer than its maximum, covers nothing and is refused with the reason; the way forward is a planned request through its approval chain. The elevation form shows before the click whether the person has an administrative account for the target to land on.
Both paths start from one request flow: what, when and for how long, and why. A summary beside it says before submitting whether the elevation starts now (because a pre-authorisation covers it, which the server checks) or goes to approval, and the search for privileged access shows a verdict per hit. A privileged right that nobody owns cannot be requested: the form says so before anything is written, says what to do (ask an administrator to assign an owner), and keeps the send closed. An administrator who elevates directly also sees the approval chain a request for that right would take. Anyone who may request access can open the JIT page and ask for an elevation. A person who has no administrative account on the target system yet asks through the approval chain, and the form says that the administrative account is set up with the grant; asking on behalf of someone else stays closed in that case. The JIT page has Overview (active now, coming up and recently ended), Effectiveness, Exceptions (still-standing access first) and Settings. The security team and auditors read Overview, Effectiveness and Exceptions; resolving an exception, the settings and eligibility stay with an administrator. Break glass has its own review queue, with the unexplained activations first and no Review button on your own activation, and each profile says whether it would still grant anything.
Two refusals are worth knowing, because both refuse rather than warn: an elevation requires the person to already have an account on the target system, and a privileged entitlement requires a privileged account. A privileged right does not fall back onto whatever account happens to exist. Elevating the same account into the same entitlement a second time works: the lapsed grant is reused.
Break-glass
Break-glass exists for when waiting for anything is the wrong answer. Activation is instant and there is no approval step — that is the point at three in the morning. Four things make it different from simply granting somebody admin:
- Eligibility was decided in daylight. A profile names a set of entitlements and the people or roles who may activate it, configured in advance. In the emergency, nobody decides who is trusted.
- The window is finite and the platform closes it, not the holder.
- The activation is recorded at critical severity on the immutable audit trail, and the reason is mandatory — but filed after, against a justify-within deadline: nobody writes a justification while production is down. The activation shows as outstanding until it arrives (the default deadline is 60 minutes, set per profile).
- Use triggers a review. Emergency access raises an event that spawns a post-use review of what was actually held, looked at by someone who did not activate it. The reviewer sees it in the Inbox as emergency access that was used, not as an ordinary new-grant review; the security team or an administrator records the outcome as approved or a violation, also once the activation has ended or expired. The activator cannot record that outcome on their own activation, also not as an administrator; the attempt is refused and recorded.
An activation says what it actually granted. Each entitlement in the profile gets its own outcome (granted, pending, or failed with the reason, such as no active account on that system or a write held for approval), and the responder sees "X of N granted" with the reason for the rest. An activation that did not grant everything is recorded as a separate critical audit event and reaches the security webhook as incomplete, instead of reading as a success.
Only the activator, an administrator or the security team may justify or revoke an activation — a check that had to be added, because "any authenticated user in the tenant" was briefly enough.
A profile whose entitlements have all been removed grants nothing, so it is not offered to a responder and activating it is refused; administrators and auditors still see it so it can be replaced.
A profile also says how it delivers access: self-elevation on the responder's own account (the default, and what every existing profile was set to), a shared account or an ephemeral account. The Coverage view compares that with the allow-list of delivery modes an entitlement carries and flags a mode mismatch when a profile grants an entitlement whose allow-list does not contain the profile's mode. An entitlement without an allow-list expects nothing and shows as "not set" instead. The access mode is the one field of an existing profile an administrator can change, so a mismatch is fixed without re-creating the profile; the change is audited. The mode is declarative today: activation still grants through the responder's own account, whatever the mode says.
The clock is the product
A window is closed by a sweep running once a minute for every tenant holding a scheduled or active session — not by the holder handing the access back, and not by a nightly batch. The same sweep opens windows at their start time, and is idempotent, so it also runs safely whenever someone reads the session list.
A revoke that fails is not allowed to look like success. A session whose deactivation failed, or one still active past its end time, surfaces as an exception with its remedies attached (retry, force-revoke) and counts against the tenant's on-time-revoke percentage, reported beside mean session length and peak concurrent elevations. A failed revoke is privilege left standing; the target is zero, and it is measured rather than assumed.
The security team sees the same thing on its Home: an Elevated right now card lists the active sessions the reader may see, and a session still active past its end time is marked in red and becomes the bar at the top of Home, linking to JIT access.
One elevation, end to end
Marieke de Vries, a database engineer, needs owner rights on the Aurora Payroll production database for a schema migration on Thursday evening.
- Request. She asks for
PROD-DB Ownerfor 180 minutes from 19:00, with a justification. The entitlement is classified critical, so it is eligible, and 180 minutes sits inside the tenant's bounds. Had she asked for two days, the request would have been refused here, not approved and trimmed later. - Approval. Sanne Bakker, who owns the payroll platform, approves. Nothing is
granted: the item becomes scheduled session
JIT-9f3c2a1bwith its start and end already fixed. Her approval is the elevation decision. - 19:00 — the window opens. The sweep activates the session and materialises a time-boxed grant against Marieke's administrative account on Aurora Payroll, not her ordinary one.
- 22:00 — the window closes. The sweep expires the session and takes the access away; neither Marieke nor Sanne has to remember. Had she finished early, she or an administrator could have revoked by hand — and had that revoke failed, the session would surface as an exception rather than lapse into standing privilege.
- Afterwards. The session's evidence view returns one trail: when it was requested, who approved it and when, when it was granted, when and how it was revoked, and whether its duration was inside policy — over the immutable audit events for the same session. The set exports as an evidence pack answering the question this exists for: show me that privileged access is never standing.
Evidence that outlives the session
A session points at an identity, an account and an entitlement by internal identifier, and those are not stable across a rebuild: wipe and re-sync a connector and the same people and groups return under new ones. A nulled foreign key, a dangling reference, a cascading delete — three mechanisms, one outcome: a historical session that can no longer say who held what. That is not evidence, however immutable the audit events beside it, because they carry the same dead identifiers.
So every write path stamps a snapshot onto the session as it is created: per reference, a stable key that survives a re-sync of the same connector, plus the display name as it then was. Reads resolve in this order:
- Live first. If the object still exists, the current name wins — history never shows a stale label where a current one is available.
- Self-heal. If the identifier is dead but the stable key finds a live object under a new one, the reference is repaired in place, and the repair is audited. The row stops being broken rather than being papered over.
- Snapshot, marked. If nothing resolves, the snapshot name is served with an explicit "(deleted)" marker: "Lucas Aerts — Domain Admins (deleted)", never an em-dash and never a truncated identifier that looks like data.
Break-glass activations, access requests and approval decisions get the same treatment through one shared resolver rather than four. Snapshots hold a name and a stable key and no email address — enough to attribute, not a second copy of the directory. They persist through an erasure request on the same retention ground as the audit trail, which is a trade-off worth stating rather than discovering.
Plan gating: there is none
Privileged access is available to every tenant. There is no feature or plan gate on direct elevation, break-glass activation or break-glass profile creation, and a plan change cannot strand a live elevation. Reading, listing, revoking, exception handling and evidence are likewise always available.
Who staffs the protected roles
The protected roles (administrator, security team, break-glass) come from membership of curated system groups with manual membership: "IGA Administrators", "IGA Security" and "IGA Break-glass". An administrator manages every one of those groups, and may bind a protected role to a group or remove it, without a super-admin. Anyone else, the helpdesk included, can only hand out roles they hold themselves, and a business administrator can never bind a protected role. The last administrator cannot be removed, and every change is audited, at warning level when a protected role is involved.
Losing a protected role takes effect at once. When a person is removed from such a group, or the role is unbound from it, the person's existing sessions are revoked, so a session started while they were still an administrator does not keep the role until it expires.
MFA for the administrator roles
Separate from elevation, a tenant can decide what second-factor proof the people who hold the protected roles (administrator, security team, break-glass) must sign in with. A session records when it was authenticated with a second factor: after the local TOTP check, or when the identity provider's token or assertion says so. A missing claim is never read as proof.
The policy has three modes, set per tenant by an administrator in Environment & connections, Security:
- Off is the default for every tenant, including new ones.
- Report only: each session that holds a protected role without proof is written to the audit trail as "would have been blocked", once per login per hour, and nobody is held back.
- Required (enforce): such a session loses the protected roles for as long as it lacks the proof. It keeps its other roles (at least end user), so the person can still reach the profile menu and turn on two-step verification, then sign in again. A banner in the shell names the paused roles and the way back. The same applies to people acting through an OAuth or MCP grant whose sign-in had no second factor. Each such session is audited as blocked, once per login per hour.
Enforcement is opt-in; nothing switches it on for a tenant. Two guards keep a tenant from locking itself out. An administrator cannot save Required unless their own session carries the proof (the card does not offer it, and the server refuses with a conflict). And RapidValue support can always bring a tenant back to Off or Report only, with a written reason, behind a fresh operator sign-in, recorded in the tenant's audit trail. Support can never switch Required on. The settings view shows whether your own session has the proof and how many logins were reported over 30 days, so you can judge whether enforcing would lock anyone out.
A fresh second factor for the moments that matter
A sign-in that proved a second factor hours ago says little about who is at the keyboard now. Two actions therefore ask for a second factor from the last 15 minutes, whoever performs them and whatever roles they hold:
- privileged elevation from the "Elevate now" path, when the entitlement is privileged or is membership of a group that confers a protected role;
- approving an access request that provisions into Active Directory or LDAP, whichever route the approval arrives by (request, task, bulk or mailed link). Rejecting is never asked.
This follows the same tenant policy as the roles. With the policy off, nothing is asked and nothing is recorded. In report only the action goes through and the audit trail notes "would have been refused". In Required the action is refused with a message saying a fresh second factor is needed, and no proof at all counts as a refusal. A proof whose time the identity provider did not report is never treated as fresh. An approval from a mailed link carries no proof of its own, so under Required the approver is asked to open the app instead; the link is not spent.
In-session step-up. The way back from that refusal does not need a sign-out. In the app, the refused action opens a dialog that asks for the authenticator code, re-issues the session with a fresh proof and replays the action once. This works for people with a local authenticator. A session signed in through an OIDC or SAML identity provider gets the same result through a round trip: the dialog sends the browser to the identity provider with a forced fresh sign-in, the platform checks that the same person came back with a second factor proved after the round trip started, and the app exchanges a single-use code for the upgraded session. The refused action is then repeated once, for the same login only and within ten minutes; it had done nothing the first time, so the repeat cannot apply it twice. An OIDC login that has never signed in through the identity provider cannot step up this way, and whether Microsoft Entra reports the fresh second factor depends on its Conditional Access configuration.
Break-glass is deliberately exempt. Activation is never blocked by the fresh second-factor check, because an MFA or identity-provider outage is exactly when the panic button is needed. Under Required it goes through without a fresh proof and is recorded loudly: a critical-severity audit entry (with the reason: no proof, stale or time unknown) and a security event for webhooks. Under Report only it leaves the "would have been refused" note. The same logic applies to eligibility: the roles that Required pauses still count when deciding who may activate a break-glass profile that is open to a role, so that person is not locked out of the panic button, and the record says so. The paused roles stay paused for everything else.
Defaults and limits. Everything above is opt-in per tenant through the MFA policy, which is off for every tenant, including new ones; whether new tenants should start with Required is undecided. Not covered: other decision-task kinds, AD writes that only arise through a role expansion, and the elevation session scheduled after an approval.
Separately, the vendor side asks for a recent second-factor sign-in before its destructive operations on a tenant (reissuing tokens, exporting or deleting a tenant, creating support credentials; ten minutes by default) and prompts the operator to sign in again. That protects the tenant from the operator's session, not the other way round.
Known edges, published rather than discovered
- No recording, no vaulting, no proxy — entitlements and their lifetime, not sessions and their contents.
- How an elevation reaches the target is a per-tenant setting, and the default is conservative. In direct mode — the default — the platform records the time-boxed grant but does not call the connector: the window is governed and evidenced here while membership at the target is unchanged. In recon mode the elevation is written as a time-boxed expectation, and reconciliation pushes it to the target at the start and pulls it back at expiry. Only the second makes "granted at the start, revoked at the end" a statement about the target system as well as about our records, so ask which mode a deployment runs before reading an elevation report. Break-glass is not symmetric — its activation calls the provisioning engine in both modes, because the panic button must work even when reconciliation is degraded. In recon mode the expiry or revoke is then carried out by reconciliation, and a reconciliation pass afterwards keeps the baseline truthful.
- The delivery mode is recorded, not brokered. An entitlement can carry an allow-list of how privileged access should be delivered — self-elevation, a shared account, an ephemeral account — and the choice is validated against it and stamped on the session. The platform does not broker a shared account or mint an ephemeral one; the field governs an intent the operating procedure carries out. The same holds for a break-glass profile's access mode.
- The break-glass justification deadline is tracked, not enforced. An overdue activation is visibly overdue and the reason stays mandatory to close the record, but nothing escalates it automatically or cuts the access short. Chasing it is a review duty.
- Elevation needs an account to elevate. Neither route creates the account it needs; if the administrative account does not exist yet, that is provisioning work to do first.
- Break-glass has no approval step at all. That is the design, not an omission, and it is why eligibility, the clock, the critical-severity record and the post-use review carry the whole weight.
Further reading: