Frequently asked questions

The agent authenticates with an ECDSA P-256 keypair. On first boot it generates the keypair on your host and registers the public key using a one-time enrolment credential; from then on it proves itself with a signed challenge-response verified against that public key. The private key never leaves your machine, and sessions are short-lived and re-established from the keypair rather than from a long-lived shared secret. Connector secrets for agent-mode connectors (LDAP bind password, AD service account, etc.) are held in an encrypted store on the agent host — never sent to the control plane.

For high-security environments, client-certificate pinning can be layered on top, binding an agent to one specific certificate in addition to its keypair.

Self-updates are signature-verified. The agent checks an update's signature against a key it already holds before it installs anything — an update that doesn't verify is refused outright.

Automatic rollback. The previous version is kept before any self-update is applied, and a new version only becomes the accepted one once it has come up and stayed up. If it crashes on start-up instead, the next start detects that and re-executes the previous version.

No operator action required — the recovery is automatic, provided the agent runs under a service manager that restarts it (the standard systemd and container installs both do).

Several options are available depending on your data residency requirements:

• SaaS (standard): AWS eu-west-1, Ireland. Fully managed, GDPR-compliant EU data residency.
• EU Sovereign SaaS (on request): OVH or Scaleway, EU-domiciled. No US Cloud Act exposure, no American legal jurisdiction over your data.
• Private Cloud (available on request): Deployed inside your own AWS, Azure, or OVH account. Your data stays in your environment.
• On-Premises (available on request): Runs in your own datacenter under your own controls.

Only the managed SaaS option is productised today. The other three are real offers we scope and build with the first customer who needs them — worth knowing before you plan a timeline around one.

In all cases, connector credentials for agent-mode connectors stay inside your own network and never reach the control plane — the wire carries configuration and results, never secrets.

In every connector mode, the control plane receives and stores the synced identity model — identities, accounts, entitlements and grants. That's the product: the EU-hosted control plane is where reconciliation, risk scoring, certifications and audit happen, and it needs the model to do that work.

What the tier-3 agent changes is custody of credentials and network reach, not the data flow: connector secrets resolve locally on the agent and never cross the wire — the wire carries configuration and results.

Data minimisation is in your hands: the onboarding wizard's attribute selection lets you choose, per object and per attribute, exactly what gets imported. Everything you do import is EU-hosted, fully exportable (GDPR Art. 20) and erasable (Art. 17).

It depends on the connector's execution mode, and the honest answer has three parts. In agent mode the credential (LDAP bind password, AD service account, API token, OAuth client secret) lives in an encrypted store on the agent host inside your VPC; the agent resolves it locally at execution time and it is never sent to the control plane, not even encrypted. In in-process mode — used for internet-facing SaaS targets — the credential lives in the control plane's vault, or in your own vault if you register one (bring-your-own-vault: we store a reference, you keep the value). In tunnel mode the credential also lives control-plane-side; the agent only carries the request over your network. Reach and custody are the two axes, and you pick them per connector.

The credential CLI locks that store and its master key down to owner-only permissions on the host as credentials are added. In production deployments, it's common to source the master key from a secrets manager (HashiCorp Vault, Azure Key Vault) rather than a local file.

Yes. A POC processes real identity data in the EU control plane — that's where governance happens in every mode — so our standard DPA applies from day one. We sign it as part of POC onboarding, so it costs you no extra lead time.

What the tier-3 agent does change: you never hand over connector credentials. Secrets stay in your network for the entire POC.

DORA (Digital Operational Resilience Act) requires financial entities to continuously monitor and manage ICT-related risks, including access rights for critical functions. Key RapidValue capabilities that address DORA requirements:

• Scheduled reconciliation: a daily tenant-wide run, a per-identity recompute after each import, and on demand — every run timestamped with per-grant evidence — "why does this access exist?"
• Segregation of duties: declarative cross-system SoD rules with continuous violation detection — toxic combinations declared once, flagged wherever they occur
• Non-human identity governance: service accounts and bots governed by why they exist — an asserted lifecycle driver, never guessed from the identity type — with ownership tracked
• Third-party access governance: contractor and partner identity flows with access expiry
• Audit trail: immutable audit log per category, exportable for regulator submission

The Financial Services sector pack ships DORA-cited SoD rules (developer-plus-production access, for instance, cited to Art. 8) and approval baselines — a three-approver chain on high-risk resources, four-eyes on privileged and emergency requests. The compliance posture engine scores your estate against DORA Art. 9 and Art. 28 controls out of the box, computed from live certification, privileged-access and NHI-ownership coverage rather than a questionnaire.

Yes. NIS2 requires essential and important entities to implement access control policies, multi-factor authentication, and continuous monitoring of privileged access. RapidValue addresses this through:

• Continuous access certification (event-triggered, not just annual)
• NHI governance keyed to an asserted lifecycle driver — critical service accounts identified and ownership-governed
• Blast-radius scoring for non-human identities and roles — what a compromised one could reach
• Audit-ready evidence per reconciliation run — meeting the "documented access oversight" requirement

For critical-infrastructure sectors, the Manufacturing pack ships a four-eyes baseline for OT/SCADA access and the Public Sector pack an AI-agent approval baseline, both cited to NIS2. The compliance posture engine scores your estate against NIS2 Art. 21 controls out of the box — multi-factor authentication and privileged access are scored as two separate controls, because they are two different things: MFA registration comes from what your IdP actually reports per account, privileged access from your just-in-time coverage. Where a connector reports no MFA state at all, we publish that control as an unmeasured gap and leave it out of the score rather than rounding it to zero or to a hundred per cent. We measure what we can see, and we say when we cannot see it.

A report opens as a view: paged, sorted, searchable, with the filter it actually resolved stated on screen and drill-through per cell. The same saved filter drives the export, so the file and the screen agree — masking included.

What we do not have is a self-service report builder for end users; the catalog plus saved filters is the honest description.

Yes. SOX's access control requirements (particularly Section 404 on internal controls) are well-supported:

• Segregation of duties policies with automated violation detection
• Access certification campaigns with approval trails and timestamps
• Immutable audit log of all access decisions and certification outcomes
• Role-based access control with evidenced justifications per grant

External auditors typically appreciate the per-grant snapshot model: ask what access person X held at point-in-time Z and it is reconstructed from the immutable event history, with the approval and justification for each grant sitting next to it in the same audit trail — instead of an engineer rebuilding the world-state by hand. One caveat we would rather state than have an auditor find: the replay reads that event history, and access an import writes straight into a target does not pass through it yet. On a freshly synced estate a reconstruction therefore under-reports — and it names what it cannot account for rather than presenting a confident blank.

The agent installs in under 5 minutes and the first connector syncs within the first hour. The POC is designed to give you a working governance environment within 2 weeks, including initial role mining and a first certification campaign.

Full production rollout (all connectors, full role model, team training, sector pack configuration) is scoped at 4–8 weeks for a mid-market environment. Classic IGA implementations run 6–18 months for the same scope.

And the first afternoon is not blank: four starter packs (birthright, JML, access review, SoD) install inert, so you edit governance instead of authoring it.

Once a week a bot signs in as six different personas and opens every route that persona's own navigation offers — read from the rendered page, not from a list we maintain — and checks four things on arrival: it mounts, the console is clean, no untranslated key is on screen, and a page the navigation offered does not answer with "no access". Six personas, and a couple of hundred routes in every run.

What it cannot judge is whether a screen is any good; that stays a human pass, and the harness says so at the end of every run.

A typical POC runs as follows:

• Day 1, morning: sales engineer joins a call; runs rv-poc bootstrap; agent is installed and connected in <30 minutes; first connector onboarded via wizard
• Day 1, afternoon: Quick Scan runs on connected data; role mining proposals generated; take-home report prepared for your CISO
• Week 1–2: connect additional target systems; run full reconciliation; configure first certification campaign
• End of week 2: POC debrief with your team; pricing discussion; path to production scoped

No infrastructure setup required on your side beyond running the one-line installer. The standard DPA is signed as part of POC onboarding (see Data & privacy) — it costs you no extra lead time.

No. The agent is a single Python file that runs on any Linux host (including WSL2 on Windows). It's a deliberately light footprint — a small VM with 1 vCPU and 512 MB RAM is plenty; in practice it idles at roughly 200 MB. It needs Python 3.12 or newer and outbound HTTPS to the control plane. For agent-mode connectors it also installs a handful of pip packages (httpx, cryptography, ldap3 and friends) and downloads our connector code from the control plane, version-locked by content hash — so "one file" describes what you audit, not the whole install.

For production, we recommend a dedicated VM or container with persistent storage for the agent state files and vault. Most customers run it on an existing management host rather than provisioning new infrastructure.

Engine pause is three independent switches — sync, reconciliation, and provisioning — each halting that engine across the entire tenant. They persist across restarts and are visible to all admin users.

It matters because IGA engines run on schedules — if you discover a role model error at 11pm, you need to be able to stop the right engine (or all three) while you investigate, without having to touch configuration files or kill processes. The pause switches do exactly that in one click, with a reason that is required, not optional — in both directions, turning the pause on and lifting it. It is stored with the pause state, stamped with who paused and when, and shown to every admin until the engine is resumed.

No other IGA platform we're aware of has this as a first-class feature. Most require emergency access to the application server or database to stop a runaway provisioning job.

Role mining analyses your existing access data to identify natural groupings — patterns of entitlements shared by people in similar roles. RapidValue runs 8 algorithms in parallel (attribute-based, organisational, job-function, permission-clustering, context-based, and others).

The deduplication step solves a common IGA problem: the same real-world role (e.g., "Finance Manager in the IT department") gets proposed multiple times by different algorithms from different source systems. Without deduplication you'd receive 7 proposals that all say the same thing.

Our engine detects overlapping proposals (similar entitlement sets, similar member cohorts) and merges them into a single proposal with a merge rationale. You review one proposal with full lineage, not seven with no context.

Every non-human identity — service account, AI agent, bot, IoT device, cloud workload — asserts a lifecycle driver at registration: why it exists, never guessed from what kind of identity it is.

• Change-driven: tied to a code deploy or a config change — a CI/CD service account, a pipeline credential
• Runtime-driven: exists because something is running right now — a scheduled job, a workload identity
• Asset-bound: tied to a piece of infrastructure — a device, a certificate
• Purpose-driven: exists for a stated business reason that outlives any one system — an integration, a data feed

A person asserts the driver at registration — a value merely suggested from the identity type can never quiet a governance finding, only a real assertion can. AI agents also carry a separate, additional property: an autonomy tier (assisted, supervised, autonomous) that sets how often the agent gets re-attested — a different axis from the lifecycle driver, which answers why the identity exists at all. Ownership coverage (% of NHIs with a named owner) is a top-line KPI in the governance dashboard from day 1.

The platform is its own connected system. Every login user is backed by an identity in your directory; platform roles (admin, auditor, helpdesk, …) are group memberships that appear in the same security model as any other access. Inviting a colleague with a role mints a real, governed grant that shows up in reconciliation and access reviews.

Guardrails make self-lockout impossible: automation can never deactivate or demote the last active admin, and an active admin's role membership is protected against connector-driven revocation — while emergency lockout of a compromised admin still strips everything instantly.

Yes — first-class. Break-glass profiles bind eligible people to the emergency entitlements of your critical systems, with coverage tracking — which systems have no emergency path is itself a KPI. Activation is one click and time-bound (auto-expiry, revocation on expiry). Every activation lands on the immutable audit trail at critical severity, stays visibly flagged until a justification is filed, and the event-review rule spawns a post-use review of exactly what was used.

Reviewers delegate their queue for a period (out-of-office or standing). Decisions taken on someone's behalf are visibly badged "on behalf of" and separately auditable — the approval chain never stalls on an empty chair, and the audit trail never loses who actually decided.

And an overdue queue nudges its owner automatically — delegation is for absence, not for forgetting.

They get told first: the mail goes to the approver of the step that is actually theirs. It can carry one decide link — never Approve beside Reject — and the link names the item and the recipient, never the decision; reading it twice decides nothing.

The decision itself is a page with the SoD and high-risk warnings on it, and a rejection always needs a written reason. Per tenant, and off until you turn it on.

The same mail and the same single link now cover certification rounds — a review that lands announces itself, and due-soon is its own message.

No. The approver of the pending step is mailed, an overdue decision is nudged on a cadence by a scheduled job, and a standing lens shows what has been waiting longest, on whom.

You also see a measured "typically approved in" — the median of this tenant's own last ninety days, or no number at all when there is too little data to be honest. And when the outcome lands, you hear it — including "your access is live", which is sent when provisioning actually lands.

IVIP = Identity Visibility & Intelligence Platform. It's the analytics + risk layer built into RapidValue: a materialised per-identity risk score, cross-system SoD detection, dormant grant detection, peer-group outlier detection, and daily risk-trend snapshots.

It matters because most IGA tools today ship governance workflows but leave you to figure out where to focus. IVIP answers "which 5 identities should I look at right now?" with a deterministic score and explainable component breakdown — no LLM, no black box.

It's also what makes "observe before you govern" work: keep any system or object visibility-only, get the full risk surface and recommendations from day one, and enable provisioning per system when the governance value is proven.

Yes — fully deterministic, no ML. The score is a 0-100 weighted sum over 18 declared components, 16 of which score, including:

• Dormant grants — and dormant privileged grants, weighted separately
• Cross-system SoD violations (warning and critical buckets)
• Shadow access — permissions inherited transitively through nested groups
• Peer-group outlier — more access than statistically comparable colleagues
• Active grants on a terminated identity
• Privileged access without a recent certification
• Unowned non-human identities
• Open review items and identity warnings (by severity)
• Open platform-advisor findings (by severity)

Each component contributes a configurable weight. The breakdown is visible in the identity drawer — you can always trace why a score is what it is.

A scheduled detector that flags entitlement grants whose holder hasn't used them in N days. "Use" is derived from usage-data ingest pipelines per target system (login records, API call counts, last-active timestamps).

It only judges what it can actually observe: a grant is a dormancy candidate only on a connector that reports usage at all. On a system we can't see activity for, dormancy is unknown, not zero — so you never get a screen full of "dormant" that really means "untracked".

Dormant grants raise the holder's risk score and surface as Platform Advisor recommendations: "Revoke 23 dormant grants across 4 systems — ETA: 0 user impact." Click-through to validate and revoke, single or bulk. Revocation is always an explicit admin action — deliberately no auto-revoke, because removing access is high-impact and deserves a human decision.

First scans routinely surface a substantial share of dormant grants in mid-market environments — direct license savings + reduced attack surface.

Identities are clustered by department + job function. The detector flags identities whose access set sits far above the cohort median (median, not mean — one outlier can't drag the baseline) — typically "Bob has 3× the access of his peer group".

Outliers become candidates for one of three actions: targeted certification ("manager confirms the extra access is justified"), role-membership review ("Bob's extra access maps to a role he should formally be in"), or right-sizing ("Bob accumulated this access from previous positions — clean up").

Deterministic + explainable — the outlier breakdown shows which specific entitlements drive the deviation.

They're two words for one engine. A SoD rule is how you declare a toxic combination: two cross-system conditions — "vendor maintenance in Workday" vs "payment approval in SAP" — that no one person should hold together. The evaluator runs continuously and flags every identity holding both sides, however they got there: through different roles, different systems, or grants nobody intended to combine.

Violations surface in three places from the same single source: the SoD workbench (with both sides named per person), the compliance posture view (as toxic-combination findings), and the identity risk score (weighted by rule severity, critical / warning). Deliberately one engine — two parallel detectors would give you two disagreeing answers.

Audit packs are pre-built, framework-mapped evidence bundles. Pick a date range, click "Generate + download", and you get a ZIP containing an HTML index that carries the framework-control citation per section, one JSONL data file per section, and a manifest with the date range and per-section row counts.

Ten templates today — the framework-mapped ones you'll be asked for first:

• SOX § Access Management — access provisioning, change, review. Maps to PCAOB AS 2201 control objectives. Auditor-ready, with the underlying framework citation.
• ISO 27001 Annex A.9 Access Control — user-access registration, privilege management, review of access rights.
• HIPAA § 164.312 Technical Safeguards — access control, audit controls, integrity, person/entity authentication, transmission security. Targeted at covered entities and business associates running PHI-bearing systems through ePHI gates.
• GDPR Art. 32 Security of Processing — appropriate technical and organisational measures to ensure security appropriate to the risk.
• DORA Art. 9 · NIS2 Art. 21 · SOC 2 CC6 — the three the EU mid-market is asked for next.
• EU AI Act / ISO 42001 agent governance — the agent register, accountability and attestation history, with its own statement of what it does not claim.

Plus two operational packs: joiner/mover/leaver lifecycle evidence, and privileged/just-in-time access.

What you get is what your auditor asks for — not "we'll have to discuss in scoping". Bring it to the audit kickoff. The pack itself is a bundle of records drawn from the hash-chained, database-immutable audit trail, and it ships signed twice over the same bytes: an HMAC-SHA256 signature over its manifest, plus a hash of every file inside it, so alteration after the fact fails verification. The second signature is ECDSA P-256 with a per-tenant key whose public half we hand out — so your auditor verifies the pack without us, with a standalone verifier that ships signed inside every pack: your auditor unzips and runs it, and nothing further is needed from us. Strip the second signature and the first one notices, because it is declared inside the manifest it signs. The raw audit-log export is signed the same way.

New connectors land with provisioning enabled but every new grant batch-gated: outgoing access changes queue for your explicit approval until you remove the training wheels, per system. Precisely: the gate covers the create/grant direction today — revokes and attribute write-backs are governed by their own per-connector policy, not by the batch gate. Identities, accounts and entitlements sync in from the first run, and the full IVIP surface (risk score, SoD, recon, advisor) lights up immediately.

Result: a new target onboarded in minutes, and you see the platform discovering your access before anything changes in the target. Want to observe before you govern? Any object can additionally be flipped to visibility-only (per-object write_enabled flag) — read it without configuring write-back at all.

The maturity path is explicit: connect (gated) → mine roles and set policies → remove the gate for high-value targets (typically AD first) when the reconciliation evidence has earned your trust.

20 connectors ship in the catalog today — 14 vendor templates plus six generic engines:

• Microsoft Entra ID (Azure AD) — full Graph API integration
• Exchange Online — mailbox and distribution-group governance
• Google Workspace — Admin SDK directory + Drive unstructured-data scan
• Active Directory / generic LDAP — AD, OpenLDAP, IBM/Oracle Directory
• ServiceNow — bidirectional (provisions + creates tickets for manual tasks)
• Salesforce — profile + permission set governance
• Workday — HR-source integration
• SAP SuccessFactors — HR-source integration
• Box — folder + collaboration scan (unstructured data)
• AFAS · TOPdesk · Nmbrs · Atlassian · GitHub — vendor templates for the NL/BE mid-market stack
• SMB/NTFS file shares — agent-side unstructured-data scan behind the firewall
• Generic SCIM 2.0 — any SCIM-compliant target (Slack, GitHub Enterprise, Atlassian, …)
• Generic REST — any JSON API, incl. CSV/JSON HR feeds
• Generic SQL — Postgres / MySQL / MSSQL application databases
• SFTP-CSV — flat-file HR feeds over SFTP/HTTPS

Nmbrs (Visma) ships as a template — the one-time OAuth consent runs in the wizard: register the app in your Nmbrs developer portal, click Connect, sign in once, and it runs unattended on its refresh token from then on. It is also the one that is not ours: it was contributed as a package against our template SDK, which is the proof that the long tail does not have to run through our roadmap. SOAP / WS-* is flagged coming-soon and is not in the twenty. We'd rather you knew that before the demo.

Custom connectors are built via the guided wizard using REST, LDAP, or SCIM endpoints. The wizard's live discovery pre-fills most of the mapping configuration — you validate suggestions rather than author from scratch.

The wizard-based approach typically takes 30–90 minutes for a standard REST or SCIM target. You point the wizard at the target's discovery endpoint, it returns a mapping suggestion, and you validate ~10 fields rather than defining 100 from scratch.

For complex targets (multi-step authentication, non-standard schemas, legacy SOAP APIs), custom connector development is available as a service — typically 3–5 days for a full production-grade connector.

Migration complexity depends on what you're migrating:

• Connectors: the wizard rebuilds connector configurations from live discovery — typically easier than migrating connector XML/configuration from the old tool
• Role model: role mining re-derives it from your current access data — in practice cleaner than importing the old tool's accumulated role definitions, and every proposal comes with evidence
• Certification history: keep your old tool's evidence exports for the retention period; RapidValue starts a fresh, immutable evidence trail from day one
• Workflows + policies: SoD rules are re-declared in the rule editor; approval rules are rebuilt in the visual builder

We scope a migration from an existing tool at 4–8 weeks for a typical mid-market estate. Deployments with heavy accumulated customisations are more complex — we scope those individually.

You can export everything, at any time, yourself: a full per-tenant export (GDPR Art. 20) produces a machine-readable copy of all your data — identities, accounts, entitlements, configuration, and the complete audit history — as a tar.gz of one JSONL file per table, behind a 24-hour signed link. It's a tenant-admin button in your own settings. No ticket, no waiting on us.

On termination we run a two-step offboarding: your tenant is first put in an offboarding state (nothing new happens, everything still exportable), and permanent deletion only executes after an explicit, typed confirmation — never as an automatic background step. A 30-day grace window is enforced in code between the two: before it elapses the delete is refused outright, and overriding it early is an admin action that writes its own audit event. The immutable audit log is the one thing retained after deletion, under the GDPR Art. 17(3)(b) legal-retention ground. For agent-mode connectors your credentials additionally never left your network to begin with — the agent's local vault is yours to destroy.