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, restricted to administrators, managers and helpdesk, with no approval chain, a bounded duration (5 minutes to 12 hours) and a mandatory justification.

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.

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.
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; an administrator records the outcome as approved or a violation.

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.

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.

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 Owner for 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-9f3c2a1b with 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

Privileged access is a paid-tier capability, included from the Business plan up. The gate is enforced on the server, at the top of the three endpoints that grant privileged access or provision the capability: direct elevation, break-glass activation, break-glass profile creation. The interface hides the surfaces too, but hiding is not the control — a direct API call meets the same refusal.

Reading, listing, revoking, exception handling and evidence are never gated: de-escalating access and proving what happened must work regardless of what a tenant pays, and a plan change must never strand a live elevation. Unbilled and trial tenants are treated as unrestricted, not blocked.

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 — it calls the provisioning engine in both modes, because the panic button must work even when reconciliation is degraded.
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 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: