The tier-3 model separates the control plane (SaaS, hosted in EU) from the execution layer (a lightweight Python agent that runs inside your own VPC or on-premises infrastructure).
The control plane handles: task scheduling, configuration, dashboards, and aggregated reporting. The agent handles: connector execution, identity data processing, and local secret resolution. Connector credentials never leave your VPC.
For SaaS connectors (Entra ID, Salesforce, SCIM apps), the connector can run either in the control plane or via the agent. When run via the agent, identity data stays in your VPC. When run in the control plane, identity data is processed in our EU-hosted infrastructure.
The agent authenticates to the control plane via a bearer token (issued at registration, shown once). 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 enabled: the agent presents a client certificate fingerprint with each request, and the control plane validates it before processing. This provides mutual authentication beyond the bearer token.
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.
The control plane runs in EU-region cloud infrastructure (Belgium/Netherlands). We do not use US-domiciled hosting for EU customer tenants. All data stored at the control plane level (task metadata, connector configuration, aggregated metrics) is processed in the EU and subject to GDPR.
For Enterprise customers with stricter requirements, the control plane can be deployed on-premises in your own Kubernetes cluster.
It depends on your deployment mode:
Tier-3 agent mode (on-prem connectors or agent-routed SaaS): the control plane receives only task metadata (duration, success/failure, aggregate counts). No employee names, account details, entitlement lists, or personal data.
SaaS connector mode (control plane executes the sync): identity data is processed in our EU-hosted control plane. It is not stored permanently — it is used to compute governance decisions and audit events, then discarded. A DPA governs this processing.
Connector credentials (passwords, API tokens) are never sent to the control plane in either mode when using the tier-3 agent.
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 agent-vault.json file is created with chmod 600 by the installer. In production deployments, it's common to mount it from a secrets manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) rather than storing it as a plain file.
For tier-3 POCs (agent in your VPC, on-prem connectors): no DPA required, because identity data never leaves your infrastructure. You can run a proof-of-concept with real production data without prior legal review.
For SaaS connector POCs where data is processed in our EU control plane: a DPA is required. We can execute one within 48 hours of request — contact us and we'll handle it promptly.
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: toxic combination detection across both SoD policies and heuristic pattern matching
- 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 includes pre-configured DORA certification templates and SoD rules.
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 Healthcare and Public Sector packs include NIS2-aligned certification templates.
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. The first connector sync runs in under 30 minutes. Most customers have a working governance environment within 2 weeks, including initial role mining and the first certification campaign.
Full production rollout (all connectors, full role model, team training, sector pack configuration) typically takes 4–8 weeks for a mid-market environment. This compares to 6–18 months for classic IGA implementations.
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. No DPA needed for the POC.
No. The agent is a single Python script that runs on any Linux host (including WSL2 on Windows). Minimum requirements: 1 vCPU, 512MB RAM, Python 3.10+, outbound HTTPS access to the control plane.
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.
The engine pause is a global switch that halts all provisioning, reconciliation, and sync scheduling across the entire tenant. It persists across restarts and is 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 everything while you investigate, without having to touch configuration files or kill processes. The pause switch does exactly that in one click, with a mandatory reason field that appears in the audit log.
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 based on their risk profile and operational pattern:
- Tier 1: Critical infrastructure services (database service accounts, PKI accounts, backup agents) — highest scrutiny, mandatory ownership
- Tier 2: Business-critical automation (ERP integration accounts, payroll bots) — ownership required, quarterly review
- Tier 3: Operational tooling (monitoring agents, CI/CD service accounts) — ownership tracked, annual review
- Tier 4: Low-risk automation (read-only report bots, notification services) — catalogued, no active review required
Ownership coverage (% of NHIs with a designated owner) is a top-line KPI in the governance dashboard from day 1.
8 production-grade connectors are included:
- Active Directory (LDAP)
- Microsoft Entra ID (Azure AD) — full Graph API integration
- Generic LDAP — OpenLDAP, IBM Directory Server, Oracle Directory
- HR system — CSV/JSON push or pull for any HRMS
- ServiceNow — bidirectional (provisions + creates tickets for manual tasks)
- Salesforce — profile + permission set governance
- GitHub — org membership + team + repo access governance
- Generic SCIM 2.0 — any SCIM-compliant target
Custom connectors are built via the 5-step wizard using REST, LDAP, or SCIM endpoints. The wizard's live discovery pre-fills ~75% of the mapping configuration.
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: can be imported from a CSV export of your existing roles; Quick Scan can also re-derive it from current access data
- Certification history: historical audit data can be preserved as imported records; ongoing certifications restart fresh
- Workflows + policies: SoD rules are re-configured using the policy DSL; approval rules are rebuilt in the wizard
Most migrations from Omada or legacy tools take 4–8 weeks. SailPoint migrations are more complex if you've accumulated heavy customisations — we scope those individually.
In tier-3 mode, identity data was never in our control plane — it remains in your VPC. In SaaS connector mode, identity data processed by our control plane is fully exportable and will be permanently deleted on contract termination.
Configuration data (connector settings, role model, policies) is exportable at any time as JSON/CSV. Audit history is exportable in full. On contract termination, the control plane tenant is archived (not deleted) for 90 days, then permanently removed. You receive a full export before archival.