Answers to the questions
we hear most often

The agent authenticates with an ECDSA P-256 keypair. On first boot it generates the keypair on your host and registers the public key with a one-time enrolment credential. From then on it proves its identity with a signed challenge-response that is verified against that public key. The private key never leaves your machine. Sessions are short-lived and are re-established from the keypair, so there is no long-lived shared secret. Connector secrets for agent-mode connectors are held in an encrypted store on the agent host and are never sent to the control plane. Self-updates are signature-verified, and an update that does not verify is refused.

The agent rolls back automatically. It keeps the previous version before it applies a self-update, and a new version is only accepted once it has started and stayed up. If the new version crashes on start-up, the next start detects that and runs the previous version again. No operator has to do anything, as long as the agent runs under a service manager that restarts it. The standard systemd and container installs both do.

RapidValue’s standard managed control plane runs at Scaleway, a French cloud provider, in its Amsterdam region in the EU. Customer-managed cloud and on-premises are alternative deployment models for when your architecture or policy calls for infrastructure you control. Connector credentials for agent-mode connectors stay inside your own network and never reach the control plane. Only configuration and results travel between the two.

Yes, over an outbound webhook. There is no dedicated Splunk, Sentinel or QRadar connector. You configure an HTTPS endpoint per tenant and RapidValue POSTs events to it. A Security events preset turns on the whole security category in one click: failed sign-ins, the brute-force cool-down, a person locked out and unlocked, an NHI kill switch thrown and released, an emergency activation, a break-glass revoke, a new SoD violation, a risk score crossing into critical, and a sync held by a safety limit. Each POST carries the event type in a header and, if you set a signing secret, an HMAC-SHA256 signature over the body. Every attempt is logged with its status, the HTTP code and a structured failure reason such as connection refused, timeout, DNS, TLS, 4xx or 5xx. Anyone with audit rights can read that log without being an admin, and the log never shows the endpoint or its secret. There are two limits. First, there is no automatic retry today. An admin re-sends a failed delivery, and the retry is logged as a new attempt next to the failed one. Second, the only authentication events in the feed are failed sign-ins and the lockout that follows them. There is no stream for successful logins, MFA or password changes. Failed-login payloads carry a reason class and leave out the address that was tried, so nobody can use the feed to enumerate your users.

In every connector mode the control plane receives and stores the synced identity model: identities, accounts, entitlements and grants. Reconciliation, risk scoring, certifications and audit run there. The tier-3 agent changes where credentials are kept and how your network is reached. It does not change the data flow. Connector secrets are looked up locally on the agent and are never sent to the control plane. You decide how much data is imported: in the onboarding wizard you select, per object and attribute, exactly what comes in. The imported model is processed and stored in the EU-hosted managed control plane. It can be exported under GDPR Article 20 and erased under Article 17, within the stated limits for legal retention.

That depends on the mode a connector runs in, and there are three modes. In agent mode the credential (LDAP bind password, AD service account, API token, OAuth client secret) is kept in an encrypted store on the agent host inside your VPC. The agent looks it up locally when it runs, and it is never sent to the control plane, not even encrypted. In in-process mode, which is used for internet-facing SaaS targets, the credential is kept in the control plane’s vault, or in your own vault if you register one. With your own vault we store a reference and you keep the value. In tunnel mode the credential is also kept on the control-plane side, and the agent only carries the request over your network. You choose per connector how your network is reached and where the credential is kept. The credential CLI restricts the store and its master key to owner-only permissions on the host when credentials are added. In production it is common to take the master key from a secrets manager such as HashiCorp Vault or Azure Key Vault, and not from a local file.

Yes. A POC processes real identity data in the EU-hosted managed control plane, so our standard DPA applies from day one. We sign the DPA as part of POC onboarding. Because of the tier-3 agent you do not hand over connector credentials. Secrets stay in your network for the whole POC.

DORA (Digital Operational Resilience Act) requires financial entities to monitor and manage ICT-related risks continuously, including access rights for critical functions. These RapidValue capabilities address DORA requirements. Scheduled reconciliation: a daily tenant-wide run, a recompute per identity after each import, and runs on demand. Every run is timestamped and keeps evidence per grant that answers why the access exists. Segregation of duties: you declare cross-system SoD rules once, and RapidValue keeps detecting violations wherever they occur. Non-human identity governance: service accounts and bots are governed by the reason they exist. A person states that reason, RapidValue does not guess it from the identity type, and ownership is tracked. Third-party access governance: contractor and partner identity flows with an access end date. Audit trail: an unchangeable audit log per category that you can export for a regulator. The Financial Services sector pack contains 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 and four-eyes approval on privileged and emergency requests. The compliance posture engine scores your estate against DORA Art. 9 and Art. 28 controls out of the box. It calculates the score from live certification, privileged-access and NHI-ownership coverage. It does not use a questionnaire.

Yes. NIS2 requires essential and important entities to implement access control policies, multi-factor authentication and continuous monitoring of privileged access. RapidValue covers this in four ways. Continuous access certification, triggered by events as well as by the yearly schedule. NHI governance based on a stated reason for existence, so that critical service accounts are identified and have an owner. Blast-radius scoring for non-human identities and roles, which shows what a compromised one could reach. Audit-ready evidence for every reconciliation run, which meets the requirement for documented access oversight. For critical-infrastructure sectors, the Manufacturing pack contains a four-eyes baseline for OT/SCADA access and the Public Sector pack contains an AI-agent approval baseline. Both are 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 reports per account, and privileged access comes from your just-in-time coverage. Where a connector reports no MFA state at all, we show that control as an unmeasured gap and leave it out of the score. We do not round it to zero or to a hundred per cent.

A report opens as a view that is paged, sorted and searchable. The filter that was applied is shown on screen, and you can drill through per cell. The same saved filter drives the export, so the file and the screen show the same data, including masking. There is no self-service report builder for end users. What you get is the report catalogue plus saved filters.

Yes. RapidValue supports the access control requirements of SOX, in particular Section 404 on internal controls. It offers segregation of duties policies with automated violation detection, access certification campaigns with approval trails and timestamps, an unchangeable audit log of all access decisions and certification outcomes, and role-based access control with a recorded justification per grant. External auditors usually like the snapshot per grant. You ask which access person X held at point in time Z, and RapidValue reconstructs it from the unchangeable event history. The approval and justification for each grant are shown next to it in the same audit trail, so no engineer has to rebuild the situation by hand. There is one limitation you should know about. The reconstruction reads that event history, and access that an import writes straight into a target does not pass through it yet. On a freshly synced estate a reconstruction therefore reports less than there is, and it lists what it cannot account for. RapidValue holds no SOX, ISO 27001 or SOC 2 certification, and an evidence pack is not an audit opinion. We deliver the evidence your auditor asks for, produced from live data. The opinion is theirs.

The agent installs in under 5 minutes and the first connector syncs within the first hour. You see a first result in one morning: by lunch your HR data and one application are connected and the gaps are on screen. The POC follows the week after and gives you a working governance environment, including initial role mining and a first certification campaign. A 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 take 6–18 months for the same scope. You also do not start from an empty screen on the first afternoon. Four starter packs (birthright, JML, access review, SoD) are installed switched off, so you edit existing governance rules and do not have to write them from scratch.

Once a week a bot signs in as six different personas and opens every route that the persona’s own navigation offers. It reads those routes from the rendered page, so we do not maintain a list. On each page it checks four things: the page loads, the console is clean, no untranslated key is on screen, and a page the navigation offered does not answer with “no access”. That is six personas and a couple of hundred routes in every run. The bot cannot judge whether a screen is any good. A person still has to do that, and the test report says so at the end of every run.

A typical POC runs as follows. It builds on the first morning, so the agent and your HR source and first application are already connected, and Serge, the founder, works with you throughout. Day 1: the Quick Scan runs on the connected data, role mining generates proposals and a take-home report is prepared for your CISO. Rest of the week: you connect more target systems, run a full reconciliation and configure a first certification campaign. End of the week: a debrief with your team, a pricing discussion and a plan for the path to production. You do not have to set up any infrastructure beyond running the one-line installer. The standard DPA is signed as part of POC onboarding (see Data & privacy), and it does not add lead time.

No. The agent is a single Python file that runs on any Linux host, including WSL2 on Windows. It needs very little: a small VM with 1 vCPU and 512 MB RAM is plenty, and 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 similar) and downloads our connector code from the control plane, version-locked by content hash. So “one file” describes what you audit, and the full install is somewhat larger. 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 and do not provision new infrastructure.

Engine pause consists of three independent switches, for sync, reconciliation and provisioning. Each one stops that engine across the entire tenant. The switches stay in place across restarts and are visible to all admin users. This matters because IGA engines run on schedules. If you discover a role model error at 11pm, you need to stop the right engine, or all three, while you investigate, without touching configuration files or killing processes. A pause switch does that in one click. A reason is recorded next to the pause state, with who paused and when, and every admin sees it until the engine is resumed. We do not know of another IGA platform that has this as a standard 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 find 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, for example “Finance Manager in the IT department”, gets proposed several times by different algorithms from different source systems. Without deduplication you would receive 7 proposals that all say the same thing. RapidValue detects overlapping proposals (similar entitlement sets, similar groups of members) and merges them into a single proposal with an explanation of the merge. You review one proposal and see where it came from.

Every non-human identity (service account, AI agent, bot, IoT device, cloud workload) gets a lifecycle driver at registration. The driver says why the identity exists, and RapidValue does not guess it from the kind of identity. There are four drivers. Change-driven: tied to a code deploy or a config change, such as a CI/CD service account or a pipeline credential. Runtime-driven: exists because something is running right now, such as a scheduled job or a workload identity. Asset-bound: tied to a piece of infrastructure, such as a device or a certificate. Purpose-driven: exists for a stated business reason that outlives any one system, such as an integration or a data feed. A person states the driver at registration. A value that RapidValue only suggests from the identity type never closes a governance finding. AI agents also have a second property: an autonomy tier (assisted, supervised, autonomous) that sets how often the agent is re-attested. That is separate from the lifecycle driver, which answers why the identity exists at all. Ownership coverage (the percentage of NHIs with a named owner) is a top-line KPI in the governance dashboard from day 1.

RapidValue treats itself as a 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. When you invite a colleague with a role, RapidValue creates a real, governed grant that shows up in reconciliation and access reviews. Safeguards prevent you from locking yourself out. Automation can never deactivate or demote the last active admin, and an active admin’s role membership is protected against revocation by a connector. An emergency lockout of a compromised admin still removes everything immediately.

Yes, as a standard feature. Break-glass profiles link eligible people to the emergency entitlements of your critical systems. Coverage is tracked, and the number of systems without an emergency path is a KPI. Activation takes one click and is time-bound: it expires automatically and the access is revoked on expiry. Every activation is recorded on the unchangeable audit trail at critical severity and stays flagged until a justification is filed. The event-review rule then starts a review of exactly what was used.

Reviewers delegate their queue for a period, either for an absence or as a standing arrangement. Decisions taken on someone’s behalf carry an “on behalf of” badge and can be audited separately. The approval chain keeps moving while someone is away, and the audit trail still shows who decided. An overdue queue also reminds its owner automatically, so delegation is only needed for absence.

The approver first gets an email. It goes to the approver of the step that is theirs. The email can carry one link to the decision page. It never shows Approve next to Reject. The link names the item and the recipient and does not contain the decision, so opening it twice decides nothing. The decision itself is taken on a page that shows the SoD and high-risk warnings, and a rejection always needs a written reason. This is set per tenant and is off until you turn it on. The same email and the same single link now also cover certification rounds. A new review announces itself, and a due-soon reminder is a separate message.

No. The approver of the pending step gets an email. A scheduled job sends reminders for an overdue decision at regular intervals, and a standing view shows what has been waiting longest and with whom. You also see a measured “typically approved in” time. It is the median of this tenant’s own last ninety days, and no number is shown when there is too little data. You are told when the outcome is known, including a “your access is live” message that is sent once provisioning has completed.

Agents hosted on Microsoft Entra Agent ID (including agents built in Copilot Studio and AI Foundry), Amazon Bedrock and AgentCore, Google Vertex AI Agent Engine and Agentspace, Salesforce Agentforce, ServiceNow AI agents and GitHub Apps. On AWS and Google Cloud you can also tag IAM users or declare service accounts as agents. GitHub discovery stays off until an organisation owner enables it. Self-hosted agents are registered through intake by a named sponsor. Where the platform records a sponsor, RapidValue imports it as the owner. These AI agents are something different from the tier-3 agent, which is RapidValue’s own connector runtime.

It depends on the platform, and RapidValue tells you what it did. In Entra it disables the agent. On AWS it attaches a deny-all policy and reads it back, and a role shared with other workloads is reported as shared. On Google Cloud it disables a user-managed service account and refuses Google-managed ones. For GitHub Apps it locks the agent in RapidValue and states that GitHub cannot be stopped from there. In every case the identity is locked in RapidValue, the credentials RapidValue issued are revoked, a typed reason is required and the action is audited. Releasing the switch does not re-issue revoked credentials.

Yes. RapidValue’s own MCP server lets your AI assistants ask questions, request access and decide their user’s own tasks, with only what that user may see. Each connected assistant is governed as an AI agent with an owner and a kill switch. In early access is RapidValue’s gateway in front of your MCP servers and internal APIs. Each tool becomes an entitlement that goes through request, approval, certification and segregation-of-duties checks, and the gateway decides every call and blocks what is not allowed. It holds the system’s credential so the agent never sees it, and each system starts in observe mode. A gateway you already run can ask RapidValue for the same decision in the OpenID AuthZEN format. Decisions are sealed every hour. A model never gets a direct path to a connector.

RapidValue records credential metadata and never the secret itself. The metadata comes from Entra app registrations (secrets and certificates), AWS IAM access keys, Google Cloud service-account keys, Google Workspace app passwords and Active Directory (password age as rotation, last logon as use), plus the API credentials RapidValue issues. Non-expiring credentials, credentials expiring within 30 days, unused API credentials and overdue rotations become findings. When a source does not report use, the credential is shown as “not reported”. It is not shown as “never used”.

IVIP stands for Identity Visibility & Intelligence Platform. It is the analytics and risk layer built into RapidValue: a stored risk score per identity, cross-system SoD detection, dormant grant detection, peer-group outlier detection and daily risk-trend snapshots. It matters because most IGA tools give you governance workflows and leave it to you to work out where to focus. IVIP answers the question “which 5 identities should I look at right now?” with a score that is calculated by fixed rules and broken down into its components. It uses no LLM, and you can see how every score was calculated. It is also what makes it possible to observe before you govern. You can keep any system or object read-only, get the full risk picture and recommendations from day one, and enable provisioning per system once you have seen the value.

Yes, it is fully deterministic and uses no machine learning. The score is a weighted sum from 0 to 100 over 18 declared components, 16 of which contribute to the score. They include: dormant grants, with dormant privileged grants weighted separately; cross-system SoD violations, in warning and critical buckets; shadow access, meaning permissions inherited through nested groups; peer-group outliers, meaning more access than statistically comparable colleagues; active grants on a terminated identity; privileged access without a recent certification; non-human identities without an owner; open review items and identity warnings, by severity; and open platform-advisor findings, by severity. Each component has a configurable weight. The breakdown is shown in the identity drawer, so you can always see why a score is what it is.

It is a scheduled detector that flags entitlement grants whose holder has not used them in N days. “Use” is derived from usage data per target system, such as login records, API call counts and last-active timestamps. The detector only judges what it can observe. A grant can only be flagged as dormant on a connector that reports usage. On a system where RapidValue cannot see activity, dormancy is shown as unknown, so a list of dormant grants never contains grants that are simply untracked. Dormant grants raise the holder’s risk score and appear as Platform Advisor recommendations, for example “Revoke 23 dormant grants across 4 systems. ETA: 0 user impact.” You click through to validate and revoke, one at a time or in bulk. Revocation is always an explicit admin action. There is no automatic revocation, because removing access has a large impact and a person should decide it. First scans in mid-market environments regularly find a substantial share of dormant grants, which means direct licence savings and a smaller attack surface.

Identities are grouped by department and job function. The detector flags identities whose access is far above the median of their group. It uses the median, so one outlier cannot shift the baseline. A typical finding is “Bob has 3× the access of his peer group”. An outlier becomes a candidate for one of three actions. A targeted certification, where the manager confirms that the extra access is justified. A role-membership review, where Bob’s extra access matches a role he should formally have. Or right-sizing, where Bob collected this access in previous positions and it is cleaned up. The result is deterministic, and the breakdown shows which specific entitlements cause the deviation.

They are two words for the same engine. A SoD rule is how you declare a toxic combination: two conditions across systems, such as “vendor maintenance in Workday” and “payment approval in SAP”, that no one person should hold together. The evaluator runs continuously and flags every identity that holds both sides, however they got them: through different roles, different systems, or grants nobody meant to combine. Violations appear in three places and come from the same 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 or warning). We chose one engine on purpose, because two separate detectors would give you two answers that disagree.

Audit packs are pre-built evidence bundles mapped to a framework. You pick a date range and click “Generate + download”. You get a ZIP with 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 the row counts per section. There are ten templates today. These are the framework-mapped ones you will be asked for first. SOX § Access Management: access provisioning, change and review, mapped to PCAOB AS 2201 control objectives, with the underlying framework citation. ISO 27001 Annex A.9 Access Control: user-access registration, privilege management and review of access rights. HIPAA § 164.312 Technical Safeguards: access control, audit controls, integrity, person/entity authentication and transmission security, aimed at covered entities and business associates that run systems holding PHI. GDPR Art. 32 Security of Processing: appropriate technical and organisational measures to ensure security appropriate to the risk. DORA Art. 9, NIS2 Art. 21 and SOC 2 CC6: the three that EU mid-market organisations are 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. There are also two operational packs: joiner/mover/leaver lifecycle evidence, and privileged/just-in-time access. The packs contain what your auditor asks for, so you can bring them to the audit kickoff. A pack is a bundle of records taken from the hash-chained audit trail, which cannot be changed in the database. Its manifest holds a hash of every file in the pack and repeats what the pack claims, such as each section’s citation and row count, so changing a file or a label fails verification. The manifest carries one Ed25519 signature with a per-tenant key, and we publish the public half. Your auditor can therefore verify the pack without us, with the standalone verifier included in every pack or with OpenSSL alone. Your auditor takes the public key from your published signing keys, not from the pack itself, and needs nothing further from us. Packs signed before October 2026 still verify. The raw audit-log export carries an Ed25519 signature too.

New connectors start with provisioning enabled, but every new grant is held in a batch. Outgoing access changes wait for your explicit approval until you remove the training wheels, per system. To be precise: the gate covers creating and granting today. Revokes and attribute write-backs are governed by their own policy per connector, and the batch gate does not cover them. Identities, accounts and entitlements sync in from the first run, and the full IVIP picture (risk score, SoD, reconciliation, advisor) is available immediately. The result is that a new target is onboarded in minutes, and you see what RapidValue finds in your access before anything changes in the target. If you want to observe before you govern, you can also set any object to read-only (a write_enabled flag per object) and read it without configuring write-back at all. The path is: connect with the gate on, mine roles and set policies, and remove the gate for high-value targets (typically AD first) once the reconciliation evidence has convinced you.

The catalogue contains 20 connectors today: 14 vendor templates plus six generic engines. Microsoft Entra ID (Azure AD), with full Graph API integration. Exchange Online, for mailbox and distribution-group governance. Google Workspace, with the Admin SDK directory and a Drive unstructured-data scan. Active Directory and generic LDAP, covering AD, OpenLDAP and IBM/Oracle Directory. ServiceNow, in both directions: it provisions and it creates tickets for manual tasks. Salesforce, for profile and permission set governance. Workday, as an HR source. SAP SuccessFactors, as an HR source. Box, with a folder and collaboration scan (unstructured data). AFAS, TOPdesk, Nmbrs, Atlassian and GitHub, as vendor templates for the Dutch and Belgian mid-market. SMB/NTFS file shares, with an unstructured-data scan by the agent behind the firewall. Generic SCIM 2.0, for any SCIM-compliant target (Slack, GitHub Enterprise, Atlassian, …). Generic REST, for any JSON API, including CSV/JSON HR feeds. Generic SQL, for Postgres, MySQL and MSSQL application databases. SFTP-CSV, for flat-file HR feeds over SFTP/HTTPS. The unstructured-data scans (Google Drive, Box, SharePoint, SMB/NTFS) are a preview. They are switched off by default and enabled per tenant on request, because they have not yet been proven in a live customer environment. Nmbrs (Visma) is a template. The one-time OAuth consent runs in the wizard: you register the app in your Nmbrs developer portal, click Connect and sign in once. After that it runs unattended on its refresh token. It is also the one connector we did not build ourselves. It was contributed as a package against our template SDK, which shows that less common connectors do not have to wait for our roadmap. SOAP / WS-* is marked as coming soon and is not one of the twenty. Custom connectors are built with the guided wizard, using REST, LDAP or SCIM endpoints. The wizard’s live discovery fills in most of the mapping configuration, so you check suggestions and do not have to write the mapping from scratch.

With the wizard a standard REST or SCIM target is connected in about 15 minutes. You point the wizard at the target’s discovery endpoint, it returns a mapping suggestion, and you check about 10 fields where you would otherwise define 100 from scratch. For complex targets (multi-step authentication, non-standard schemas, legacy SOAP APIs), custom connector development is available as a service. That typically takes 3–5 days for a production-grade connector.

That depends on what you migrate. Connectors: the wizard rebuilds connector configurations from live discovery, which is usually easier than migrating connector XML or configuration from the old tool. Role model: role mining derives it again from your current access data. In practice that gives a cleaner result than importing the role definitions the old tool has accumulated, and every proposal comes with evidence. Certification history: you keep your old tool’s evidence exports for the retention period, and RapidValue starts a new, unchangeable evidence trail from day one. Workflows and policies: you declare SoD rules again in the rule editor and rebuild approval rules in the visual builder. We scope a migration from an existing tool at 4–8 weeks for a typical mid-market estate. Deployments with many accumulated customisations are more complex, and we scope those individually.

You can export everything yourself, at any time. A full export per tenant (GDPR Art. 20) produces a machine-readable copy of all your data: identities, accounts, entitlements, configuration and the complete audit history. You get a tar.gz with one JSONL file per table, behind a signed link that is valid for 24 hours. It is a button for tenant admins in your own settings, so you do not need a ticket and do not have to wait for us. On termination we offboard in two steps. Your tenant is first put in an offboarding state, in which nothing new happens and everything can still be exported. Permanent deletion only runs after an explicit, typed confirmation and never as an automatic background step. The code enforces a 30-day grace period between the two steps. Before it has passed, the delete is refused. Overriding it early is an admin action that writes its own audit event. The unchangeable audit log is the one thing that is kept after deletion, under the legal-retention ground of GDPR Art. 17(3)(b). For agent-mode connectors your credentials never left your network in the first place, and the agent’s local vault is yours to destroy.