Low-code in the KRITIS environment: sovereignty starts with software architecture

Last Updated on 12. June 2026

The debate surrounding digital sovereignty in critical infrastructures has gained momentum. Regulators, operators and security authorities are asking the right questions: Where is my data stored? Who controls my infrastructure? Will I still be able to function in the event of a crisis? Yet an equally fundamental question is often overlooked: what about the software itself?

KRITIS operators in the energy, healthcare and defence sectors now manage a multitude of digital specialist procedures and administrative processes. Many of these run on proprietary platforms – with opaque licensing models, closed source code and heavy dependencies on individual manufacturers. What happens if such a partner is lost? Due to geopolitical pressure, insolvency or the discontinuation of a product? In the worst-case scenario, critical processes could then come to a standstill.

Open source as a structural solution

In this context, open-source-based low-code platforms offer a structural advantage for software architecture. After all, source code transparency is essential in security-sensitive environments. Those who can view, review and audit the code are not reliant on the trust of a single vendor.

The advantages of open-source low-code platforms:  

•    No vendor lock-in due to proprietary licences: Those building on an open-source basis retain control, regardless of how market conditions or corporate strategies evolve. Several high-profile cases in recent years have shown how quickly proprietary platforms can change their licence terms or cease operations.

•    Reuse and community: In the public sector and within KRITIS structures, open standards enable structured exchange between operators – analogous to the ‘one for all’ (EfA) principle in administrative digitalisation. Solutions that have been developed once do not need to be reinvented repeatedly.

•    On-premise remains a fully viable option: Those who cannot or do not wish to use a cloud connection for regulatory or security reasons are not restricted by open-source platforms, neither functionally nor in terms of licensing.

What legislators and regulatory authorities have already recognised

NIS2 and DORA are not abstract compliance requirements. They directly address the question of how operators of critical infrastructure should design their software architecture. Both sets of regulations require transparency regarding software supply chains and the active management of third-party risks. Those who run their core processes on an open platform can meet these requirements structurally. Not through time-consuming documentation after the fact, but because the architecture itself is the answer. This is no coincidence. The regulator has understood what is often overlooked in practice: sovereignty is not just a question of data centre location.

The real question: enterprise maturity

The question of whether open source is fundamentally viable in KRITIS environments has been settled. The relevant question today is: which platforms offer the necessary enterprise maturity?

In concrete terms, this means:

•    Demonstrable scalability in complex, regulated environments – not just in pilot projects.

•    Operation in security-critical contexts with appropriate certifications and audit trails.

•    A robust ecosystem of partners who can ensure long-term support, further development and operation.

Platforms that meet these criteria are already available on the market. They are also increasingly gaining ground in regulated sectors. Digital sovereignty in the KRITIS environment is an ongoing architectural decision. Those who rely today on proprietary platforms with closed supply chains create dependencies that are difficult to resolve later on. Open-source-based low-code platforms are therefore not a stopgap solution. With the appropriate level of enterprise maturity, they represent a structurally superior approach for critical environments where transparency, control and resilience are not optional but explicit requirements.