Last updated: April 16, 2026
Vera by Fortra is a rights management platform that applies persistent encryption at the file level. Every protected document travels with inline policy, audit log and dynamic revocability. Vera is built for post-exfiltration control: protection that keeps working after a file has left the organizational boundary. Primary audience: CISOs and legal counsels at Dutch organizations that share data with third parties in M&A, joint ventures, vendor audits or investigation workflows under NIS2 and GDPR.
What: a container that wraps every file with AES-256 encryption, inline policy and audit log. The file extension stays readable, the payload does not. Access is validated per open attempt against the Vera server.
For whom: organizations that share data outside their own perimeter and still want to control who opens it, when, where and how often. Typically financial, legal, R&D, government and healthcare.
Where: on every endpoint (Windows, macOS, mobile, web) and on every file format (Office, PDF, CAD, source code, archives). Federates with Azure AD, Okta and Ping. Couples with Titus and Boldon James for label-driven wrapping.
When: for M&A data rooms, due diligence, joint ventures, vendor audits, suspicion of IP theft, contract end with data return or unexpected employee departure.
Cost indication: per protected user or per protected file, depending on the use case. Concrete figures via Korper ICT.
Lead time: 30-day POC on a scoped dataset, full rollout in 2 to 4 months.
Vera is a digital rights management platform that applies persistent encryption to individual files. The category is called file-level rights management or persistent DRM. The product was founded in 2014 as Vera Security, acquired by HelpSystems in 2020, and has been part of the Fortra portfolio since the merger. In the Netherlands Vera is delivered via Korper ICT and implemented by Neo Security.
The mechanism works as follows. A user or an automated process marks a file for protection. Vera wraps the payload in a generic container that keeps the original extension, for example invoice.pdf stays invoice.pdf, but the content is encrypted with AES-256. Alongside the payload the container carries an inline policy block: who may open, when, where, how often, with or without print rights, with or without watermark. The file travels with this policy, also outside your network.
At every open attempt the Vera viewer (as a standalone application, plug-in or web reader) opens a session with the Vera policy server. The server validates the identity of the recipient, the status of the file and the current policy. If everything checks out, a key is released for the duration of the session. Decryption happens locally, the file stays encrypted on disk. Every open, print, copy or share attempt is logged. That log is the foundation of the audit function.
Vera is not a classification tool and not a DLP. It does not create labels (that is what Titus does) and it does not block outbound traffic (that is what Clearswift does). Vera accepts that data leaves the perimeter and places control on the recipient side. No perimeter defense, just protection that travels with every file. That puts Vera on the post-exfiltration layer in the chain: after the earlier layers have done their work, Vera holds on to what cannot be held any other way.
Primary audience: CISOs, legal counsels and enterprise architects at Dutch organizations that routinely share sensitive data with parties outside their own tenant. Financial services firms running due diligence on acquisition targets. Law firms sharing case files with clients. Research organizations exchanging R&D data with academic partners. Biotech and pharma sharing study results with regulators. Industrial organizations sharing CAD designs with suppliers. In each of these cases the perimeter is not the correct unit of control; the individual file is.
Secondary audience: compliance officers and data protection officers who have to demonstrate that technical measures conform to GDPR article 32 keep working outside their own systems. Article 32 requires appropriate security according to the state of the art, including encryption where appropriate. For data that ends up contractually at third parties, wrapping with inline policy is the technical implementation of that requirement. A paper data processing agreement is necessary, not conclusive technical proof. Vera supplies the latter.
Vera fits less well with three types of organizations. For organizations that almost never share data externally the added value is low, because an internal tenant already covers ISO 27001 Annex A 8.12 (data leakage prevention) to a large extent. For very small organizations under 100 FTE the operational overhead of a policy server and a dedicated administrator is disproportionate. For organizations whose receiving parties have no willingness to install a viewer and also refuse a browser-based opening, adoption friction emerges that undermines the business case. That last situation is rare; external parties in regulated sectors typically accept a web reader.
Sectors where Vera is most common in the Netherlands: banks and insurers inside NIS2 scope, government organizations with intelligence or investigation files, academic hospitals with research data, manufacturing with critical intellectual property, and legal services with large transaction dossiers. The common denominator is that every shared file carries a latent risk that only becomes visible at the moment of audit or incident. Vera makes that risk manageable on the recipient side.
Vera runs on three logical layers. The policy server hosts the policy definitions, identity integrations, key management and audit log. In Dutch deployments this server typically sits in a data center in Amsterdam or Eindhoven, or in a private region of a hyperscaler under European jurisdiction. The wrap component runs on the endpoints where files are protected: desktops, laptops, a dedicated server in a file workflow or an API endpoint for programmatic wrapping from other applications. The viewer component runs at the recipient, as a desktop application, as an Office plug-in or as a web reader that requires no installation.
Integration points we most often configure in Dutch rollouts. Azure AD or Okta for identity federation, including Conditional Access rules that block on device status or geography. Microsoft Exchange and Gmail for inline wrapping of outgoing attachments based on recipient domain or classification label. SharePoint and OneDrive for automatic wrapping on upload to a protected library. Box, Dropbox and Egnyte for the same function in third-party clouds. GoAnywhere MFT and FileCloud for regulated file exchange. Splunk and Microsoft Sentinel for audit log ingest: every open, print and copy event is forwarded as an event and is usable in SIEM correlation.
Label handoff is a specific integration category. Titus places a label in a document's metadata at creation. A policy engine reads that label and triggers the Vera wrap for labels above a threshold. The same happens with labels that Boldon James attaches to existing files during discovery. The user picks the label, the system picks the protection. That is the separation that holds up in audit: who labels and who protects are two roles with an automated bridge between them.
The platform supports federation with practically every SAML or OIDC provider. That is why Vera works for cross-tenant sharing where Microsoft IRM stumbles. A recipient at an external law firm does not need a guest account in your tenant. They log in with their own identity. Your policy determines that this identity appears on the allow list and that their organization meets the contractual requirements. The key is released, the file opens. End the collaboration and the allow list is adjusted, after which the file closes on its own.
Seven concrete trigger events come back in our intake calls almost without exception.
M&A and due diligence. The selling party opens a data room with financial reports, contracts and HR data. Buyers and their advisors need to review, not export. Vera wraps the data room. After closing or walk-away the access disappears without a retrieval process having to be organized. That still works if buyers have copied files without authorization.
Joint venture. Two parties stand up a joint entity and share IP for the duration of the collaboration. Both parties want their own data back the moment the JV ends. Vera delivers that via time-bound policies where rights automatically expire on a contractually agreed end date.
Vendor audit. A regulator or external auditor asks for access to source code, configuration files or system logs. You have to share, but the risk that this data remains with third parties after the audit is real. Vera limits access to specific auditor identities, with expiry after the audit window.
Derogation after breach. After a data breach the Autoriteit Persoonsgegevens publishes a request to supply technical investigation data. That data is itself sensitive: it describes vulnerabilities, compromised systems and indicators of compromise. Wrapping with policy restriction to the investigation group is the minimum appropriate measure under GDPR article 32.
Unexpected departure. A senior engineer or partner leaves abruptly. In the weeks before they downloaded, shared or synced files to a private cloud. If the files are wrapped with Vera, access stops the moment you remove their identity from the policy. Without wrap the fight is lost before it begins.
Suspicion of IP theft. Monitoring shows that an employee is copying unusual volumes of confidential data. You want to keep the investigation quiet and limit damage at the same time. Dynamic revocability on the specific identity or device blocks further opening without the employee being directly alerted.
Contract end with data return. An outsourcing engagement ends and you have to provide provable assurance that the vendor no longer holds a usable copy. Vera transforms that assurance from a contractual promise into a technical certainty: whatever sits at the vendor becomes unusable from the expiry date onward. Audits by the Nationaal Cyber Security Centrum and publications by ENISA describe third-party risk as one of the most persistent problem areas. File-level rights management is one of the few measures that structurally addresses this risk.
Honest answer up front. Microsoft ships two products that come close to Vera's problem space. Many customers already use them. We will not paper over the differences.
Microsoft Purview Message Encryption (OME). This is email-only. It encrypts outgoing messages so external recipients open them in Outlook, an OME portal or a one-time link. It is fine for occasional encrypted mail and for enforced encryption on specific recipient domains. It does not cover attachments outside the mail flow, does not cover files shared over other channels, and it is less granular about who may do what. No per-open watermarking, no revocation after download, no cross-channel visibility.
Microsoft IRM (part of Azure RMS, now largely absorbed into Purview Information Protection). IRM locks rights inside Office file formats. It works well inside Word, Excel, PowerPoint and Outlook. Outside Office it gets wobbly quickly. A PDF is possible provided you use the Microsoft PDF stack. CAD, source code, archives, non-Office viewers and mobile apps outside the official line break the chain. Cross-tenant sharing is cumbersome: guest accounts in your tenant, B2B federations with limitations, or a detour via OME with all the constraints that come with it.
Vera. Vera is file-format agnostic: every file gets the same container treatment regardless of extension or application. Cross-tenant sharing is the default mode: an external identity with their own identity provider opens directly. Dynamic revocability works on every open attempt, not only on the next download. Watermarking-on-open and print rights are policy attributes, not an add-on. The audit log is granular at open-event level, usable in forensic investigation.
The choice is not binary. In most Dutch environments OME and Purview Information Protection run for internal and light external flows, and Vera is deployed for the hard categories: data room, audit, IP, joint venture, unexpected departure. The same classification chain from Titus and Boldon James serves both mechanisms without duplicate labels.
Alternatives outside Microsoft that also come up: Seclore, NextLabs and Virtru. Seclore is functionally the closest comparison to Vera and is deployed in the Netherlands at some government and defense-adjacent environments; the serviceable vendor structure in the Netherlands is narrower. NextLabs focuses on policy-driven attribute-based access and is strong in SAP-linked environments. Virtru is good for email-centric use cases but less so for broader file flows. For Dutch enterprise customers with direct implementation support in Dutch and a service chain that aligns with Titus, Boldon James and Clearswift, Vera is the most common choice.
The architecture in prose. The container is the foundation. At wrapping time the following happens. The original extension stays visible (invoice.pdf, drawing.dwg, sourcecode.zip), but the payload is replaced with an encrypted blob in AES-256-GCM. Directly behind the blob sits an inline metadata block with policy ID, server endpoint, key fingerprint and optional offline token. The container is visible to a file system viewer, but without the Vera viewer or web reader the content is not openable.
The policy engine on the server side is the core. A policy consists of four attribute families: who (identity or group), when (time window, expiry, Conditional Access state), where (geographic restriction based on IP or claims) and how often (open count, print limit, download limit). Policies are attached to the file at construction via the policy ID and can be adjusted afterwards without touching the file again. That is the technical basis of dynamic revocation: the next open attempt consults the current policy, not the policy snapshot at the moment of wrapping.
At every open attempt the viewer runs a policy check against the Vera server. If the policy is active, a session key is released, along with a print, copy and watermark attribute set. The viewer renders the file and adds a watermark overlay with user name, timestamp and document ID. That watermark is visible on screen and in prints. Physical photos of the screen remain possible, but they identify the leaker. That is a deliberate design: perfect unbreakable protection does not exist, attributable protection does.
Offline access is a policy attribute, not default behavior. You set per classification label or per workflow how long a session token may be cached locally. From 0 days (always online) to 30 days (field staff). After expiry a fresh online verification is required. The cache is almost always set conservatively, because offline-access drift is the biggest weakness of persistent rights management. Too generous an offline window means a broken identity binding can take weeks to become effective.
The audit log is where the audit value comes from. Every open attempt, successful or denied, is logged with timestamp, identity, IP, device, policy and outcome. Prints and copy attempts likewise. The log is writable as a stream to Splunk or Microsoft Sentinel via a SIEM audit feed. For the forensic investigator that is the primary source: not whether a file has leaked, but who tried to access it and what they did with it.
Identity federation deserves separate attention. Vera federates with Azure AD via SAML or OIDC and adopts Conditional Access claims. If your Azure AD blocks a recipient on the basis of unknown location, Vera refuses before a key is created. The same flow works with Okta and Ping. For internal users the experience is identical to their Microsoft login. For external recipients it works via their own identity provider, without you having to manage guest accounts.
DLP label handoff closes the chain. Titus or Boldon James places a classification label in the metadata or in a central catalog. A policy engine (Vera's own or an external workflow engine such as GoAnywhere) reads that label on save, share or export and routes files above the threshold automatically through the wrap. The user does not notice. On opening at the recipient the Vera viewer appears, federates the identity and opens if allowed. The separation between label authority (Titus or Boldon James), policy engine (Vera or the workflow layer) and enforcement (Vera server and viewer) holds up in audit.
Failure modes we see in practice. First, offline-access drift. A generously configured offline cache of 30 days means a broken collaboration leaves gaps for a month. Remedy: offline window differentiated per label level, strict logging, and periodic forced verification in high-risk workflows. Second, mobile viewer compatibility. Some mobile apps replace the Vera viewer with their own renderer, causing the file not to open. Remedy: controlled MDM rollout with the Vera viewer as the primary Office alternative on regulated mobile fleets. Third, performance on large CAD files. Wrapping and unwrapping a 2 GB Inventor file takes noticeably longer than a Word document. Remedy: asynchronous wrapping in the workflow, manage user expectations, and for very large files consider a streaming wrapper where available. Fourth, key rotation complexity. Policy and key hierarchies need to be rotated periodically; poorly planned rotation on an active dataset can make batches of files temporarily inaccessible. Remedy: rotation plan upfront, rolling rotation per label group, and a test procedure on a non-production tenant.
The lead time of a typical rollout. Week 1 to 2: architecture design, policy definition for two or three priority workflows (typically data room, vendor audit and internal IP protection). Week 3 to 4: POC with 20 to 50 users on a scoped dataset, including federation with Azure AD and viewer rollout on two mobile platforms. Month 2 to 3: expansion to all planned workflows, label handoff from Titus or Boldon James, SIEM audit feed to Splunk or Sentinel. Month 3 to 4: operationalization, runbooks for revocation and key rotation, forensic procedures, and handover to the managed operations team. For the broader portfolio context see the solutions page. For the regulatory motivation behind this chain see the deep-dive why page. If you want to start directly with a POC the contact form is on the contact page, or you can return to the overview.
Microsoft IRM locks rights inside Office file formats and relies on an Office viewer that speaks the RMS protocol. Outside Office the chain breaks: PDF, CAD, source code or archive formats fall outside its reach. Vera works on any file format and wraps the payload in a generic container with inline policy. Access control stays active regardless of viewer, tenant or host.
Yes. Vera is file-format agnostic and identity-agnostic. You can federate with Azure AD, Okta, Ping or any SAML provider. A recipient at an external party without your tenant can open with their own identity, as long as your policy allows it. Cross-tenant is the default mode of operation, not an edge case.
Yes. That is the core function. The container checks the current policy on the Vera server at every open attempt. Revoke rights and the container refuses decryption from that moment on, including copies that already sit with third parties. For offline access a pre-set expiry applies, after which fresh verification is required.
Limited. A recipient can cache a token for a configurable window, typically 1 to 30 days. Within that window the file opens without network. After expiry reopening is only possible with fresh verification. For high-risk data you limit offline access to zero days; for field service you accept a longer cache with audit follow-up.
The file stays encrypted. The new recipient sees the container but cannot open it unless their identity appears in the policy. Forwarding is not a leak, it is a verification attempt that gets logged. The audit log shows which identity tried to open and whether the attempt was allowed or denied.
Via SAML or OpenID Connect federation. Vera delegates authentication to your Azure AD, takes over the claims and applies them to the policy. Conditional Access rules from Azure AD remain in force: if a recipient is on an unknown device or in an unknown country, Azure AD can block before Vera releases the key. The same flow works with Okta and Ping.
Yes. Titus places the label into the metadata at creation. A policy trigger picks up documents with label confidential or higher and routes them automatically through the Vera wrap. The user picks the label, the system picks the protection. The same bridge exists with Boldon James for documents that surface through discovery scans.
Due diligence. The selling party opens a data room with tens of thousands of files that the buyer and their advisors need to review without copies lingering after the deal. Vera wraps the data room. Advisors open within their own tenant. After closing or walk-away you revoke the rights, after which every copied file becomes unusable at the recipient.
Regulatory sources: GDPR 2016/679 article 32, NIS2 2022/2555, ISO/IEC 27001:2022 Annex A 8.12.