Frequently asked questions

The agent authenticates with an ECDSA P-256 keypair: on first boot it generates a keypair, registers the public key using the one-time bearer token from registration, and from then on exchanges signed, single-use challenges for short-lived access tokens. A leaked token alone cannot bootstrap a session. Connector secrets (LDAP bind password, AD service account, etc.) are stored locally in an agent-vault.json file on the agent host — never sent to the control plane.

For high-security environments, optional mTLS can be layered on top: the agent presents a client certificate fingerprint with each request, and the control plane validates it before processing.

Self-updates are HMAC-verified: each agent has a unique signing key. The control plane computes a per-agent HMAC over the new agent source. The agent verifies the signature before overwriting itself. A mismatched signature means the update is rejected and the agent stays on the current version.

Automatic rollback. Before any self-update, the current agent is backed up to tier3_agent.py.bak. After restart, the agent has 60 seconds to write a "stable boot" marker. If it crashes before writing the marker, the next startup detects the missing marker, restores the backup, and re-executes the previous version.

No operator action required. The recovery is fully automatic.

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.

In all cases, connector credentials handled by the tier-3 agent 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).

All connector credentials (LDAP bind password, AD service account, API tokens, OAuth client secrets) are stored in agent-vault.json on the agent host — inside your VPC. The agent resolves them locally at execution time. They are never sent to the control plane, not even in encrypted form.

The credential CLI locks agent-vault.json (and the local master key) to owner-only permissions (chmod 600) 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:

• Continuous reconciliation: every run is 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 classified into 4 tiers with ownership tracking
• 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-aligned SoD rules and approval baselines (4-eyes on high-risk), and the compliance posture engine scores your estate against DORA access controls (Art. 9) out of the box.

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 4-tier classification — critical service accounts identified and ownership-governed
• Blast-radius scoring — understand the propagation risk of any compromised identity
• Audit-ready evidence per reconciliation run — meeting the "documented access oversight" requirement

For critical-infrastructure sectors, the Public Sector and Manufacturing packs ship NIS2-aligned approval baselines, and the compliance posture engine scores your estate against NIS2 controls (MFA, access oversight) out of the box.

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 — they can query "why does person X have permission Y at point-in-time Z?" and get a direct answer, not a manual reconstruction.

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.

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 script that runs on any Linux host (including WSL2 on Windows). It's a deliberately light footprint — a small VM with 1 vCPU and 512MB RAM is plenty. Python 3.11+ and outbound HTTPS access to the control plane are the only requirements.

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 an optional reason — 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, RBAC, peer group, hierarchical, 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.

Non-human identities (NHIs) — service accounts, AI agents, bots, IoT devices, cloud workloads — are classified into 4 tiers by their level of autonomy, because autonomy determines the governance they need:

• Tier 1 · AI-Assisted: service accounts and IoT devices — low autonomy; reuse standard IGA flows, manual approval, yearly review
• Tier 2 · AI-Enabled: system accounts — scoped, predictable permissions; credential rotation and periodic review
• Tier 3 · Autonomous: AI agents making their own decisions — just-in-time access, policy-as-code, behaviour monitoring, short-lived credentials
• Tier 4 · AI-to-AI: applications delegating to other agents — identity federation, delegation tokens, full audit chain

Ownership coverage (% of NHIs with a designated 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.

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 of 17 components, 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)
• Stale reconciliation — access not verified against the target recently

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

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: HTML index, per-section data files (CSV/JSON), and a manifest with framework-control identifiers.

Four templates today:

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

What you get is what your auditor asks for — not "we'll have to discuss in scoping". Bring it to the audit kickoff.

New connectors land with provisioning enabled but every write batch-gated: outgoing changes queue for your explicit approval until you remove the training wheels, per system. 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.

17 production connectors are included:

• Microsoft Entra ID (Azure AD) — full Graph API integration
• 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 · 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

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 download link. 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. The immutable audit log is the one thing retained after deletion, under the GDPR Art. 17(3)(b) legal-retention ground. In tier-3 mode your credentials additionally never left your network to begin with — the agent's local vault is yours to destroy.