Why an Open Source VPN Gets Rejected in Procurement
A reviewer who objects to open source is usually protecting a requirement, not a licensing taste. Ask which one, then produce the artifact that answers it.
Rejections that cite open source rarely turn on licensing. The reviewer is normally protecting a requirement: that somebody maintains the deployed release, that the installed build can be identified, that an assessment covers what is being connected, or that the connection can be withdrawn. The debate that follows tends to answer a question nobody asked.
Ask which requirement applies before you defend a licence. The answer decides which document you need.
The Label Is Not the Requirement
Readable source code means the published implementation can be inspected. It does not mean anyone inspected it, that the build on the gateway matches the published one, or that a maintainer owes your deployment a fix. Each of those is a separate claim with a separate owner, and a reviewer who needs one of them will not be satisfied by the others. Naming the claim out loud is usually enough to change the conversation.
The reverse mistake is just as common. A commercial licence does not prove that support covers the feature you rely on, that an assessment examined the component you deploy, or that the vendor will ship a correction inside your maintenance window. Licensing describes distribution terms, while procurement decisions are about reliance. Either way, the licence is the least informative part of the answer.
Keep the client and the service apart as well. An audit of a desktop client says nothing about the partner's gateway configuration, its identity provider or the way its operators handle account removal. Whatever evidence you gather has to match the boundary the partner is being asked to trust.
Turn the Concern into an Artifact
Ask the approver to state the requirement in one sentence, then name the artifact that would satisfy it. Vague reassurance is what turns these conversations into a debate about ideology.
| What the reviewer is protecting | Artifact that answers it | Who can sign it |
|---|---|---|
| The deployed release keeps getting fixes | Named maintainer, supported version list and the cadence for security releases | The operating team, with the maintainer's published policy attached |
| The build is the one that was reviewed | Package source, version string and the checksum or signature you verify at install | The team that builds or vendors the package |
| An assessment covers the right scope | Component and version assessed, findings raised, corrections made, retest date | Whoever performed the assessment |
| The access can be withdrawn | Identities granted, resources reachable, and the tested removal procedure | The service owner on the partner side |
The NIST Secure Software Development Framework is useful here for one narrow reason: it frames acquisition conversations around a shared vocabulary of practices and supplier communications. That supports asking for defined evidence instead of arguing about a label, and it is not a certification that any particular VPN passes.
Notice what the middle column does. Every row asks for a document that either exists or does not, which converts an opinion into a deliverable somebody can produce or refuse.
Separate the Client from the Service
A support contract for a client application is not a commitment about the server your traffic reaches. Before you present evidence, mark which parts of the path the partner operates and which parts you operate on their behalf. Mixing the two produces a packet of documents that looks thorough and answers nothing.
If the deployment is yours, the partner may only need to trust an identity and an access rule, which is a much smaller request than trusting your entire software supply chain. If the deployment is theirs, the client you prefer may be irrelevant and the gateway configuration becomes the subject. Working out which case you are in before the second meeting saves a review cycle.
Then check the operational questions that reviews actually fail on: who removes an account, how quickly, and what evidence exists afterwards. A beautifully documented assessment with no removal procedure is still an open finding.
Close With a Decision, Not a Debate
End the exchange with a written outcome: the accepted version, the controls attached to it, the named operators, the evidence still outstanding and the date it is due. Anything unresolved should be recorded as a condition rather than absorbed into a general statement of approval.
If the policy names a specific approved product, use the exception route instead of building a parallel arrangement that nobody authorized. A persuasive technical case does not grant permission, and an unofficial deployment is a finding waiting to be discovered.
If a requirement genuinely cannot be met, move to the approved alternative and say why. The purpose of the exercise is to establish what the organization can rely on, and a clear no is a better outcome than an approval that nobody can defend later.