What we don't claim
The published register: how the product refuses to invent numbers, the assurances we do not hold, and the functional limitations we would rather hand you than let you discover.
Most of this would normally surface in week three of a proof of concept, or in a partner's private evaluation notes. It is here because a limitation you discover yourself costs more than the same limitation handed to you on day one — and because a vendor who publishes its edges is easier to check than one who does not. Nothing below is a roadmap. It describes the product as it is.
1. "Not measurable" is an answer
A percentage is a claim, and a claim needs a denominator. Where the platform cannot establish one it says so, rather than publishing a number it cannot defend. The test is narrow enough to state outright: can the data model positively record the negative? If it can, an extreme is earned. If an absent row is indistinguishable from "we never looked", the answer is unknown.
Compliance controls. The posture engine publishes named controls — a subset of ISO 27001:2022 Annex A.5/A.8, DORA Art. 9 and 28, SOC 2 CC6 and NIS2 Art. 21 — each scored from live data. A control whose denominator does not exist is reported as not measurable, with the reason spelled out ("no active certification rule targets entitlement grants, so no grant is in scope of an access review"), and it is excluded from the framework's score rather than averaged in as a fabricated 0%. If nothing in a framework is measurable, the framework publishes no overall figure at all: "ISO 27001: 0%" on a fresh tenant is the same invention as a vacuous 100%, in the other direction.
One measurement can legitimately evidence controls in several frameworks — access-review recency speaks to ISO A.5.18, SOC 2 CC6.1 and DORA Art. 9(2)(a) alike. Where it does, every affected row says so in as many words: one measurement evidencing three controls, not three independent corroborations.
Multi-factor authentication. MFA registration is tri-state, not boolean. A connector that reports the state gives us registered or not registered; a connector that does not report it gives us unknown, and unknown is never rounded down. Coverage is computed over the known population only, and where nothing reports MFA the control reads not measurable and names what would evidence it — rather than describing a fleet of unprotected accounts we simply cannot see.
Dormancy. A grant is a dormancy candidate only on a system that can observe activity and has actually done so: the connector's engine must support usage data, and its ingest cycle must have completed at least once. Anywhere else, "last used: never" means "we do not track this system", not "nobody has used it". Capability alone is not evidence.
The consequence is the part customers notice: on a young tenant you will see blanks and "not measurable" where another tool shows green. That is the design — a gap you can act on beats a tick you cannot defend.
The same rule runs through the product. Reconciliation reports drift between expected and actual access instead of asserting a compliance figure; the read/write parity detector refuses to auto-fix a mismatch it cannot resolve without guessing; the unstructured-data lens counts an unresolvable external reader as external, because "we do not know who this is" is the honest answer.
2. Assurances we do not hold
No certification. RapidValue holds no SOC 2 report, no ISO 27001 certificate and no SOX attestation. That is a sequencing decision rather than an oversight: certification is a recurring cost we intend to carry once revenue covers it, and buying the certificate sooner would come out of the budget that builds the product. We would rather say so than imply a programme that is not running.
Two things follow:
- The posture engine scores your estate against control sets. It is not an audit opinion about us, and not one about you either. An evidence pack is evidence; the opinion stays your auditor's.
- The frameworks above are an explicit, named subset of controls — the access-control articles an IGA platform can genuinely evidence. Full coverage is not claimed, and what we do not measure is absent rather than assumed passing: SOC 2 CC6.4 (physical access) is not covered because nothing here measures it. Where a control is evidenced by a proxy rather than head-on, the row names the computation behind it, so you can judge the fit instead of trusting the label.
No public status page. With our current number of customers it would be a dashboard nobody reads, and an unwatched status page is worse than none. If something is wrong on our side you hear it from us directly. When that stops being the better channel, we will say so.
No external attestation of the evidence scheme. The signing and verification design has not been reviewed by a third party. What exists instead is verification you perform yourself: an evidence pack carries a signed manifest, and the verification script is standalone and dependency-free — it imports nothing from the platform and needs no database and no credentials. It also refuses to run without a public key supplied separately, because a key travelling inside the artefact it verifies proves nothing. A weaker claim than "audited", and a more checkable one.
3. Functional limitations
Each entry says what the product does not do, and what happens instead.
Connectors and protocols
SOAP / WS-* is not implemented. It appears in the connector catalogue as a declared, unavailable protocol; there is no runtime engine behind it, and the wizard will not let you select it. Legacy systems are reached over REST, SCIM, SQL or a flat-file export via SFTP.
Box and on-premises file shares (SMB/NTFS) are read-only. They scan folders, permissions and shared links for the unstructured-data lens, and sync users and groups for identity resolution. They do not provision, and both declare that inability rather than advertising a target that would fail on the first real grant.
Per-connector TLS options apply to the HTTP-based engines. The tenant certificate store and the skip-verify escape hatch are honoured by the generic REST and SCIM engines in all three execution modes. The vendor-SDK connectors (Entra, Google Workspace, ServiceNow, Salesforce, Box) do not read them — the control is hidden rather than shown-and-ignored — so a self-hosted instance of one of those products is not a supported target.
The non-human credential register covers Entra and Google Workspace. It holds references, dates and display hints, never secret material. AWS and GitHub credentials are not inventoried. Service-account keys held in Google Cloud sit outside the Workspace connector's reach entirely, so their expiry is not monitored here; within Workspace the register covers application-specific passwords and deliberately excludes OAuth grants and domain-wide-delegation clients, which carry no expiry date — listing them would manufacture findings nobody could act on.
Provisioning, gating and the API
There is no universal data-authority matrix. Imported objects and governed edges retain source provenance, and connector mappings, correlation keys and write capabilities declare authority at their own boundaries. One central policy that resolves every property conflict across every object and identity type is not shipped. See Source provenance and data authority.
Batch approval covers grants and revocations, not attribute writes. On a connector that requires batch approval, a grant or revocation is held as a pending claim and the target is written only after an administrator approves the batch. Identity-attribute propagation is a third write path outside that gate; it is governed separately, per connector, by its own drift policy — write it, raise it for review, or leave it alone. Two mechanisms, and the drift policy is the one that decides.
Privileged access is PAM-lite, and we use that word. Just-in-time elevation, scheduled elevation from an approved request, and break-glass with a mandatory reason are governed flows whose evidence outlives the session. There is no session recording, no credential checkout or rotation for target systems, and no privileged-session proxy. If you need those, this sits alongside a PAM product rather than replacing one.
Lifecycle coupling watches all three phases, with one honest gap. A rule tying an entitlement's lifecycle to a business record's stands behind a record beginning (seeds a governed access proposal), a record's naming or description changing (flags the linked entitlement for review, the same day via the event nudge), and a record ending (proposes a deprecation plan). The gap: an edge whose naming came from free text rather than a declared pattern has no tracked baseline, so a rename on that specific record cannot be flagged as drift — the platform marks that edge "not tracked" rather than showing a silent, indistinguishable "nothing changed". None of the three writes access: every one is a proposal a person approves.
The machine API reads broadly and writes narrowly. Its scope grammar declares twenty scopes; nine are issuable — seven resource reads, plus writing an identity and starting an onboarding. The rest have no endpoint enforcing them, and rather than hand out a scope that authenticates nowhere the platform refuses to issue it. A scoped credential can read your governance data and push identities in from an HR feed or integration platform; it does not drive the other write operations, and it tells you that when you create it rather than when you call it.
Reporting is live, but not one universal canvas. Reports open as reader-scoped live views and reuse the same evaluator for rows and exports. The universal live-configuration rail and summary mode are not shipped across every report. Delivery history is evidence per run, not an exactly-once messaging guarantee.
Deployment and operations
Scaleway Amsterdam is the decided European default, not yet a production-HA claim. The compatibility lab has proved the application server, private PostgreSQL 16, migration replay, private registry, object storage and DNS. It has not yet completed the secrets, CI/CD, HTTPS, monitoring, backup/restore, rollback and staging gates required for a supported production environment. See Hosting, regions and deployment status.
Customer-managed cloud and on-premises control planes are not standard offerings today. They are future enterprise delivery models with separate pricing, implementation and support responsibilities. The supported Tier-3 agent is not evidence that the whole control plane is generally available for self-hosting.
An EU region is not a blanket legal guarantee. We can identify the provider, selected region and relevant data flows. Those facts do not create immunity from foreign law or prove compliance with every customer's regulatory framework.
The current AWS deployment path costs roughly a minute of API errors. Services are recreated in dependency order, so the web tier keeps serving and the interface stays up behind a reconnecting indicator with automatic retries — but calls in flight against the API can fail while the backend restarts and applies migrations. A blue-green swap needs about twice the backend's memory; at the current AWS instance size a deploy is degraded rather than down. This is an AWS runbook fact, not an availability promise for another provider.
There is no agent high-availability grouping. A connector binds to one tier-3 agent. Replacing a dead or retiring agent is an explicit operation that re-binds its connectors and re-queues their pending work; agents do not pool, fail over, or share a queue. The interfaces carry the shape a group would take and reject any value in it, because a shape is not a capability.
The future self-hosted update path is not a managed-SaaS guarantee. The platform is containerised and migrations apply on restart, but a future customer-hosted control plane would require an explicit image, rollback and support process. The remotely managed, signed update channel described today is for the supported Tier-3 agent, not for a generally available self-hosted control plane.
SAML request signing is off unless a keypair is provisioned. The signature the trust boundary rests on is the identity provider's on the assertion, and that is always verified against the certificate stored for your tenant. Our own signing of the outbound authentication request is a separate, additional control that activates only where a signing keypair is configured for the deployment; without one, requests go out unsigned.
Things we deliberately do not automate
Not gaps we are working around — positions.
Segregation-of-duties conflicts are not auto-resolved. The platform detects a toxic combination and can block the conflicting side, with or without a time-boxed exception path. It will not choose which half to revoke: that is a business decision about which job someone is doing, and a tool that guesses will eventually guess wrong and quietly break someone's work.
The onboarding processes refuse to finish without an accountable owner. Role mining formalising a proposal, entitlement onboarding and application onboarding all reject a submission that names no owner — and the refusal is the server's, not a greyed-out button, so it holds for any client. This is a gate on those three processes, not on the catalog: an application created directly, or an entitlement that arrives through a target sync, can still exist without an owner, which is what the unowned-object finding in the Advisor and the ownership coverage figure exist to surface. For role mining the approval chain comes from the role type rather than the mining run; for entitlement onboarding the reviewer chain is resolved through ownership; for application onboarding the default approver is the owner of the directory that fronts the application. Mining reads the estate and drafts the argument; a person still signs it, and a person still owns the result.
Risk scores are an explainable weighted sum, not a model. Every component, its weight per unit and its cap are configurable and visible, and the breakdown an administrator sees is arithmetic they can reproduce by hand against their own configuration. There is no machine-learned or behavioural score, and no anomaly baseline over activity outside the platform. A number an auditor cannot recompute is not evidence.
If something you need is missing here, it is far more likely an omission than a secret. Ask, and we will tell you where the edge actually is.
Further reading:
- Tier-3 hybrid architecture — deployment modes, and what never crosses the wire
- Reconciliation engine — expected versus actual, and what drift means
- Read/write parity — the honesty posture applied to configuration
- Unstructured data visibility — what the file-share lens can and cannot see
- Governing API access — scoped machine credentials and how they are enforced