KRITIS Firewall Compliance: Essential Requirements for German Critical Infrastructure
KRITIS firewall compliance represents one of the most demanding cybersecurity requirements facing German organizations. If you operate critical infrastructure — energy, water, healthcare, transport, food, finance, telecommunications, or IT — the BSI holds you to a higher standard than standard enterprise security. Your firewall infrastructure must not only protect your network but also provide comprehensive documentation that proves compliance at any point in time.
What Makes KRITIS Different
KRITIS (Kritische Infrastrukturen) regulations under the IT-Sicherheitsgesetz 2.0 go beyond standard security best practices. While frameworks like ISO 27001 provide a general security management system, KRITIS demands specific, measurable controls with evidence of implementation:
- Strict IT/OT Separation: Critical infrastructure operators must demonstrate clear network segmentation between IT and OT environments, with documented firewall rules governing all cross-zone traffic.
- Complete Change Documentation: Every firewall change must have a full audit trail — request, justification, risk assessment, approval, implementation, and verification — with records retained for audit.
- Extended Log Retention: Firewall logs must be retained for a minimum of 90 days, with the ability to provide them to the BSI upon request.
- 24/7 Monitoring: KRITIS operators must implement continuous monitoring of network security controls, including real-time alerting on firewall policy violations and unauthorized changes.
- Biennial Audits: KRITIS operators must demonstrate compliance through audits conducted every two years by BSI-approved auditors, with evidence of all controls submitted.
The 5 Essential KRITIS Firewall Requirements
Based on BSI standards and the IT-Sicherheitsgesetz 2.0, KRITIS firewall compliance centers on five essential requirements:
1. Network Segmentation and Zone Architecture
KRITIS operators must implement a zone-based network architecture with documented security boundaries. At minimum, this means separate zones for IT, OT, DMZ, management, and external connectivity — with firewall rules explicitly controlling traffic between each zone.
Every cross-zone rule must have a documented business justification. “Any-to-any” rules between zones are immediate audit failures. The zone architecture must be documented in network diagrams that are updated whenever changes occur.
Key evidence: Zone architecture document, network diagrams, cross-zone rule inventory with justifications, segmentation test results.
2. Change Management Documentation
Every firewall change in a KRITIS environment must follow a formal change management process. This is not optional and it is not flexible — auditors will review change records in detail. The process must include request documentation, risk assessment, multi-level approval, implementation records, and post-implementation verification.
Emergency changes are permitted but must have a documented emergency change procedure with mandatory post-implementation review within 48 hours.
Key evidence: Change management policy, individual change records, approval chains, emergency change procedures, post-implementation reviews.
3. Logging and Retention Requirements
KRITIS mandates a minimum 90-day retention period for firewall logs. These logs must capture all allowed and denied traffic, administrative access, configuration changes, and policy modifications. Logs must be stored in a tamper-proof manner and be available for forensic analysis.
Log integrity is critical. BSI auditors will verify that logs cannot be modified or deleted by administrators. This typically requires forwarding logs to a separate SIEM or log management system with write-once storage.
Key evidence: Log retention policy, SIEM configuration, log integrity verification, sample log exports, storage capacity planning.
4. Incident Detection and Response
KRITIS operators must detect security incidents within their firewall infrastructure and respond according to documented procedures. This includes monitoring for unauthorized rule changes, detecting anomalous traffic patterns, and alerting on policy violations.
Incident reports must be submitted to the BSI without undue delay — significant incidents within 24 hours. The incident response process must be tested regularly through exercises and the results documented.
Key evidence: Incident response plan, monitoring configuration, alert rules, incident reports, exercise records, BSI notification templates.
5. Regular Security Assessments
Firewall configurations must be assessed regularly for security effectiveness. This includes periodic rulebase optimization to remove shadow rules, redundancies, and overly permissive policies. Penetration testing of the firewall infrastructure must be conducted at least annually.
The biennial KRITIS audit will specifically review the results of these assessments and the actions taken in response to findings.
Key evidence: Assessment reports, rulebase analysis results, penetration test reports, remediation tracking, trend data showing improvement.
Common KRITIS Audit Failures
Based on patterns from KRITIS audits, these are the most common firewall-related findings:
- Missing business justifications. Firewall rules exist without documented reasons for their existence. This is the single most common finding.
- Incomplete change records. Changes were made to firewall configurations without following the documented change management process — or the process was followed but records are incomplete.
- Insufficient OT/IT segmentation. Traffic flows between OT and IT zones that are not explicitly documented and justified. Overly broad rules that allow unnecessary communication between zones.
- Log retention gaps. Logs are not retained for the full 90-day minimum, or log integrity cannot be demonstrated because logs are stored on the same system they originate from.
- No evidence of regular reviews. There is no documented evidence that firewall rules are reviewed periodically. Rules from years ago remain in place without any record of re-validation.
- Emergency changes without follow-up. Emergency firewall changes were made during incidents but never retroactively reviewed and formally approved.
- Outdated network diagrams. The documented network architecture does not match the actual firewall configuration. Diagrams show zones and connections that no longer exist, or miss new ones.
How FwChange Supports KRITIS Compliance
Meeting KRITIS firewall requirements manually is possible but requires significant effort. Automation eliminates the most common audit failures by enforcing process discipline:
- Mandatory Business Justification: Every change request requires a documented business justification before it enters the approval workflow. No justification, no change.
- Complete Audit Trail: Every step of the change process — request, validation, approval, implementation, verification — is automatically logged with timestamps, user identities, and full context.
- Multi-Level Approval: Configurable approval workflows that route changes based on risk level, zone criticality, and organizational policy. Supports the multi-level approval chains KRITIS auditors expect.
- Automated Rule Analysis: Built-in rule analysis detects shadow rules, redundancies, and conflicts across your entire multi-vendor fleet.
- Compliance Reporting: Generate audit-ready reports that map directly to KRITIS requirements, including rule inventories, change histories, and review evidence.
If you operate critical infrastructure and need to demonstrate KRITIS compliance, start with a free rulebase audit to identify your current documentation gaps.
Frequently Asked Questions
Who qualifies as a KRITIS operator?
KRITIS operators are organizations that provide essential services in sectors defined by the BSI-KritisV ordinance: energy, water, food, IT and telecommunications, healthcare, finance, and transport. The qualification is based on specific thresholds (e.g., serving more than 500,000 people). Approximately 1,600 organizations currently qualify as KRITIS operators in Germany.
How does KRITIS relate to NIS2?
KRITIS predates NIS2 and covers a narrower set of organizations. When the NIS2 transposition (NIS2UmsuCG) takes effect, KRITIS operators will need to comply with both frameworks. In practice, KRITIS requirements are generally stricter than NIS2, so KRITIS-compliant organizations will largely meet NIS2 requirements as well.
What happens if we fail a KRITIS audit?
The BSI can issue binding instructions requiring specific remediation actions within defined timelines. Failure to comply can result in fines of up to EUR 2 million under the IT-Sicherheitsgesetz 2.0. The BSI can also require the organization to engage external auditors for follow-up verification at the organization’s expense.
Do we need a specific firewall vendor for KRITIS?
No. KRITIS requirements are vendor-neutral. Whether you run Palo Alto, Fortinet, Check Point, or any other combination of vendors, the compliance requirements are the same. What matters is the documentation, process, and evidence — not the specific technology.
How often are KRITIS audits conducted?
KRITIS operators must demonstrate compliance every two years through audits conducted by BSI-approved auditors. The audit results are submitted to the BSI, which can request additional information or conduct its own inspections.
See How Your Firewall Rules Score
Upload your config and get a free compliance report with shadow rule detection, conflict analysis, and optimization recommendations.
Stay Updated
Get firewall management tips, compliance guides, and product updates.
No spam. Unsubscribe anytime.