EU Tech Sovereignty Package tests whether open source becomes policy

At a glance

What this is: This is PassBolt’s analysis of the European Commission’s Tech Sovereignty Package, arguing that open source only becomes strategically meaningful when policy creates binding mechanisms rather than repeating broad declarations.

Why it matters: IAM, PAM, and NHI programmes depend on procurement, portability, and interoperability decisions that determine whether identity tooling can be replaced, audited, or governed without lock-in.

Context

The policy question is not whether open source has strategic value, but whether public initiatives can change procurement behaviour, dependency patterns, and platform lock-in. For identity programmes, that matters because the way software is bought and integrated often determines how much control security teams retain over credentials, telemetry, and lifecycle governance.

PassBolt frames the European Commission’s Tech Sovereignty Package as a test of execution, not intent. The article argues that Europe has made similar declarations before, yet market structure and public-sector procurement have not shifted enough to make openness the default control environment.

The practical issue is whether principles such as open standards, interoperability, portability, and fair access to public markets become enforceable conditions. Without that, open source may remain politically endorsed but operationally optional.

Key questions

Q: How should IAM teams evaluate open source tools without creating lock-in?

A: Focus on whether the tool preserves portability, transparent interfaces, and exportable evidence. If an open-source system still traps credentials, logs, or integrations behind proprietary workflows, it behaves like a closed platform from a governance perspective. Procurement should test exit paths, not just license terms.

Q: What breaks when open standards are missing from identity programmes?

A: Without open standards, identity teams lose the ability to move configurations, logs, and integrations cleanly between systems. That increases switching cost, weakens oversight, and makes procurement decisions harder to reverse. The result is not only vendor dependence, but weaker governance over lifecycle changes.

Q: Should organisations treat sovereignty goals as a security requirement?

A: Yes, but only when sovereignty is translated into measurable controls such as portability, auditability, and interoperability. Abstract policy language does not improve security on its own. Teams need criteria that preserve operational control when suppliers, hosting, or market conditions change.

Q: How do public procurement rules affect software and identity control?

A: Procurement rules shape whether organisations can keep control over integrations, evidence, and migration options. When sourcing favours bundled scale over open interfaces, teams inherit future lock-in. Good procurement makes exit feasible before a contract is signed, not after a problem appears.

Technical breakdown

Why open standards matter to identity governance

Open standards reduce dependency on a single implementation path by making identity, access, and integration behaviour more portable across systems. In IAM terms, that affects how teams move credentials, audit logs, federation trust, and administrative workflows without re-architecting the whole stack. The operational value is not ideological openness, but the ability to preserve control when vendors, hosting models, or procurement terms change. Where standards are weak or optional, the identity programme inherits hidden switching costs and weaker leverage over lifecycle governance. Practical implication: treat standards support as a control requirement, not a procurement preference.

Practical implication: Make interoperability a procurement gate for identity, secrets, and collaboration tooling.

How procurement creates software and identity lock-in

Procurement rules often determine whether open source remains a real option or becomes a nominal one. If evaluation processes reward scale, bundled platforms, and incumbent familiarity over portability and transparent interfaces, then identity teams end up with systems that are difficult to replace or govern. That problem is not unique to open source, but open-source adoption is especially sensitive to it because the benefits depend on continued openness in support, standards, and contribution pathways. Practical implication: assess procurement criteria for lock-in effects before the contract is signed.

Practical implication: Review sourcing criteria for hidden barriers that reduce exit options or governance flexibility.

When sovereignty policy becomes a control problem

Sovereignty language only changes security outcomes when it creates enforceable control conditions. For identity and access programmes, those conditions include portability of credentials, transparent dependency chains, and the ability to audit what the software is doing and what it depends on. If policy stops at declaration, the market keeps rewarding size and influence rather than openness and contestability. That leaves security teams with the same operational reality, even if the policy narrative has changed. Practical implication: separate political endorsement from implementable governance requirements.

Practical implication: Translate sovereignty goals into measurable access, audit, and portability requirements.

NHI Mgmt Group analysis

Open source only becomes policy-relevant when it changes the switching cost structure. PassBolt’s point is that declarations are easy; the hard part is making lock-in materially more expensive than openness. That matters to identity governance because procurement choices shape whether credentials, integrations, and audit trails can be moved without programme disruption. The practitioner conclusion is simple: if portability is not enforced, sovereignty remains rhetorical.

Identity teams should read sovereignty debates as control-plane debates. The real issue is not whether software is open source in name, but whether standards, interfaces, and governance conditions allow an organisation to retain operational control. In IAM and PAM terms, that determines how much leverage teams have over lifecycle changes, vendor exits, and assurance evidence. The practitioner takeaway is to treat openness as an architectural control surface.

Market concentration and openness are not opposite policy outcomes, but they pull in different directions. PassBolt argues that Europe’s software market has not materially changed after repeated policy statements because the incentives behind procurement still favour scale and embedded influence. For identity security programmes, that means tool choice can be constrained long before technical evaluation begins. The practitioner conclusion is to scrutinise whether governance criteria preserve contestability or simply formalise incumbent advantage.

Open standards are the named concept that turns sovereignty from aspiration into enforceable behaviour. They define whether an identity stack can be exchanged, audited, and integrated without rebuilding the programme around a single supplier’s assumptions. In practice, that affects credentials, federation, portability, and the long-term viability of open-source adoption. The practitioner conclusion is to make standards support measurable in every sourcing and architecture review.

What this signals

Open standards are the practical test of whether sovereignty policy will alter identity governance. If an IAM or NHI programme cannot move credentials, audit data, and integration logic without platform rework, then the policy has not changed the control environment. The reader should treat portability as a design requirement, not a future option.

Open source as critical infrastructure only matters when procurement stops rewarding inertial lock-in. That means architecture reviews and sourcing decisions need to ask whether a tool can be replaced, inspected, and integrated on terms the organisation controls. The governance lesson is that market structure is part of the attack surface for long-term identity assurance.

For practitioners

• Define portability as a procurement control Require identity, collaboration, and security tools to demonstrate exportability of configuration, logs, and credentials before contract award.
• Add interoperability tests to vendor evaluation Test whether open standards let you move integrations, federation settings, and audit data without rebuilding core workflows.
• Check exit costs before adoption Model what it would take to replace the platform if support ended, including data transfer, API dependencies, and administrative rework.
• Separate policy support from operational assurance Document which sovereignty requirements are political objectives and which are enforceable technical controls in your IAM or NHI programme.

Key takeaways

• Open source becomes strategically useful for identity programmes only when policy creates enforceable conditions, not just endorsement.
• The article’s central warning is that procurement and dependency patterns can preserve lock-in even when openness is politically celebrated.
• Practitioners should translate sovereignty language into measurable requirements for interoperability, portability, and exit feasibility.

Key terms

• Open standards: Publicly defined technical interfaces that let different systems interact without relying on one vendor’s private implementation. For identity security, open standards support federation, interoperability, and more reliable governance because they reduce hidden dependency on a single platform boundary.
• Vendor Lock-In: A dependency state where business processes, technical integrations, and identity controls become difficult to move away from without disruption. It is not only a commercial constraint. It also creates governance friction when credentials, APIs, and monitoring workflows are tied too tightly to one provider.
• Control Portability: Control portability is the ability of a governance control to keep working when the application architecture changes. In clean core programmes, portable controls survive release cycles, integrations, and cleanup of custom code, which makes them more reliable than controls that only exist inside legacy extensions.
• Procurement Control: Procurement control is the set of sourcing rules and evaluation criteria that shape what technology an organisation can buy and on what terms. In identity security, procurement often decides whether openness, interoperability, and exitability are enforced before a platform enters the environment.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.