Laatst bijgewerkt: 16 april 2026
Vera by Fortra is een rights management-platform dat persistent encryption toepast op bestandsniveau. Elk beschermd document bevat een inline policy, een auditlog en dynamische intrekbaarheid. Vera is bedoeld voor post-exfiltratie-controle: bescherming die blijft werken nadat een bestand de organisatiegrens heeft verlaten. Primair voor CISO's en legal counsels bij Nederlandse organisaties die data delen met derden in M&A, joint ventures, leveranciersaudits of onderzoekskaders onder NIS2 en AVG.
Wat: een container die elk bestand wrapt met AES-256 encryptie, een inline policy en een auditlog. De bestandsextensie blijft leesbaar, de payload niet. Toegang wordt per open-poging gevalideerd bij de Vera-server.
Voor wie: organisaties die data buiten de eigen perimeter delen en toch willen controleren wie opent, wanneer, waar en hoe vaak. Meestal financieel, juridisch, R&D, overheid en zorg.
Waar: op elk eindpunt (Windows, macOS, mobiel, web) en op elk bestandsformaat (Office, PDF, CAD, broncode, archieven). Federeert met Azure AD, Okta en Ping. Koppelt met Titus en Boldon James voor label-gedreven wrapping.
Wanneer: bij een M&A-dataroom, due diligence, joint ventures, leveranciersaudits, vermoeden van IP-diefstal, een contract-einde met data-retour of een onverwachte uitdiensttreding.
Kostenindicatie: per beschermde gebruiker of per beschermd bestand, afhankelijk van use case. Concrete cijfers via Korper ICT.
Doorlooptijd: 30-dagen POC op een afgebakende dataset, volledige uitrol in 2 tot 4 maanden.
Vera is een digital rights management-platform dat persistent encryption toepast op individuele bestanden. De categorie heet file-level rights management of persistent DRM. Het product is in 2014 opgericht onder de naam Vera Security, in 2020 overgenomen door HelpSystems en maakt sinds de merger onderdeel uit van het Fortra-portfolio. In Nederland wordt Vera geleverd via Korper ICT en geïmplementeerd door Neo Security.
Het mechanisme is als volgt. Een gebruiker of een automatisch proces markeert een bestand voor bescherming. Vera wrapt de payload in een generieke container die de originele extensie behoudt, bijvoorbeeld factuur.pdf blijft factuur.pdf, maar de inhoud is versleuteld met AES-256. In de container zit naast de payload een inline policy-blok: wie mag openen, wanneer, waar, hoe vaak, met of zonder printrecht, met of zonder watermerk. Die policy blijft aan het bestand gekoppeld, ook buiten uw netwerk.
Bij elke open-poging opent de Vera-viewer (als standalone applicatie, plug-in of web-reader) een sessie met de Vera-policy-server. De server valideert de identiteit van de ontvanger, de status van het bestand en de actuele policy. Is alles akkoord, dan wordt een sleutel vrijgegeven voor de duur van de sessie. De ontsleuteling gebeurt lokaal, het bestand blijft versleuteld op schijf. Elke open-, print-, kopieer- of delenpoging wordt gelogd. Dat logboek is de basis van de auditfunctie.
Vera is geen classificatietool en geen DLP. Het maakt geen labels (dat doet Titus) en blokkeert geen uitgaand verkeer (dat doet Clearswift). Vera accepteert dat data de perimeter verlaat en legt de controle aan de ontvangerskant. Geen perimeterverdediging meer, wel bescherming die aan elk bestand gekoppeld blijft. Daarmee staat Vera op de post-exfiltratie-laag in de keten: nadat de eerdere lagen hun werk hebben gedaan, houdt Vera vast wat niet anders te houden is.
Primaire doelgroep: CISO's, legal counsels en enterprise architecten bij Nederlandse organisaties die structureel gevoelige data delen met partijen buiten de eigen tenant. Financiële dienstverleners die due diligence doen op overnamekandidaten. Advocatenkantoren die casusdossiers delen met cliënten. Onderzoeksorganisaties die R&D-data uitwisselen met academische partners. Biotech en farma die studie-resultaten delen met regulators. Industriële organisaties die CAD-ontwerpen delen met toeleveranciers. In al deze gevallen is de perimeter niet de juiste eenheid van beheer; het individuele bestand is het.
Secundaire doelgroep: compliance officers en functionarissen voor gegevensbescherming die moeten aantonen dat technische maatregelen conform AVG artikel 32 ook buiten de eigen systemen blijven werken. Artikel 32 eist passende beveiliging naar de stand van de techniek, inclusief versleuteling waar passend. Voor data die contractueel bij derden terechtkomt is wrapping met inline policy de technische invulling van die eis. Een verwerkersovereenkomst op papier is noodzakelijk, geen sluitend technisch bewijs. Vera levert dat laatste.
Vera past minder goed bij drie typen organisaties. Bij organisaties die hun data vrijwel nooit extern delen is de meerwaarde laag, want een interne tenant dekt ISO 27001 Annex A 8.12 (data leakage prevention) al grotendeels af. Bij zeer kleine organisaties onder 100 FTE is de operationele overhead van een policy-server en een dedicated administrator disproportioneel. Bij organisaties waarvan de ontvangende partijen geen enkele bereidheid hebben om een viewer te installeren en ook geen browser-based opening accepteren, ontstaat adoptiewrijving die de businesscase onderuithaalt. Die laatste situatie is zeldzaam; externe partijen in gereguleerde sectoren accepteren doorgaans een web-reader.
Sectoren waarin Vera in Nederland het vaakst voorkomt: banken en verzekeraars onder NIS2-reikwijdte, overheidsorganisaties met inlichtingen- of opsporingsdossiers, academische ziekenhuizen met onderzoeksdata, de maakindustrie met kritiek intellectueel eigendom en juridische dienstverleners met grote transactiedossiers. De gemene deler is dat elk gedeeld bestand een latent risico draagt dat pas op het moment van audit of incident zichtbaar wordt. Vera maakt dat risico beheersbaar aan de ontvangerskant.
Vera draait op drie logische lagen. De policy-server host de policy-definities, identity-integraties, de key management en het auditlog. In Nederlandse omgevingen staat deze server meestal in een datacenter in Amsterdam of Eindhoven, of in een private regio van een hyperscaler onder Europese jurisdictie. De wrap-component draait op de endpoints waar bestanden worden beschermd: desktops, laptops, een dedicated server in een file-workflow of een API-endpoint voor programmatische wrapping vanuit andere applicaties. De viewer-component draait bij de ontvanger, als desktop-applicatie, als Office-plug-in of als web-reader waarvoor geen installatie nodig is.
Integratiepunten die wij in Nederlandse uitrollen het vaakst configureren. Azure AD of Okta voor identity-federatie, inclusief Conditional Access-regels die blokkeren op apparaatstatus of geografie. Microsoft Exchange en Gmail voor inline-wrapping van uitgaande attachments op basis van ontvangerdomein of classificatielabel. SharePoint en OneDrive voor automatische wrapping bij uploaden in een beveiligde bibliotheek. Box, Dropbox en Egnyte voor dezelfde functie in third-party clouds. GoAnywhere MFT en FileCloud voor gereguleerde bestandsuitwisseling. Splunk en Microsoft Sentinel voor auditlog-ingest: elke open-, print- en kopieergebeurtenis wordt als event doorgezet en is bruikbaar in SIEM-correlatie.
Label-handoff is een specifieke categorie integratie. Titus plaatst bij creatie een label in de metadata van een document. Een policy-engine leest dat label en triggert de Vera-wrap voor labels boven een drempelwaarde. Hetzelfde gebeurt met labels die Boldon James bij discovery op bestaande bestanden plakt. De gebruiker kiest het label, het systeem kiest de bescherming. Dat is de scheiding die bij audit overeind blijft: wie labelt en wie beschermt zijn twee rollen met een geautomatiseerde brug ertussen.
Het platform ondersteunt federatie met vrijwel elke SAML- of OIDC-provider. Dat is de reden dat Vera werkt voor cross-tenant delen waar Microsoft IRM struikelt. Een ontvanger bij een externe advocaat hoeft geen gastaccount in uw tenant. Hij logt in met zijn eigen identiteit. Uw policy bepaalt dat die identiteit voorkomt op de whitelist en dat zijn organisatie aan de contractuele eisen voldoet. De sleutel komt vrij, het bestand opent. Breekt de samenwerking, dan wordt de whitelist aangepast en sluit het bestand vanzelf.
Zeven concrete trigger events komen in onze intake vrijwel zonder uitzondering terug.
M&A en due diligence. De verkopende partij opent een dataroom met financiële rapportages, contracten en HR-data. Kopende partijen en hun adviseurs moeten inzien, niet exporteren. Vera wrapt de dataroom. Na closing of afketsen verdwijnt de toegang zonder dat er een terughalingsproces hoeft te worden georganiseerd. Dat werkt ook als kopers ongeautoriseerd gekopieerd hebben.
Joint venture. Twee partijen zetten een gezamenlijke entiteit op en delen IP voor de duur van de samenwerking. Beide partijen willen hun eigen data terug op het moment dat de JV eindigt. Vera levert dat via tijdsgebonden policies waarin rechten automatisch vervallen op contractueel afgesproken einddatum.
Leveranciersaudit. Een toezichthouder of externe auditor vraagt inzage in broncode, configuratiebestanden of systeemlogs. U moet delen, maar het risico dat deze data na de audit bij derden blijft is reeel. Vera beperkt toegang tot specifieke auditor-identiteiten, met expiry na het auditvenster.
Derogation after breach. Na een datalek publiceert de Autoriteit Persoonsgegevens een verzoek om technische onderzoeksgegevens aan te leveren. Die gegevens zijn zelf gevoelig: ze beschrijven kwetsbaarheden, compromitteerde systemen en indicators of compromise. Wrapping met policy-beperking tot de onderzoeksgroep is de minimaal passende maatregel onder AVG artikel 32.
Onverwachte uitdiensttreding. Een senior engineer of partner vertrekt abrupt. In de weken ervoor heeft hij bestanden gedownload, gedeeld of naar privecloud gesynchroniseerd. Zijn de bestanden met Vera gewrapped, dan stopt de toegang op het moment dat u zijn identiteit uit de policy verwijdert. Zonder wrap is het gevecht verloren voordat het begint.
Verdenking van IP-diefstal. Monitoring toont dat een medewerker ongebruikelijke hoeveelheden vertrouwelijke data kopieert. U wilt het onderzoek stil houden en tegelijk de schade beperken. Dynamische intrekbaarheid op de specifieke identiteit of apparaat blokkeert verdere opening zonder dat de medewerker direct gealerteerd wordt.
Contract-einde met data-retour. Een uitbesteding eindigt en u moet aantoonbaar kunnen garanderen dat de leverancier geen bruikbare kopie meer heeft. Vera maakt van die garantie een technische afdwinging in plaats van een contractuele belofte: wat bij de leverancier staat is vanaf vervaldatum onbruikbaar. Audits van het Nationaal Cyber Security Centrum en publicaties van ENISA beschrijven third-party-risico als een van de hardnekkigste gebieden. File-level rights management is een van de weinige maatregelen die dit risico structureel adresseert.
Eerlijk antwoord vooraf. Microsoft levert twee producten die dicht bij Vera's probleemgebied komen. Veel klanten gebruiken die al. Wij gaan de verschillen niet wegpoetsen.
Microsoft Purview Message Encryption (OME). Dit is email-only. Het versleutelt uitgaande berichten zodat externe ontvangers die openen via Outlook, een OME-portaal of een wegwerplink. Het is prima voor incidenteel versleuteld mailen en voor afgedwongen encryptie bij specifieke ontvangerdomeinen. Het dekt geen bijlagen buiten de mailflow, geen bestanden die via andere kanalen worden gedeeld, en het is minder granulair in wie wat mag. Geen watermarking per open-event, geen intrekking na download, geen cross-kanaal zicht.
Microsoft IRM (onderdeel van Azure RMS, nu grotendeels opgegaan in Purview Information Protection). IRM vergrendelt rechten binnen Office-bestandsformaten. Het werkt sterk binnen Word, Excel, PowerPoint en Outlook. Buiten Office wordt het snel wankel. Een PDF is mogelijk mits u de Microsoft PDF-stack gebruikt. CAD, broncode, archieven, niet-Office-viewers en mobiele apps buiten de officiele lijn breken de keten. Cross-tenant delen is omslachtig: gastaccounts in uw tenant, B2B-federaties met beperkingen, of een tussenroute via OME met alle beperkingen van dien.
Vera. Vera is bestandsformaat-onafhankelijk: elk bestand krijgt dezelfde containerbehandeling ongeacht extensie of applicatie. Cross-tenant delen is de standaardwerking: een externe identiteit met zijn eigen identity provider opent direct. Dynamische intrekbaarheid werkt na elke open-poging, niet alleen op volgende download. Watermarking-on-open en printrechten zijn policy-attributen, geen add-on. Het auditlog is granulair op open-event-niveau, bruikbaar in forensisch onderzoek.
De keuze is niet binair. In de meeste Nederlandse omgevingen draaien OME en Purview Information Protection voor interne en lichte externe flows, en wordt Vera ingezet voor de harde categorieen: dataroom, audit, IP, joint venture, onverwachte uitdiensttreding. Dezelfde classificatieketen van Titus en Boldon James bedient beide mechanismen zonder dubbele labels.
Alternatieven buiten Microsoft die ook genoemd worden: Seclore, NextLabs en Virtru. Seclore is functioneel de dichtstbijzijnde vergelijking met Vera en wordt in Nederland bij enkele overheids- en defensiegerelateerde omgevingen ingezet; de servicable leveranciersstructuur in Nederland is beperkter. NextLabs richt zich op beleidsgedreven attribuut-gebaseerde toegang en is sterk in SAP-gekoppelde omgevingen. Virtru is goed voor email-gerichte use cases maar minder voor bredere file-flows. Voor Nederlandse enterprise-klanten met directe implementatiesteun in het Nederlands en een serviceketen die aansluit op Titus, Boldon James en Clearswift, is Vera de meest gangbare keuze.
De architectuur in prose. De container is het fundament. Bij wrapping gebeurt het volgende. De oorspronkelijke extensie blijft zichtbaar (factuur.pdf, bouwtekening.dwg, broncode.zip), maar de payload wordt vervangen door een encrypted blob in AES-256-GCM. Direct achter de blob zit een inline metadata-blok met policy-ID, server-endpoint, key-fingerprint en optionele offline-token. De container is door een bestandssysteem-viewer zichtbaar, maar zonder Vera-viewer of web-reader is de inhoud niet te openen.
De policy-engine aan de serverkant is de kern. Een policy bestaat uit vier attribuutfamilies: wie (identity of groep), wanneer (tijdsvenster, expiry, Conditional Access-status), waar (geografische beperking op basis van IP of claims) en hoe vaak (aantal open-events, printlimiet, download-limiet). Policies worden bij opbouw aan het bestand gekoppeld via de policy-ID en kunnen daarna aangepast worden zonder het bestand opnieuw te raken. Dat is de technische basis van dynamic revocation: de volgende open-poging raadpleegt de actuele policy, niet de policy-snapshot op het moment van wrapping.
Bij elke open-poging voert de viewer een policy-check uit tegen de Vera-server. Is de policy actief, dan komt een sessie-sleutel vrij, tegelijk met een print-, kopieer- en watermerk-attribuutset. De viewer rendert het bestand en voegt een watermerk-overlay toe met gebruikersnaam, tijdstip en document-ID. Dat watermerk is zichtbaar op scherm en in prints. Fysieke foto's van het scherm blijven mogelijk, maar ze maken de bron van het lek traceerbaar. Dat is een bewust ontwerp: perfect onbreekbare bescherming bestaat niet, wel attribueerbare bescherming.
Offline-access is een policy-attribuut, geen standaardgedrag. U stelt per classificatielabel of per workflow in hoe lang een sessie-token lokaal gecachet mag worden. Van 0 dagen (altijd online) tot 30 dagen (veldpersoneel). Na expiry is een nieuwe online verificatie vereist. De cache wordt vrijwel altijd conservatief ingesteld, omdat offline-access drift de grootste verzwakking van persistent rights management vormt. Een te ruime offline-window betekent dat een verbroken identity-binding weken kan duren voordat hij effectief wordt.
Het auditlog is waar de audit-waarde vandaan komt. Elke open-poging, geslaagd of geweigerd, wordt gelogd met timestamp, identity, IP, apparaat, beleid en uitkomst. Prints en kopieerpogingen idem. De log is schrijfbaar als stream naar Splunk of Microsoft Sentinel via een SIEM-audit-feed. Voor de forensisch onderzoeker is dat de primaire bron: niet of een bestand gelekt is, maar wie heeft geprobeerd toegang te krijgen en wat hij ermee heeft gedaan.
Identity-federatie verdient aparte aandacht. Vera federeert met Azure AD via SAML of OIDC en neemt Conditional Access-claims over. Als uw Azure AD een ontvanger blokkeert op basis van onbekende locatie, weigert Vera al voor er een sleutel wordt aangemaakt. Dezelfde flow werkt met Okta en Ping. Voor interne gebruikers is de ervaring identiek aan hun Microsoft-login. Voor externe ontvangers werkt het via hun eigen identity provider, zonder dat u gastaccounts beheert.
DLP label-handoff maakt de keten rond. Titus of Boldon James plaatst een classificatielabel in de metadata of in een centrale catalog. Een policy-engine (Vera's eigen of een externe workflow-engine zoals GoAnywhere) leest dat label bij opslaan, delen of export en stuurt bestanden boven de drempel automatisch door de wrap. De gebruiker merkt dat niet. Bij opening bij de ontvangerskant verschijnt de Vera-viewer, federeert de identiteit en opent mits toegestaan. De scheiding tussen label-authoriteit (Titus of Boldon James), policy-engine (Vera of workflow-laag) en handhaving (Vera-server en viewer) staat bij audits overeind.
Failure modes die wij in de praktijk zien. Ten eerste offline-access drift. Een ruimhartig ingestelde offline-cache van 30 dagen betekent dat een verbroken samenwerking een maand lang gaten vertoont. Remedie: offline-window gedifferentieerd per labelniveau, strenge logging, en periodieke dwangverificatie bij hoog-risico workflows. Ten tweede mobiele viewer-compatibiliteit. Sommige mobiele apps vervangen de Vera-viewer door hun eigen renderer, waardoor het bestand niet opent. Remedie: gecontroleerde MDM-uitrol met Vera-viewer als primaire Office-alternatief op gereguleerde mobiele vloten. Ten derde performance bij grote CAD-bestanden. Een 2 GB Inventor-bestand wrappen en unwrappen duurt merkbaar langer dan een Word-document. Remedie: asynchrone wrapping in de workflow, gebruikersverwachting sturen, en bij zeer grote bestanden een streamingwrapper overwegen waar beschikbaar. Ten vierde key rotation complexity. Policy- en key-hierarchieen moeten periodiek worden geroteerd; slecht doorgedachte rotatie bij een actieve dataset kan batches bestanden tijdelijk ontoegankelijk maken. Remedie: rotatieplan vooraf, rolling rotation per labelgroep, en testprocedure op een non-productie tenant.
De doorlooptijd van een typische uitrol. Week 1 tot 2: architectuurontwerp, policy-definitie voor twee of drie prioritaire workflows (meestal dataroom, leveranciersaudit en interne IP-bescherming). Week 3 tot 4: POC met 20 tot 50 gebruikers op een afgebakende dataset, inclusief federatie met Azure AD en viewer-uitrol op twee mobiele platformen. Maand 2 tot 3: uitbreiding naar alle geplande workflows, label-handoff vanuit Titus of Boldon James, SIEM-audit-feed naar Splunk of Sentinel. Maand 3 tot 4: operationalisering, runbooks voor intrekking en key rotation, forensische procedures, en overdracht aan de beheerorganisatie. Voor een bredere portfolio-context verwijzen wij naar de oplossingenpagina. Voor de regulatoire motivatie achter deze keten zie de deep-dive waarom-pagina. Wie direct wil starten met een POC vindt het contactformulier op de contactpagina of kan terug naar het overzicht.
Microsoft IRM vergrendelt rechten binnen Office-bestandsformaten en vertrouwt op een Office-viewer die het RMS-protocol spreekt. Buiten Office breekt de keten: PDF, CAD, broncode of archiefformaten vallen buiten bereik. Vera werkt op elk bestandsformaat en wrapt de payload in een generieke container met inline policy. Daarbij blijft de toegangscontrole actief ongeacht viewer, tenant of host.
Ja. Vera is bestandsformaat-onafhankelijk en identiteit-agnostisch. U kunt federeren met Azure AD, Okta, Ping of een SAML-provider naar keuze. Een ontvanger bij een externe partij zonder uw tenant kan met zijn eigen identiteit openen, mits uw policy dat toestaat. Cross-tenant is de standaardwerking, geen randgeval.
Ja. Dat is de kernfunctie. De container checkt bij elke open-poging de actuele policy op de Vera-server. Trekt u rechten in, dan weigert de container vanaf dat moment ontsleuteling, ook op kopieen die al bij derden staan. Voor offline-toegang geldt een vooraf ingestelde expiry waarna opnieuw verificatie nodig is.
Beperkt. Een ontvanger kan een token cachen voor een configureerbaar venster, meestal 1 tot 30 dagen. Binnen dat venster opent het bestand zonder netwerk. Na expiry is een heropening alleen mogelijk met verse verificatie. Voor hoog-risico data beperkt u offline-access tot nul dagen; voor velddienst accepteert u een langere cache met audit-follow-up.
Het bestand blijft versleuteld. De nieuwe ontvanger ziet de container maar kan niet openen zonder dat zijn identiteit in de policy voorkomt. Doorsturen is geen lek, het is een verificatiepoging die wordt gelogd. Het auditlog toont welke identiteit heeft geprobeerd te openen en of de poging is toegestaan of geweigerd.
Via SAML of OpenID Connect federatie. Vera delegeert de authenticatie naar uw Azure AD, neemt de claims over en past die toe op de policy. Conditional Access-regels uit Azure AD blijven gelden: als een ontvanger op een onbekend apparaat of land zit, kan Azure AD blokkeren voordat Vera de sleutel vrijgeeft. Dezelfde flow werkt met Okta en Ping.
Ja. Titus plaatst het label bij creatie in de metadata. Een policy-trigger pakt documenten met label vertrouwelijk of hoger en stuurt die automatisch door de Vera-wrap. De gebruiker kiest het label, het systeem kiest de bescherming. Dezelfde brug bestaat met Boldon James voor documenten die via discovery-scans boven komen drijven.
Due diligence. De verkopende partij zet een dataroom klaar met tienduizenden bestanden die de koper en zijn adviseurs moeten inzien zonder dat er na de deal kopieen blijven rondslingeren. Vera wrapt de dataroom. Adviseurs openen binnen hun eigen tenant. Na closing of afketsen trekt u de rechten in, waarna elk gekopieerd bestand bij de ontvanger onbruikbaar wordt.
Regulatoire bronnen: AVG 2016/679 artikel 32, NIS2 2022/2555, ISO/IEC 27001:2022 Annex A 8.12.