For most of the last decade, enterprise security procurement followed a simple pattern: the vendor produces a SOC 2 report, a penetration test summary, and a list of certifications, and the buyer takes it on faith that the software does what the vendor says. In Europe in 2026, that pattern is breaking down — not because compliance reports stopped mattering, but because “trust us” is no longer a sufficient answer to a procurement team running real vendor due diligence.
Europe is funding its way toward auditable infrastructure
This isn't just sentiment — it's backed by real money and real regulation. The EuroStack initiative has attached a roughly €300 billion investment ambition over the next decade to building sovereign European digital infrastructure across cloud, compute, and networks, as we covered in Part I of this series, much of it oriented around open standards and inspectable software rather than closed platforms. Germany's Sovereign Tech Fund has spent years directly funding open-source infrastructure projects on the same premise: critical digital infrastructure the public and private sector depend on shouldn't be a black box controlled by a single company — it's the same fund that financed the independent audit of OpenVPN's own protocol completed earlier this year (more on that below).
The regulatory side reinforces the same preference. The Cyber Resilience Act (CRA), which begins enforcing vulnerability and incident-reporting obligations on 11 September 2026, draws a deliberate line between closed commercial products and open-source components: non-commercial open-source software is largely exempt, while commercial products built on open-source components carry full manufacturer responsibility — but the underlying code stays open to independent review by anyone. That's a fundamentally different security posture than a closed platform where only the vendor's own internal team can verify what the software does. (We break down how the CRA fits alongside DORA and NIS2 for network-access vendors specifically in our three-law vendor-risk guide — this post focuses narrowly on what the CRA's open-source distinction means for source-code-level due diligence.)
What “auditable” solves that “certified” doesn't
Compliance certifications answer the question, “did an auditor review this vendor's processes at a point in time?” They're valuable, and Access Server carries the relevant ones — SOC 2 Type 2, ISO/IEC 27001:2022, HIPAA, and GDPR compliance-readiness. But that's a narrower question than most vendor risk management programs assume. Certifications don't let a customer's own security team independently verify how a specific feature behaves, how a vulnerability class was addressed, or whether a vendor's claims about encryption or key handling hold up under direct inspection.
Open-source code answers a different, complementary question: can anyone with the skill and motivation check this themselves? For security-critical infrastructure — and network access is about as security-critical as infrastructure gets — that second question increasingly matters as much as the first to European buyers who've watched vendor breach disclosures and CLOUD Act exposure become board-level topics rather than back-office ones.
The receipts: three independent audits, spanning nine years
This isn't a theoretical argument. The OpenVPN protocol has been put through independent, adversarial review multiple times by firms with no commercial stake in the outcome — and the reports are public:
- In 2016–2017, QuarksLab and Cryptography Engineering audited OpenVPN 2.4 under funding from the Open Source Technology Improvement Fund and found two remote denial-of-service issues, both patched within weeks. Read the audit findings.
- Trail of Bits reviewed the OpenVPN2 codebase and its maintenance processes, including static analysis and fuzzing, and reported no significant flaws affecting confidentiality, integrity, or availability.
- Most recently, SRLabs' independent audit of OpenVPN v2.7, funded by Germany's Sovereign Tech Fund and running October 2025 through March 2026, found no attacks against OpenVPN's transport security guarantees, with the small number of issues identified already mitigated or in remediation.
That's what “ask for the source code” cashes out to in practice: not a hypothetical offer to look, but a track record of outside experts actually looking, publishing what they found, and the code getting fixed in response.
Where OpenVPN sits in this shift
The OpenVPN protocol itself has been open source for more than two decades, reviewed, tested, and hardened by a global community of security researchers rather than relying solely on one company's internal review. That's a structurally different trust model than the closed tunneling protocols built into many SASE and VPN clients, where the vendor that wrote the code is the only party who can verify it.
OpenVPN Access Server builds a commercial management layer — the Admin Web UI, access control policies, clustering, licensing — on top of that open protocol core, and CloudConnexa supports the same OpenVPN protocol alongside IPsec. Under the CRA's framework, that puts the commercial products themselves in the manufacturer category, carrying full responsibility for the product's security lifecycle. But the protocol underneath remains something a customer's security team, or any independent researcher, can actually read — not just take a vendor's word for.
For procurement teams running vendor risk reviews in 2026, that combination — a commercially supported product built on an openly auditable, independently reviewed core, backed by relevant compliance certifications — is becoming the specific answer they're looking for, rather than a closed platform that asks them to trust a report and nothing else.
This isn't a purity argument
None of this means every closed-source security product is untrustworthy, or that open source is automatically more secure by default — poorly maintained open-source projects carry their own risks, which is part of why the CRA imposes real obligations on commercial products built from open components. The point is narrower and more practical: when a European buyer's own regulatory obligations increasingly require them to demonstrate, not just assert, that their vendors are secure, software they can independently inspect gives them something to point to that a closed platform simply can't offer.
Frequently asked questions
Is OpenVPN Access Server itself open source?
The OpenVPN protocol at Access Server's core is open source and has been publicly available for independent audit for more than two decades. Access Server adds a commercially licensed management and administration layer — the Admin Web UI, access policies, clustering, licensing — on top of that open core.
Does the Cyber Resilience Act treat open-source software differently from commercial software?
Yes. Non-commercial open-source projects face significantly lighter obligations under the CRA. Commercial products that incorporate open-source components — including commercially supported software built on an open protocol — carry full manufacturer responsibility for the finished product's security, with vulnerability and incident-reporting obligations starting 11 September 2026.
Why does auditability matter if a vendor already has SOC 2 or ISO 27001 certification?
Certifications confirm that an auditor reviewed a vendor's processes at a specific point in time. They don't let a customer independently verify the underlying code. Open, auditable software gives security teams a second, independent way to confirm vendor claims rather than relying solely on a compliance report.
What's the difference between open source and a source-code escrow agreement?
Some closed-source vendors offer source-code escrow as a partial answer to auditability concerns: the code is deposited with a third party and released only if the vendor goes out of business or breaches contract terms. That protects business continuity, but it doesn't let a security team review the code today, before signing. An open-source protocol like OpenVPN's is available for inspection continuously — not just as a contingency plan.
Does this apply to CloudConnexa as well as Access Server?
CloudConnexa supports the OpenVPN protocol alongside IPsec, so the same auditability argument for the underlying protocol applies there too. Like Access Server, the commercial CloudConnexa platform — the cloud management plane, access policies, and infrastructure — is a commercially supported product built on that open core.
See it for yourself
If your next vendor review calls for more than a compliance report, explore Access Server — an open, independently audited protocol core with the commercial certifications procurement teams also expect.
Related posts
- Part I: Why Europe Is Drawing Its Own Digital Borders & What That Means for Your Business
- Part III: Sovereignty by Design — How Self-Hosting Puts European Businesses Back in Control
- DORA, NIS2, and the CRA: The Three EU Laws Rewriting Vendor Risk for Network Access
- The CLOUD Act Problem Nobody's Pricing In
- Zero Trust, Bought or Built? Why Europe Is Rethinking the Cloud-Broker ZTNA Model
- Transparency in Action: OpenVPN v2.7 Independent Security Audit Results
- Trail Of Bits Validates Security Strength of OpenVPN