Architecture & trust rapidvalue.eu →

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:

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

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.

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.

Deployment and operations

A deployment 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 instance size a deploy is degraded rather than down, and we would rather describe it that way than call it zero-downtime.

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.

Self-hosted installations update by hand. The platform is containerised and migrations apply themselves on restart, but a fully customer-hosted deployment updates by pulling a new image. The remotely managed, signed update channel exists for the hybrid model, where the agent is updated from the 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.

Role formalisation requires a named owner and a reviewer chain. A mined proposal cannot become a live role without an owner, and the approval chain comes from the role type rather than the mining run. Role mining reads the estate and drafts the argument; a person still signs it.

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: