Veelgestelde vragen

De agent authenticeert met een ECDSA P-256-sleutelpaar: bij de eerste start genereert hij een sleutelpaar, registreert de publieke sleutel met de eenmalige bearer-token uit de registratie, en wisselt vanaf dan ondertekende, eenmalig bruikbare challenges in voor kortlevende access-tokens. Een gelekte token alleen kan geen sessie opzetten. Connector-secrets (LDAP-bindwachtwoord, AD-serviceaccount, enz.) worden lokaal opgeslagen in een agent-vault.json-bestand op de agent-host — nooit naar het controlplane gestuurd.

Voor omgevingen met hoge beveiligingseisen kan optioneel mTLS bovenop worden gelegd: de agent presenteert bij elke request een client-certificaat-fingerprint, en het controlplane valideert die vóór verwerking.

Zelf-updates zijn HMAC-geverifieerd: elke agent heeft een unieke signing key. Het controlplane berekent een per-agent HMAC over de nieuwe agent-broncode. De agent verifieert de handtekening vóór hij zichzelf overschrijft. Een niet-kloppende handtekening betekent dat de update wordt geweigerd en de agent op de huidige versie blijft.

Automatische rollback. Vóór elke zelf-update wordt de huidige agent geback-upt naar tier3_agent.py.bak. Na herstart heeft de agent 60 seconden om een "stable boot"-marker te schrijven. Crasht hij vóór het schrijven van de marker, dan detecteert de volgende start de ontbrekende marker, herstelt de back-up en voert de vorige versie opnieuw uit.

Geen actie van de operator nodig. Het herstel is volledig automatisch.

Er zijn meerdere opties, afhankelijk van je dataresidentie-eisen:

• SaaS (standaard): AWS eu-west-1, Ierland. Volledig beheerd, AVG-conforme EU-dataresidentie.
• EU Sovereign SaaS (op aanvraag): OVH of Scaleway, EU-gevestigd. Geen blootstelling aan de US Cloud Act, geen Amerikaanse rechtsmacht over je data.
• Private cloud (op aanvraag): uitgerold binnen je eigen AWS-, Azure- of OVH-account. Je data blijft in je eigen omgeving.
• On-premises (op aanvraag): draait in je eigen datacenter onder je eigen controls.

In alle gevallen blijven connector-credentials die door de tier-3 agent worden beheerd binnen je eigen netwerk en bereiken ze nooit het controlplane — de lijn draagt configuratie en resultaten, nooit secrets.

In elke connector-modus ontvangt en bewaart het controlplane het gesynkte identiteitsmodel — identities, accounts, entitlements en grants. Dat ís het product: het EU-gehoste controlplane is waar reconciliatie, risicoscoring, certificaties en audit gebeuren, en het heeft het model nodig om dat werk te doen.

Wat de tier-3 agent verandert is de custody van credentials en het netwerkbereik, niet de datastroom: connector-secrets worden lokaal op de agent geresolved en gaan nooit de lijn over — de lijn draagt configuratie en resultaten.

Dataminimalisatie ligt in jouw handen: met de attribuutselectie van de onboarding-wizard kies je, per object en per attribuut, exact wat er geïmporteerd wordt. Alles wat je wél importeert is EU-gehost, volledig exporteerbaar (AVG Art. 20) en wisbaar (Art. 17).

Alle connector-credentials (LDAP-bindwachtwoord, AD-serviceaccount, API-tokens, OAuth-clientsecrets) worden opgeslagen in agent-vault.json op de agent-host — binnen je VPC. De agent resolvet ze lokaal op het moment van uitvoering. Ze worden nooit naar het controlplane gestuurd, zelfs niet in versleutelde vorm.

De credential-CLI vergrendelt agent-vault.json (en de lokale master key) tot owner-only-rechten (chmod 600) naarmate credentials worden toegevoegd. In productie-deployments is het gebruikelijk om de master key uit een secrets manager (HashiCorp Vault, Azure Key Vault) te halen in plaats van uit een lokaal bestand.

Ja. Een POC verwerkt echte identiteitsdata in het EU-controlplane — daar gebeurt governance in elke modus — dus onze standaard-DPA geldt vanaf dag één. We tekenen ze als onderdeel van de POC-onboarding, dus het kost je geen extra doorlooptijd.

Wat de tier-3 agent wél verandert: je geeft nooit connector-credentials uit handen. Secrets blijven de hele POC in je netwerk.

DORA (Digital Operational Resilience Act) verplicht financiële entiteiten om ICT-gerelateerde risico's continu te monitoren en te beheren, inclusief toegangsrechten voor kritieke functies. Belangrijke RapidValue-capabilities die aan DORA-eisen tegemoetkomen:

• Continue reconciliatie: elke run is voorzien van een timestamp met bewijs per recht — "waarom bestaat deze toegang?"
• Functiescheiding: declaratieve cross-systeem SoD-regels met continue detectie van overtredingen — giftige combinaties eenmaal gedeclareerd, geflagd waar ze ook voorkomen
• Governance van niet-menselijke identiteiten: serviceaccounts en bots geclassificeerd in 4 lagen met eigenaarschap-tracking
• Governance van derdentoegang: identity-flows voor contractors en partners met toegangsvervaldatum
• Audit-trail: onwijzigbaar auditlog per categorie, exporteerbaar voor indiening bij de toezichthouder

De Financial Services-sectorpack levert DORA-afgestemde SoD-regels en goedkeuringsbaselines (4-ogen op high-risk), en de compliance-posture-engine scoort je omgeving out of the box tegen DORA-toegangscontroles (Art. 9).

Ja. NIS2 verplicht essentiële en belangrijke entiteiten om toegangscontrolebeleid, multifactor-authenticatie en continue monitoring van geprivilegieerde toegang te implementeren. RapidValue pakt dit aan via:

• Continue toegangscertificatie (event-gedreven, niet enkel jaarlijks)
• NHI 4-lagenclassificatie — kritieke serviceaccounts geïdentificeerd en met eigenaarschap gegoverneerd
• Blast-radius-scoring — begrijp het propagatierisico van elke gecompromitteerde identiteit
• Auditklaar bewijs per reconciliatierun — voldoet aan de eis van "gedocumenteerd toegangstoezicht"

Voor kritieke-infrastructuursectoren leveren de Public Sector- en Manufacturing-packs NIS2-afgestemde goedkeuringsbaselines, en de compliance-posture-engine scoort je omgeving out of the box tegen NIS2-controles (MFA, toegangstoezicht).

Ja. De toegangscontrole-eisen van SOX (met name Section 404 over interne controles) worden goed ondersteund:

• Functiescheidingsbeleid met geautomatiseerde detectie van overtredingen
• Toegangscertificatie-campagnes met goedkeuringssporen en timestamps
• Onwijzigbaar auditlog van alle toegangsbeslissingen en certificatie-uitkomsten
• Rolgebaseerde toegangscontrole met onderbouwde rechtvaardigingen per recht

Externe auditors waarderen doorgaans het snapshot-model per recht — ze kunnen "waarom heeft persoon X permissie Y op tijdstip Z?" opvragen en krijgen een direct antwoord, geen handmatige reconstructie.

De agent installeert in minder dan 5 minuten en de eerste connector synct binnen het eerste uur. De POC is ontworpen om je binnen 2 weken een werkende governance-omgeving te geven, inclusief eerste role mining en een eerste certificatie-campagne.

Een volledige productie-uitrol (alle connectoren, volledig rolmodel, teamtraining, sectorpack-configuratie) wordt voor een mid-market-omgeving geschat op 4–8 weken. Klassieke IGA-implementaties lopen 6–18 maanden voor dezelfde scope.

Een typische POC verloopt als volgt:

• Dag 1, ochtend: sales engineer sluit aan op een call; draait rv-poc bootstrap; agent is geïnstalleerd en gekoppeld in <30 minuten; eerste connector geonboard via de wizard
• Dag 1, middag: Quick Scan draait op de gekoppelde data; role-mining-voorstellen gegenereerd; take-home-rapport klaargemaakt voor je CISO
• Week 1–2: extra doelsystemen koppelen; volledige reconciliatie draaien; eerste certificatie-campagne configureren
• Einde week 2: POC-debrief met je team; prijsgesprek; pad naar productie afgebakend

Geen infrastructuur-setup aan jouw kant nodig, buiten het draaien van de one-line installer. De standaard-DPA wordt getekend als onderdeel van de POC-onboarding (zie Data & privacy) — het kost je geen extra doorlooptijd.

Nee. De agent is één Python-script dat op elke Linux-host draait (inclusief WSL2 op Windows). Het is een bewust lichte footprint — een kleine VM met 1 vCPU en 512MB RAM is ruim voldoende. Python 3.11+ en uitgaande HTTPS-toegang tot het controlplane zijn de enige vereisten.

Voor productie raden we een dedicated VM of container aan met persistente opslag voor de agent-statusbestanden en de vault. De meeste klanten draaien hem op een bestaande management-host in plaats van nieuwe infrastructuur te provisionen.

Engine pause is drie onafhankelijke schakelaars — sync, reconciliatie en provisioning — die elk die engine over de hele tenant stilleggen. Ze blijven behouden over herstarts heen en zijn zichtbaar voor alle admin-gebruikers.

Het is belangrijk omdat IGA-engines op schema draaien — ontdek je om 23 uur een fout in het rolmodel, dan moet je de juiste engine (of alle drie) kunnen stoppen terwijl je het onderzoekt, zonder configuratiebestanden aan te raken of processen te killen. De pause-schakelaars doen precies dat met één klik, met een optionele reden — opgeslagen bij de pauzestatus, gestempeld met wie pauzeerde en wanneer, en getoond aan elke admin tot de engine wordt hervat.

Geen enkel ander IGA-platform dat wij kennen heeft dit als first-class feature. De meeste vereisen noodtoegang tot de applicatieserver of database om een op hol geslagen provisioning-job te stoppen.

Role mining analyseert je bestaande toegangsdata om natuurlijke groeperingen te vinden — patronen van entitlements die mensen in vergelijkbare rollen delen. RapidValue draait 8 algoritmes parallel (attribuutgebaseerd, organisatorisch, functiegebaseerd, permissie-clustering, contextgebaseerd, en andere).

De deduplicatiestap lost een veelvoorkomend IGA-probleem op: dezelfde rol uit de praktijk (bv. "Finance Manager in de IT-afdeling") wordt meerdere keren voorgesteld door verschillende algoritmes uit verschillende bronsystemen. Zonder deduplicatie zou je 7 voorstellen krijgen die allemaal hetzelfde zeggen.

Onze engine detecteert overlappende voorstellen (vergelijkbare entitlement-sets, vergelijkbare ledencohorten) en voegt ze samen tot één voorstel met een merge-onderbouwing. Je beoordeelt één voorstel met volledige herkomst, niet zeven zonder context.

Niet-menselijke identiteiten (NHI's) — serviceaccounts, AI-agents, bots, IoT-devices, cloud-workloads — worden in 4 lagen geclassificeerd naar hun mate van autonomie, omdat autonomie bepaalt welke governance ze nodig hebben:

• Tier 1 · AI-Assisted: serviceaccounts en IoT-devices — lage autonomie; hergebruik standaard IGA-flows, manuele goedkeuring, jaarlijkse review
• Tier 2 · AI-Enabled: systeemaccounts — afgebakende, voorspelbare permissies; credential-rotatie en periodieke review
• Tier 3 · Autonomous: AI-agents die hun eigen beslissingen nemen — just-in-time-toegang, policy-as-code, gedragsmonitoring, kortlevende credentials
• Tier 4 · AI-to-AI: applicaties die delegeren naar andere agents — identity-federatie, delegatietokens, volledige audit-keten

Eigenaarschap-dekking (% NHI's met een aangewezen eigenaar) is vanaf dag 1 een top-line KPI in het governance-dashboard.

Het platform is z'n eigen gekoppelde systeem. Elke login-gebruiker is gekoppeld aan een identity in je directory; platformrollen (admin, auditor, helpdesk, …) zijn groepslidmaatschappen die in hetzelfde beveiligingsmodel verschijnen als elke andere toegang. Een collega uitnodigen met een rol mint een echte, gegoverneerde grant die opduikt in reconciliatie en access reviews.

Guardrails maken self-lockout onmogelijk: automatisering kan nooit de laatste actieve admin deactiveren of degraderen, en het rollidmaatschap van een actieve admin is beschermd tegen connector-gedreven intrekking — terwijl een emergency lockout van een gecompromitteerde admin nog steeds alles onmiddellijk ontneemt.

Ja — first-class. Break-glass-profielen binden in aanmerking komende mensen aan de nood-entitlements van je kritieke systemen, met dekking-tracking — welke systemen geen nood-pad hebben is zelf een KPI. Activatie is één klik en tijdgebonden (auto-vervaldatum, intrekking bij verval). Elke activatie belandt op de onwijzigbare audit-trail met critical severity, blijft zichtbaar geflagd tot er een rechtvaardiging is ingediend, en de event-review-regel spawnt een review-na-gebruik van precies wat er gebruikt is.

Reviewers delegeren hun wachtrij voor een periode (out-of-office of vast). Beslissingen die namens iemand worden genomen, krijgen zichtbaar de badge "namens" en zijn apart auditeerbaar — de goedkeuringsketen loopt nooit vast op een lege stoel, en de audit-trail verliest nooit wie er werkelijk besliste.

IVIP = Identity Visibility & Intelligence Platform. Het is de analytics- + risicolaag die in RapidValue is ingebouwd: een gematerialiseerde risicoscore per identiteit, cross-systeem SoD-detectie, detectie van slapende rechten, peer-group-outlier-detectie, en dagelijkse risicotrend-snapshots.

Het is belangrijk omdat de meeste IGA-tools vandaag governance-workflows leveren maar je zelf laten uitzoeken waar je moet focussen. IVIP beantwoordt "naar welke 5 identiteiten moet ik nu kijken?" met een deterministische score en een verklaarbare component-opbouw — geen LLM, geen black box.

Het is ook wat "observe before you govern" mogelijk maakt: houd elk systeem of object visibility-only, krijg vanaf dag één het volledige risico-oppervlak en de aanbevelingen, en zet provisioning per systeem aan wanneer de governance-waarde bewezen is.

Ja — volledig deterministisch, geen ML. De score is een gewogen som van 0-100 over 17 componenten, waaronder:

• Slapende rechten — en slapende geprivilegieerde rechten, apart gewogen
• Cross-systeem SoD-overtredingen (warning- en critical-buckets)
• Shadow access — permissies die transitief geërfd worden via geneste groepen
• Peer-group-outlier — meer toegang dan statistisch vergelijkbare collega's
• Actieve grants op een beëindigde identiteit
• Geprivilegieerde toegang zonder recente certificatie
• Niet-menselijke identiteiten zonder eigenaar
• Openstaande review-items en identity-warnings (naar severity)
• Openstaande platform-advisor-bevindingen (naar severity)
• Verouderde reconciliatie — toegang recent niet geverifieerd tegen het doelsysteem

Elke component draagt een configureerbaar gewicht bij. De opbouw is zichtbaar in de identity-drawer — je kunt altijd nagaan waarom een score is wat hij is.

Een geplande detector die entitlement-grants flagt waarvan de houder ze in N dagen niet heeft gebruikt. "Gebruik" wordt afgeleid uit usage-data-ingest-pijplijnen per doelsysteem (login-records, API-call-tellingen, last-active-timestamps).

Slapende rechten verhogen de risicoscore van de houder en verschijnen als Platform Advisor-aanbevelingen: "Trek 23 slapende rechten over 4 systemen in — ETA: 0 impact op gebruikers." Klik door om te valideren en in te trekken, per stuk of in bulk. Intrekken is altijd een expliciete admin-actie — bewust geen auto-revoke, omdat toegang wegnemen high-impact is en een menselijke beslissing verdient.

Eerste scans brengen in mid-market-omgevingen doorgaans een substantieel aandeel slapende rechten aan het licht — directe licentiebesparingen + kleiner aanvalsoppervlak.

Identiteiten worden geclusterd op afdeling + functie. De detector flagt identiteiten waarvan de toegangsset ver boven de cohort-mediaan ligt (mediaan, geen gemiddelde — één outlier kan de baseline niet meesleuren) — typisch "Bob heeft 3× de toegang van zijn peer group".

Outliers worden kandidaten voor een van drie acties: gerichte certificatie ("manager bevestigt dat de extra toegang gerechtvaardigd is"), rollidmaatschap-review ("Bobs extra toegang mapt op een rol waar hij formeel in zou moeten zitten"), of right-sizing ("Bob heeft deze toegang opgebouwd uit vorige functies — opruimen").

Deterministisch + verklaarbaar — de outlier-opbouw toont welke specifieke entitlements de afwijking veroorzaken.

Het zijn twee woorden voor één engine. Een SoD-regel is hoe je een giftige combinatie declareert: twee cross-systeem-condities — "leveranciersonderhoud in Workday" vs. "betalingsgoedkeuring in SAP" — die niemand samen zou mogen houden. De evaluator draait continu en flagt elke identiteit die beide kanten houdt, hoe ze er ook aan kwamen: via verschillende rollen, verschillende systemen, of grants die niemand bedoeld had te combineren.

Overtredingen verschijnen op drie plaatsen vanuit dezelfde ene bron: de SoD-workbench (met beide kanten benoemd per persoon), de compliance-posture-weergave (als giftige-combinatie-bevindingen), en de identity-risicoscore (gewogen naar regel-severity, critical / warning). Bewust één engine — twee parallelle detectoren zouden je twee tegenstrijdige antwoorden geven.

Audit packs zijn kant-en-klare, framework-gemapte bewijsbundels. Kies een datumbereik, klik "Generate + download", en je krijgt een ZIP met: HTML-index, databestanden per sectie (CSV/JSON), en een manifest met framework-control-identifiers.

Vier templates vandaag:

• SOX § Access Management — toegangsprovisioning, wijziging, review. Mapt op de control-doelstellingen van PCAOB AS 2201. Auditklaar, met de onderliggende framework-citatie.
• ISO 27001 Annex A.9 Access Control — registratie van gebruikerstoegang, privilege-beheer, review van toegangsrechten.
• HIPAA § 164.312 Technical Safeguards — toegangscontrole, audit-controls, integriteit, persoons-/entiteitsauthenticatie, transmissiebeveiliging. Gericht op covered entities en business associates die PHI-dragende systemen via ePHI-gates draaien.
• AVG Art. 32 Beveiliging van de verwerking — passende technische en organisatorische maatregelen om een op het risico afgestemd beveiligingsniveau te waarborgen.

Wat je krijgt is wat je auditor vraagt — niet "dat bespreken we in de scoping". Neem het mee naar de audit-kickoff.

Nieuwe connectoren landen met provisioning ingeschakeld maar elke write batch-gegate: uitgaande wijzigingen wachten op jouw expliciete goedkeuring tot je de training wheels weghaalt, per systeem. Identities, accounts en entitlements synchroniseren vanaf de eerste run, en het volledige IVIP-oppervlak (risicoscore, SoD, recon, advisor) licht meteen op.

Resultaat: een nieuw doelsysteem geonboard in minuten, en je ziet het platform je toegang ontdekken voordat er iets verandert in het doelsysteem. Eerst observeren voor je governt? Elk object kan bovendien op visibility-only worden gezet (per-object write_enabled-flag) — lees het zonder write-back te configureren.

Het maturity-pad is expliciet: koppelen (gegate) → rollen minen en policies instellen → de gate weghalen voor high-value doelsystemen (typisch AD eerst) wanneer het reconciliatie-bewijs je vertrouwen heeft verdiend.

17 productieconnectoren zijn inbegrepen:

• Microsoft Entra ID (Azure AD) — volledige Graph API-integratie
• Google Workspace — Admin SDK-directory + Drive-scan van ongestructureerde data
• Active Directory / generieke LDAP — AD, OpenLDAP, IBM/Oracle Directory
• ServiceNow — bidirectioneel (provisiont + maakt tickets aan voor handmatige taken)
• Salesforce — governance van profielen + permission sets
• Workday — HR-bron-integratie
• SAP SuccessFactors — HR-bron-integratie
• Box — map- + samenwerkingsscan (ongestructureerde data)
• AFAS · TOPdesk · Atlassian · GitHub — vendor-templates voor de NL/BE mid-market-stack
• SMB/NTFS-fileshares — agent-side scan van ongestructureerde data achter de firewall
• Generieke SCIM 2.0 — elk SCIM-conform doelsysteem (Slack, GitHub Enterprise, Atlassian, …)
• Generieke REST — elke JSON-API, incl. CSV/JSON HR-feeds
• Generieke SQL — Postgres / MySQL / MSSQL applicatiedatabases
• SFTP-CSV — platte-bestand HR-feeds over SFTP/HTTPS

Custom connectoren worden gebouwd via de begeleide wizard met REST-, LDAP- of SCIM-endpoints. De live discovery van de wizard vult het grootste deel van de mapping-configuratie vooraf in — je valideert suggesties in plaats van vanaf nul te schrijven.

De wizard-aanpak duurt doorgaans 30–90 minuten voor een standaard REST- of SCIM-doelsysteem. Je richt de wizard op het discovery-endpoint van het doelsysteem, hij geeft een mapping-suggestie terug, en je valideert ~10 velden in plaats van er 100 vanaf nul te definiëren.

Voor complexe doelsystemen (meerstaps-authenticatie, niet-standaard schema's, legacy SOAP-API's) is custom connector-ontwikkeling beschikbaar als dienst — doorgaans 3–5 dagen voor een volledig productiewaardige connector.

De complexiteit van de migratie hangt af van wat je migreert:

• Connectoren: de wizard herbouwt connector-configuraties uit live discovery — doorgaans makkelijker dan connector-XML/-configuratie migreren uit de oude tool
• Rolmodel: role mining leidt het opnieuw af uit je huidige toegangsdata — in de praktijk schoner dan de opgestapelde roldefinities van de oude tool importeren, en elk voorstel komt met bewijs
• Certificatiehistorie: bewaar de bewijs-exports van je oude tool voor de bewaartermijn; RapidValue start vanaf dag één een vers, onwijzigbaar bewijsspoor
• Workflows + policies: SoD-regels worden opnieuw gedeclareerd in de rule-editor; goedkeuringsregels worden herbouwd in de visuele builder

We schatten een migratie vanaf een bestaande tool op 4–8 weken voor een typische mid-market-omgeving. Deployments met veel opgestapelde maatwerk-aanpassingen zijn complexer — die schatten we individueel in.

Je kunt alles, altijd, zelf exporteren: een volledige per-tenant-export (AVG Art. 20) levert een machineleesbare kopie van al je data — identities, accounts, entitlements, configuratie en de volledige audit-historie — als downloadlink. Geen ticket, geen wachten op ons.

Bij beëindiging draaien we een tweestaps-offboarding: je tenant wordt eerst in een offboarding-staat gezet (er gebeurt niets nieuws, alles blijft exporteerbaar), en permanente verwijdering wordt pas uitgevoerd na een expliciete, ingetypte bevestiging — nooit als automatische achtergrondstap. Het onwijzigbare auditlog is het enige dat na verwijdering wordt bewaard, op de wettelijke bewaargrond van AVG Art. 17(3)(b). In tier-3-modus verlieten je credentials sowieso nooit je netwerk om mee te beginnen — de lokale vault van de agent is de jouwe om te vernietigen.