Software engineering for KRITIS and regulated industries: what critical infrastructure operators will really need in 2026

Software that runs in an online store is allowed to crash. It’s annoying, but it can be fixed. Software that controls a network control center, operates a hospital platform, or processes financial transactions does not have the same level of fault tolerance. Outages in critical infrastructure are not only costly; they can jeopardize the reliability of services, public health, or public safety. That is precisely why different standards apply to these systems than in the general business environment.

The difference begins with the very question of what security actually means. In a traditional software project, security is often treated as an afterthought in terms of quality: you develop and test the software, and then check at the end to see if everything is secure. In KRITIS projects and in NIS2-regulated environments, this approach is simply no longer acceptable. Security by design is not a recommendation, it’s a prerequisite.

The NIS2 Implementation Act requires critical and important facilities to implement comprehensive risk management measures, to report security incidents within 24 hours, and to demonstrate compliance. KRITIS operators are subject to even stricter requirements: They must operate intrusion detection systems that identify cyberattacks in real time and, as of July 17, 2026, must also register with the Federal Office for Civil Protection and Disaster Assistance for physical protection.

What many companies underestimate is that these requirements apply not only to the operators themselves, but also to their supply chain. Any software service provider that develops software for a KRITIS operator becomes part of the regulatory chain of responsibility. NIS2 explicitly requires affected organizations to contractually ensure and verify the security standards of their suppliers and service providers. A software partner that cannot demonstrate traceable development processes, documentation, or defined security measures thus becomes a compliance risk for its customer.

Added to this is the Cyber Resilience Act, which will become mandatory for software manufacturers starting in 2027 and must already be taken into account during project planning. It mandates “security by design,” active vulnerability management, and a complete software bill of materials—that is, a documented list of all libraries and components used.

The term sounds like a given, but its specific implications are still often introduced too late in projects. “Security by Design” means that security requirementsare identified as early as the requirements analysis phase. What data does the software process? What regulatory requirements apply in the specific industry context? What attack vectors are realistic? These questions determine the architectural decisions, not the other way around.

In the architectural design phase, threat modeling follows, a structured analysis of potential threats and attack surfaces. Methods such as STRIDE help systematically identify where data flows across trust boundaries, where privileged access exists, and where inputs can be manipulated. The results are directly incorporated into the selection of authentication methods, encryption strategies, and access controls.

In the development process, this means, in practice, automated SAST and DAST tests in the CI/CD pipeline, security gates that block critical vulnerabilities before merge, and consistent dependency scanning that checks open-source components for known vulnerabilities. OWASP standards serve as the minimum framework, supplemented by industry-specific requirements, whether IEC 62443 in the energy sector, ISO 27001 as a general foundation, or GDPR and HIPAA requirements in the healthcare sector.

What happens after the go-live is just as important. KRITIS software often has to run reliably for ten, fifteen, or twenty years. Robust architectures, planned maintenance cycles, and structured patch management are not secondary considerations; rather, they are part of the architectural design from the very beginning.

One aspect that often receives too little attention in public discourse is the auditability of software. The BSI can request evidence at any time. Software whose development processes are not documented, whose change history is not traceable, or that lacks logging and monitoring functions makes compliance with regulatory deadlines practically impossible. If a security incident occurs and an initial report must be submitted within 24 hours, there is simply no time for manual investigations. The technical infrastructure must be able to automatically detect, log, and classify incidents.

For software engineering, this means: Logging is not an optional feature, documentation is not a bureaucratic project, and traceable development processes are not just a nice-to-have. They are the foundation that enables software to be used in regulated environments in the first place.

Many KRITIS operators and heavily regulated companies are faced with the question of how they can leverage the benefits of modern cloud infrastructures without losing control over critical data. The answer usually lies in hybrid models: particularly sensitive systems and data remain in the private cloud or on-premises, while less critical workloads are flexibly operated in the public cloud.

This architectural decision must be incorporated into the system design from the very beginning. Zero-trust architectures are the standard framework used today: The principle of “never trust, always verify” replaces implicit trust with rigorous access verification for every user, every device, and every process, regardless of whether the access comes from inside or outside the network. For KRITIS operators, this approach is not only sensible—in many cases, it is a regulatory requirement.

Choosing the right development partner is a strategic decision in regulated environments. In addition to technical expertise, several factors play a crucial role, factors that often carry less weight in typical IT projects.

Process maturity and the ability to provide evidence are top priorities. A partner that cannot demonstrate documented development processes leaves its customers to fend for themselves when it comes to supply chain compliance. The BSI expects affected companies to review their service providers’ security practices and ensure they are contractually safeguarded. A service provider without traceable processes is therefore a regulatory problem.

Experience with industry-specific standards cannot be delegated. Anyone developing KRITIS software for the energy sector does not need to learn IEC 62443 while the project is underway. Anyone developing software solutions for the healthcare sector must consistently apply the GDPR, HIPAA, and the MDR and IEC 62304 from the very beginning. Regulatory expertise and technical expertise must come together within the same team.

Long-term partnerships are particularly valuable in regulated environments because software isn’t simply deployed and then forgotten. Patch management, security monitoring, incident response, and adaptation to new regulatory requirements all call for a partner who understands the system and provides long-term support.

For over 20 years, BAYOOTEC has been developing customized software solutions for companies for whom reliability, data protection, and compliance are not optional. As part of the BAYOONET Group, we operate within an ecosystem that understands regulated environments from various perspectives: BAYOOSOFT brings deep expertise in IT security and access management for KRITIS-relevant infrastructure, BAYOOMED has more than ten years of experience in developing medical software in accordance with IEC 62304 and the MDR, and BAYOOCARE guides companies through regulatory processes in the medical device sector.

For our customers, this means: When an energy provider commissions the development of a platform for grid control, or when a hospital needs a cloud solution for patient data management, we don’t operate as an external supplier, but as a partner who takes the regulatory framework into account from the very beginning. Security by design, auditable processes, hybrid architectural approaches, and the integration of industry-specific standards are not special services for us, but rather part of our development approach for regulated environments.

We conduct regular penetration tests, develop solutions based on the principle of “Privacy by Design,” and also support our clients in preparing for certifications such as ISO 27001. Transparency regarding the development status and close, ongoing coordination are not mere afterthoughts, but rather what makes the difference in KRITIS projects between a project that passes the audit and one that requires corrective action.

If you’d like to know how BAYOOTEC would approach your specific use case in a regulated environment, feel free to schedule an initial, no-obligation meeting to get to know each other. We’ll assess your needs, evaluate existing systems, and develop a concrete plan—without endless presentations, but with technical substance.