AIVD-evaluated products: what ‘approved’ means in practice

What the list says, and what it does not

The AIVD publishes the overview of products evaluated by its Unit Weerbaarheid. Every entry has four fields: product name, security value, version and remarks. Above the table sits the sentence that qualifies all of them at once: all these products offer sufficient protection only if they are deployed according to the guidance in the accompanying deployment advisory.

The security value column is the one most often misread. The AIVD’s own note states that it gives the highest permitted classification of information that may be protected with the product, and that lower-classified information may be protected with it as well. A product with security value Stg. GEHEIM is therefore not a product meant exclusively for state secrets; it is a product whose evaluation reaches that far.

Dutch government uses four classifications: Departementaal Vertrouwelijk, Stg. CONFIDENTIEEL, Stg. GEHEIM and Stg. ZEER GEHEIM. The higher the classification, the stricter the Unit Weerbaarheid’s evaluation criteria. In practice the column also carries international values such as NATO Restricted, EU Restricted and NATO (Top) Secret, and the value itself can be conditional: Blancco Drive Eraser is listed as “Stg. Geheim, with restrictions: see deployment advisory”. The column is not a single scale but a pointer to the reach of one concrete evaluation.

The list is not a live product register: the page itself gives June 2025 as its last update. Nor does it say anything about brand names. The same manufacturer can appear on this list with one configuration and on an entirely different scheme with another, or on neither.

Three names run alongside each other in sources that are all current. The Nationaal Bureau voor Verbindingsbeveiliging (NBV) is called NLNCSA, Netherlands National Communications Security Agency, in English-language documents, and Unit Weerbaarheid on the current AIVD pages. The product list uses NBV and Unit Weerbaarheid side by side, in different rows of the same table. They are the same AIVD unit.

The evaluation covers a version, not a brand

An evaluation yields a deployment advisory for a particular version of the evaluated product: a hardware variant, a firmware or software version, or a variant produced specifically for the Dutch government. The evaluation is explicitly valid for that named version. The AIVD then places a concrete duty on the buyer: as the acquirer of an evaluated security product, it matters that you ask the supplier for the right version.

With the iStorage datAshur PRO that scoping goes a long way. The AIVD names not only version 3.0 and firmware level 1.11, but also that the Dutch Dep. V.-approved sticks have carried a separate manufacturer part number since 1 November 2022, IS-FL-DA3-256-X-BL. USB sticks with a different part number are, the AIVD states, not approved. A purchase order that says only “iStorage datAshur PRO” leaves that decision to the supplier.

The reverse occurs too: two entries that are barely distinguishable in a quotation and sit far apart. Technolution PrimeLink 5001 is listed at Stg. (Zeer) Geheim, PrimeLink 5001 c at Stg. Confidentieel, on the same hardware and software versions. The Compumatica CryptoGuard VPN family appears twice, with different version sets and different validity for EU and NATO Restricted.

The question in a design or procurement process is therefore not whether product X is AIVD-approved. It is whether the exact combination of hardware, firmware, software branch and, where relevant, part number that will be deployed falls inside the evaluated scope, for the classification at hand and for the intended application. That is the difference between a marketing claim and a security claim.

The deployment advisory sets where the claim stops

The AIVD describes a deployment advisory as a document for buyers that sets out how a product can be used and managed safely and what residual risks there are. Its audience is named explicitly: IT administrators, IT policy staff, process owners, departmental security officers and security officers. The advisories can also be used to compare similar products from different suppliers.

OpenVPN-NL is the only product whose deployment advisory is public, and therefore the only public example of what such a document contains. Version 2.5 runs to 26 pages.

The advisory states that the security of an OpenVPN-NL deployment depends on four factors: the security of the software, its configuration, the security of the machines and operating systems it runs on, and the security of key management. When one of those factors fails, the security of the whole deployment falls apart. Three of the four sit outside the product.

The advisory also bounds the claim. The evaluation covers protection against breaches of confidentiality and integrity; availability, including robustness of the tunnel, was not evaluated. Nor does the quality of the implementation of underlying mechanisms such as routing, firewall settings and the assumptions about the PKI architecture fall within the evaluation proper, while the advisory notes in the same breath that those functions are vital to overall security. The disclaimer is explicit: the evaluation is not a complete code review, does not consider an actual deployment, and a user organisation has to assess for itself whatever it builds on OpenVPN-NL. In the document’s own words, OpenVPN-NL is a building block, not a total security solution.

The advisory also carries hard conditions, not loose suggestions. Split tunnelling is not recommended unless it is used to create an exclusive channel over a trusted network; over a hostile network it brings serious risks, because the host machine is then easy to target. For private key material, smartcards are recommended, with the material never leaving the card. And in view of the quantum threat the advisory requires users to protect the TLS channel with a pre-placed symmetric key via tls-crypt or tls-crypt-v2. The advisory also names the yardstick used: the NLNCSA Evaluation Criteria 2020, dated 1 October 2020.

A deployment advisory therefore says as much about the limit of the approval as about the approval itself, and about which part of the risk stays with the buyer.

Where the sources themselves diverge

The product list gives no version number for OpenVPN-NL; the version column holds only “OpenVPN-NL (as opposed to Vanilla OpenVPN)” with a pointer to the deployment advisory. The version scoping therefore sits in the advisory, which is at version 2.5 and covers the 2.5.x branch.

That same advisory was published on 29 March 2023 and names Fox-IT as maintainer and distributor, with openvpn.fox-it.com as the download location. The current AIVD list and the AIVD document page point to openvpn.sentyron.com and publish fingerprints for sentyron-win.pem and sentyron-gpg.asc. On that point the two sources contradict each other.

The advisory resolves this itself, but only for a careful reader: it instructs you to verify the fingerprint of the downloaded package on the NLNCSA website. That instruction points at the AIVD page, and the AIVD page has been updated. The stale URL inside the PDF is therefore not a flaw in the procedure, but it is a trap for anyone treating the advisory as a standalone document.

None of these pages holds the whole answer on its own, and they were updated at different moments. That is why the AIVD refers back to the Unit Weerbaarheid whenever there is doubt. For a procurement file it is the only way to establish scope defensibly.

Seven examples from the list, read as a buyer

That a deployment advisory is not public does not mean the conditions do not exist. They have to be obtained from the body designated for it, before a design is fixed.

Lifecycle: updates, end of support and removal from the list

Assurance is not a one-off event. The AIVD places the duty to report product developments and updates on the supplier, who must keep the NBV informed. If government later needs a newer version, it is examined which updates were security-related, and with that information the newer version can be evaluated by the Unit Weerbaarheid. An update therefore does not inherit its predecessor’s evaluation status.

Removal from the list also needs careful reading. According to the AIVD it generally means the product is no longer available from the supplier or no longer supported. That is separate from whether the product may still be deployed or no longer meets the evaluation criteria. In case of doubt the AIVD advises asking the Unit Weerbaarheid; as a general line it advises moving to newer evaluated versions in good time.

The mirror image is on the list as well: the Sectra Tiger/R carries the remark “End of 2024: End of Support” and was still listed in the June 2025 version of the page. Being listed and being supported are not the same thing. For the iStorage datAshur PRO, by contrast, the AIVD announces in advance that the deployment advisory for the evaluated version will be withdrawn on 1 January 2027.

The OpenVPN-NL advisory works such a lifecycle out at product level. A release there is always in one of three states: Current, Deprecated or Untrusted/insecure. The state only moves downwards and may skip Deprecated, so a current release can be declared untrusted outright. Current and deprecated releases stay downloadable; untrusted releases and their source code are never offered again, through any channel. The advice is to use a current release under all circumstances.

For architecture and contract management this produces a requirement that goes beyond recording the version at delivery. Record who judges whether a new version still falls inside the evaluated scope, who tests a change against the deployment advisory, and what happens once support or evaluation status changes. Delaying patches does not follow from that. Assigning the tension between vulnerability management and assurance deliberately does, rather than letting an automatic update process settle it.

ABRO 2026: annex 9 and Approved Means

Since 1 January 2026 central government has been introducing the Algemene Beveiligingseisen voor Rijksoverheidsopdrachten for contracts that carry risks to national security. The rollout is phased: organisations have two years, so the effective date differs per organisation. The police and the ministries of General Affairs, Defence and the core department of Justice and Security already apply the ABRO; for other parts the effective date falls in 2026 or 2027.

The ABRO framework decision describes the route there. Where risks to national security are suspected, a quick scan is carried out first; if that shows such risks may exist, a risk analysis follows. Where this reveals a Special Contract whose risks cannot be controlled by less intrusive measures, the ABRO is applied and the minister files a request with the NBIV to examine the contractor. The decision states expressly that the ABRO is not applied automatically.

Within the ABRO itself, the obligation to use Approved Means recurs in many places, among them cryptography, encryption on mobile devices, remote access and the erasure of storage media. ABRO 4.5.11, 4.7.1, 4.7.4, 4.8.9

Annex 9 works this out. For both a Dutch and an international Special Contract, an exhaustive selection of evaluated products applies. Deploying those means is permitted only when the evaluated version is used and the deployment advisory is complied with in full; that advisory can be requested through the NBIV. The condition is therefore not national-only: it stands in the opening paragraph and covers both situations. ABRO annex 9

Nationally, the Unit Weerbaarheid’s list of evaluated products is leading for every classification level. Internationally, products evaluated by for example NATO or the EU or under treaty apply, always in consultation with the NBIV. European practice connects to that: before a product approved by one member state may protect EU-classified data, a second AQUA country carries out its own evaluation. Besides the Netherlands, Germany, France, Italy and Sweden are AQUA.

Where the selection falls short, an application can in exceptional cases be filed through the NBIV to use a non-evaluated product under strict conditions. The remaining ABRO requirements still apply, among them that products must not originate from, nor depend on, countries with a known offensive cyber programme against the Dutch State. The same restriction applies separately to security mechanisms and to electronic security systems. ABRO 3.3.1, 4.5.8, annex 9

For cryptography the ABRO also fixes an order of precedence that is often skipped in practice. Cryptographic security solutions are set up and managed in accordance with documentation obtained through the NBIV. Alongside that, the client’s connection conditions, the deployment advisory and the manufacturer’s advice are followed and recorded in the security plan; where these conflict, the connection conditions prevail over the deployment advisory, which prevails over the manufacturer’s advice. ABRO 4.8.1

One final nuance, because the terms are easily equated. The ABRO defines Approved Means as software and hardware found suitable for the intended functionality in the context of a Special Contract, and adds that approval is given by different bodies depending on the intended use and the client, with requesting and issuing always running through the NBIV. “Being on the AIVD list” and “being an Approved Means” therefore sit close together but are not interchangeable: nationally that list is leading, but the route runs through the NBIV.

An ABRO declaration is not product approval

A contractor must hold an ABRO declaration at the required level before starting a Special Contract. The NBIV issues it when the contractor meets every ABRO requirement at that level. In the same paragraph the ABRO states that this is explicitly a declaration in the context of a Special Contract and not a certification, and that the contractor is not permitted to make public that it holds one.

That last point is a useful signal when assessing offers. A party advertising an ABRO declaration in marketing material or on a website is acting against the very regulation it invokes.

The substantive boundary is just as sharp. The NBIV examination addresses the security of the contractor’s business operations in the context of that Special Contract. The ABRO requirements and the NBIV examination do not address the quality or security of the product or service delivered during the contract. A declaration is moreover issued for one Special Contract and cannot simply be carried over to another.

Existing certifications or assurance statements can make the process more efficient, but the NBIV must ultimately be able to establish for itself whether the design, existence and operation of the security measures are adequate. A certification, the ABRO says, offers no guarantee of issuance.

BSPA is a different scheme for a different threat

The Baseline Security Product Assessment was likewise set up and is managed by the AIVD, but it is not an AIVD evaluation. The assessments are carried out by licensed private evaluation labs; the AIVD supervises and states itself that it is in no way substantively involved in the laboratory’s assessment.

The purpose differs as well. BSPA is designed as a lightweight assessment and is therefore intended only for the lowest security levels of the BIO, BBN1 and BBN2. The AIVD adds emphatically that BSPA is not intended for security products that must protect (state-secret) information against attacks by state actors, foreign intelligence services and similar parties. A positive assessment is also no guarantee that the product is free of vulnerabilities, and validation applies only to the version assessed.

With one manufacturer the two schemes run very close together. The iStorage datAshur PRO is on the list of evaluated products, at Departementaal Vertrouwelijk, with version 3.0, firmware 1.11 and part number IS-FL-DA3-256-X-BL. The iStorage datAshur PRO+A and PRO+C are on the BSPA list, with firmware 2.00.0 and part number IS-FL-DA3X-256-Y-BL. The same manufacturer, almost the same product name, two different schemes, two different part numbers and two different meanings. An order line that says only “iStorage datAshur” decides nothing.

Seven questions for the procurement or design file

A product name in a quotation is not evidence. For a defensible file, the following questions should be answered explicitly, in this order.

• Which information has to be protected, and what classification goes with it? Establish the security value you need first, and only then choose a means. The value on the list is a maximum, not a destination.
• Is the exact configuration offered on the list? Check hardware revision, firmware, software branch, part number and any special Dutch variant. The same product family is not evidence.
• Is the applicable deployment advisory in hand, and can every condition be met? Under the ABRO, full compliance is required. Where the advisory is not public, request it through the NBIV or the Unit Weerbaarheid before the design is fixed.
• Does the concrete architecture fit inside the evaluated application? Look beyond the device or the software, to host systems, key management, network segmentation and the management environment. For OpenVPN-NL, three of the four decisive factors sit outside the product.
• Which parts does the evaluation not cover? Record residual risks, non-evaluated security functions and assumptions in writing. For OpenVPN-NL, availability and the quality of routing, firewalling and PKI fall outside the claim.
• Who assesses patches and upgrades? Assign explicitly who checks whether a new version stays inside the evaluated scope, so that automated update management does not silently replace an evaluated configuration.
• What is the migration path on withdrawal, end of support or removal from the list? Factor in replacement, stock, configuration migration and consultation with the Unit Weerbaarheid or the NBIV in advance.

Assurance is a chain: classification, exact version, deployment advisory, configuration, management, lifecycle. A tick beside the product name covers one link. Whether the other links stand in practice the way they stand in the file is a question the file itself does not answer; what technical examination can and cannot establish about it is set out in what a sweep can and cannot establish.