System topology & NIS2-compliant architecture
qyra is designed as a secure, modular system architecture. The platform runs containerized in a Docker environment or, alternatively, on dedicated Windows or Linux servers. This flexible deployment strategy enables both on-premises installations and operation in certified data centers.
At the heart of the system topology is a real-time database. It ensures consistent processing, storage, and synchronization of all operational, control, and status data. The architecture is designed to be operated with high availability, scalability, and fault tolerance.
Architecture overview
qyra as software/application is preferably operated as a Docker container and can also be run as a Windows or Linux service, depending on the deployment scenario.
qyra is composed of the following components:
- Real-time database (event processing, state management)
- Integrated PLC (IEC 61131-3)
- Web server for visualization (SCADA) and programming / configuration
- User management with role-based access control (AD, SSO)
- Database layer for connecting SQL and NoSQL databases
- Driver Abstraction Layer
The Driver Abstraction Layer enables standardized integration of a wide range of hardware and communication protocols, including:
- OPC UA (incl. security profiles)
- BACnet Secure Connect
- Modbus (secured with TLS)
- other industrial protocols
This clear separation of layers reduces attack surfaces and enables a clean separation between the IT and automation levels.
Cyber threat model for building automation
Building and infrastructure systems are now highly networked cyber-physical systems. Attacks are not limited to IT, but directly affect operations, safety, and availability. Manipulation can impair comfort, energy efficiency, production processes, or even people’s safety.
Relevant threat scenarios include, among others:
- Manipulation of field devices and control loops
- Insider attacks via service, maintenance, or supply chains
- Misuse of insecure or unauthenticated protocols
- Sabotage through malware, faulty updates, or third-party software
- Failure of central services such as network, cloud, or management systems
NIS2 requires these risks to be assessed systematically—not only organizationally, but also architecturally.
Why traditional OT architectures are no longer sufficient
Traditional OT architectures often rely on implicit trust within the network. Anyone with access is considered authorized. Under today’s threat assumptions, this model is no longer viable.
A lack of separation of functions, unclear responsibilities, and limited traceability mean that security measures are often implemented only reactively. This is exactly where QYRA comes in: not through additional protective layers, but through a fundamentally secure system architecture.
NIS2 requires these risks to be assessed systematically—not only organizationally, but also architecturally.
QYRA risk reduction through architecture
QYRA reduces security risks not selectively, but structurally. Key principles include:
- clear separation of control, visualization, and management
- role-based access concepts instead of blanket network approvals
- full traceability of all changes and configurations
- automated recovery and rollback processes
Security is achieved not through trust, but through transparency, control, and repeatability—across planning, implementation, and operations.
Protocol and zone strategy based on NIS2 logic
QYRA follows a clear protocol and zone strategy aligned with modern security requirements.
Preferred protocols:
- OPC UA: security by design with certificates, role models, and auditability
- EtherCAT: deterministic real-time communication within a clearly delineated OT domain
Traditional protocols such as BACnet or KNX can still be integrated, but only within defined security zones and with additional protective measures. This keeps existing systems usable without compromising security requirements.
Audit, compliance, and management benefits
QYRA supports key requirements from NIS2, ISO/IEC 27001, and the GDPR directly in the system design:
- Access control through role models and multi-factor authentication
- Traceability via Git-based versioning, journals, and logging
- Resilience through redundancy and automated recovery
- Incident response support through alerting and recovery
For management, this means:
- reduced liability and operational risks
- improved audit and reporting capability
- lower organizational effort
- a sustainable, future-proof architecture
