title: "Building BSI's MIP: Germany's National Cybersecurity Incident Reporting Portal" slug: bsi-mip-cybersecurity-incident-reporting-platform
The incident reporting state machine had seven states and twelve transitions. Every transition was a legal event under NIS2 Article 23 — miss the 24-hour initial notification window and the reporting organisation is non-compliant. We couldn't use a standard workflow library because the audit trail requirement was stricter than anything an off-the-shelf solution provides: every state change had to be appended to an immutable log with a timestamp, the identity of the triggering user, and an explicit reason code. No soft deletes. No timestamp overwrites. A tamper-evident record for every action.
That constraint shaped the entire backend architecture. It also meant that every edge case in the state machine — a report submission at 23:58 on a Friday, an organisation with delegation chains across subsidiaries, an anonymous voluntary report from an entity that later wants to claim it — had to be handled correctly the first time. There is no patch-it-later option on federal cybersecurity infrastructure.
The BSI Melde- und Informationsportal (MIP) is the central digital gateway through which operators of critical infrastructure, NIS2-regulated entities, telecommunications providers, and government authorities in Germany submit mandatory security incident reports and register as regulated entities. For BSI analysts, it is also the primary instrument for constructing Germany's national threat picture.
Who the BSI Are
The Bundesamt für Sicherheit in der Informationstechnik — BSI — is Germany's central federal cybersecurity authority, founded in 1991 and headquartered in Bonn. It operates the national cyber emergency response team CERT-Bund, conducts threat intelligence analysis, issues security warnings, certifies IT products, and sets binding IT security standards including the internationally recognised IT-Grundschutz methodology.
The EU's NIS2 Directive, implemented in Germany in late 2024, significantly expanded the BSI's regulatory mandate. Thousands of organisations across previously unregulated sectors — manufacturing, food supply, waste management, digital infrastructure — are now required to register with the BSI and comply with 24-hour incident reporting obligations. The MIP is the technical infrastructure through which that regulatory expansion became operationally possible.
The Problem
The predecessor to the MIP was a legacy system that was not built for the scale or the compliance precision that NIS2 demanded. Incident reports were being submitted through channels — email, fax, phone — that produced no structured data, no verifiable submission timestamps, and no audit record that satisfied the documentation requirements of Article 23.
The NIS2 reporting timeline is strict: an initial notification must be submitted within 24 hours of detecting a significant incident. A detailed report follows within 72 hours. Monthly progress updates are required for ongoing incidents. A final closure report closes the submission. Each of these deadlines is enforceable. Missing them is not a procedural failure — it is a regulatory violation.
For an authority receiving incident reports from potentially thousands of entities across dozens of sectors, the challenge is not just building a form — it is building a workflow that enforces those timelines automatically, notifies reporters of approaching deadlines, tracks the state of every open incident across the system, and produces an audit record that would withstand legal scrutiny.
The other major requirement: anonymous voluntary reporting. Many organisations want to contribute threat intelligence to the BSI's national picture without formally registering as regulated entities. The platform had to support completely anonymous submissions alongside authenticated mandatory reports, in the same system, without the anonymous pathway compromising the security model of the authenticated one.
The security requirements were not negotiable: end-to-end encryption of report payloads, database-level AES-256 encryption at rest, tamper-evident audit logging, OWASP Top 10 mitigations, and penetration testing by BSI-certified auditors. The platform runs in Germany's federal cloud infrastructure (Bundescloud) with an on-premise HSM for key management.
What We Built
The MIP is a government-grade web platform built on Angular and TypeScript on the frontend, Java Spring Boot microservices on the backend, Keycloak for authentication (OpenID Connect and SAML 2.0), and a custom state-machine incident workflow engine. Everything runs in Bundescloud with Kubernetes orchestration, and encryption keys are managed by an on-premise HSM that never leaves federal infrastructure.
The platform serves three distinct user groups: reporting organisations — KRITIS operators, NIS2-regulated entities, telecommunications providers — who submit mandatory incident reports and manage their registration; anonymous voluntary reporters who contribute threat intelligence without an account; and BSI analysts who review incoming reports, manage escalation, and extract aggregated intelligence for the national threat picture.
The incident workflow covers the full NIS2 Article 23 lifecycle: initial 24-hour notification → 72-hour detailed report → monthly progress updates → final closure. Each stage is independently timestamped in the audit log. BSI analysts receive aggregated reports and can escalate priority incidents to CERT-Bund integration directly from the incident record.
Alongside mandatory reporting, the platform handles: organisation registration and identity verification for regulated entities, multi-user account management with delegation of reporting rights, and encrypted PGP/S-MIME notifications to reporters on every status change and BSI feedback event.
How We Built It
The NIS2 Incident State Machine
The state machine is the central architectural decision of the backend. Incident reports exist in one of seven states: initial_submitted, initial_accepted, detailed_submitted, detailed_accepted, progress_update, closure_submitted, closed. Transitions between states are triggered by user actions (report submissions, BSI acceptance decisions) or by automated deadline events.
Every transition is an append operation to the audit log — never an update to existing records. The current state of any incident is derived by replaying the log sequence, not by reading a status field that could be overwritten. This means the complete history of every incident is preserved exactly as it occurred, with BSI analyst intervention — reclassification, escalation, comment — appearing as distinct log entries rather than mutations to the original submission.
We used a Java-based custom state machine framework rather than an off-the-shelf workflow engine because the commercial options available either (a) stored state as mutable fields or (b) had audit logging that satisfied generic enterprise requirements but not the specific tamper-evidence requirements of federal cybersecurity infrastructure. The custom implementation added six weeks to the backend build. The alternative — discovering during the penetration test that the audit trail was insufficient — would have been worse.
Keycloak for Multi-Entity Identity
Reporting organisations range from sole-practitioner telecommunications providers to major KRITIS operators with hundreds of staff across multiple subsidiaries. The identity model had to support: single accounts for small reporters, multi-user organisation accounts with admin-controlled role delegation, and complex subsidiary structures where a parent organisation manages reporting for multiple legally distinct entities.
Keycloak handles this through a custom realm configuration: organisations are modelled as Keycloak groups with hierarchical membership. An organisation admin can create user accounts, assign reporting roles, and delegate rights to subsidiaries — all without BSI involvement. ELSTER-compatible organisation identity (the German tax authority's electronic identity system) provides the entity verification anchor for German-registered organisations.
Two-factor authentication is mandatory for all authenticated sessions. Session tokens are short-lived and non-persistent. Authenticated and anonymous pathways are technically separated at the infrastructure level — anonymous submissions enter through a separate, stateless API endpoint that has no access to the authenticated data store.
Encrypted Report Payloads
Incident reports contain sensitive operational data: specific vulnerabilities exploited, affected systems, impact scope, mitigation actions taken. This information — if intercepted or leaked — could aid further attacks against the already-compromised organisation. End-to-end encryption of report payloads was mandatory.
Report payloads are encrypted client-side before submission using a public key published by the BSI. Only BSI analysts with access to the corresponding private key — stored in the on-premise HSM — can decrypt submitted reports. The encrypted payload is stored in the database and transmitted over TLS; even a database breach or a TLS interception does not expose report contents. PGP/S-MIME encrypted email notifications ensure that even BSI feedback to reporters is protected in transit.
What Made It Hard
1. Anonymous Submissions Without Compromising the Authenticated System
The anonymous voluntary reporting pathway is one of the most valuable features for the BSI's threat intelligence mission: organisations that aren't legally required to report — or that are legally required but choose to contribute additional intelligence anonymously — represent a significant source of early warning signal.
The security challenge: anonymous submissions must be completely unlinkable to any account or identity, while still being routed correctly into the BSI's intake pipeline. A naive implementation would still capture metadata — IP address, session identifiers, submission timing — that could be used to correlate anonymous reports with known reporters.
The anonymous pathway is served from a separate infrastructure endpoint with no session state, no logging of source IP at the application layer, and no cookies. Submissions receive a randomly generated reference ID on receipt — not linked to any account — that the submitter can use to follow up via the same anonymous channel. BSI analysts see anonymous reports flagged in their queue but with no metadata that enables attribution. The two pathways are technically isolated: a breach of the authenticated system doesn't expose the anonymous submission queue, and vice versa.
2. Deadline Enforcement on a 24-Hour Regulatory Window
The 24-hour initial notification deadline is the hardest operational constraint in the system. An organisation detecting a significant incident at 2am on a public holiday has the same 24-hour window as one detecting during business hours. The platform has to notify them of the deadline, remind them as it approaches, and record whether they met it — with the timestamp that would appear in any subsequent regulatory review.
We implemented deadline tracking at the state machine level: on initial report creation, the system calculates the submission deadline and schedules two automated notifications — at 12h remaining and at 6h remaining. Deadline state is recorded at the moment of report submission, not when BSI processes the report. If a reporter submits their initial notification at 23h 58m after detection, that's recorded as compliant. If they submit at 24h 02m, the record shows non-compliant. The timestamp in the audit log is final.
The practical implication: the system clock synchronisation had to be treated as a security-sensitive function. Clock drift that caused a compliant submission to be recorded as non-compliant — or vice versa — would create a record with legal consequences for the reporting organisation. We implemented NTP synchronisation with monitoring and alerting for drift beyond 100ms, with the audit log timestamping derived from server time, not client time.
3. Penetration Testing on Government Infrastructure
The BSI MIP was penetration tested by BSI-certified auditors before launch and at annual intervals thereafter. This is not a compliance checkbox — the BSI is a cybersecurity authority, and a breach of their own incident reporting platform would be both a security failure and a reputational catastrophe.
The penetration test scope covered the full attack surface: the authenticated application, the anonymous submission endpoint, the Keycloak realm, the API layer, the Kubernetes cluster configuration, and the encrypted notification pipeline. The pre-launch test identified six findings. None were critical, but two were significant: a SSRF vector in the notification pipeline's URL validation logic, and an information disclosure in the Keycloak error responses that revealed valid usernames. Both were remediated before launch.
This is the most useful thing I can say about building on government infrastructure: treat the pen test as the primary correctness check, not the final step. We built with the assumption that everything would be tested thoroughly and that findings would require remediation before launch. The six-week buffer between development completion and go-live that we had originally planned as contingency was almost entirely consumed by pen test remediation and retest.
What Changed
The MIP launched and became the primary channel for NIS2-mandated incident reporting in Germany. Organisations that previously reported via email or phone now submit through a structured workflow that produces timestamped, auditable records at each stage. The anonymous voluntary pathway has contributed to BSI's early warning intelligence in the months following launch, with anonymised indicators of compromise flowing into the national threat picture through the same platform.
The MLR-equivalent outcome: the percentage of incident reports that arrive in a structured, parseable format has increased substantially relative to the legacy system. BSI analysts spend less time normalising unstructured data and more time on triage and response.
What's Next
The roadmap includes NLP-based automated incident classification — using the report text to pre-classify attack vector, affected sector, and severity before a human analyst reviews; STIX/TAXII integration for automated sharing of anonymised indicators of compromise with ISAC partners across EU member states; and API linkage with ENISA and member state CERTs for pan-European situational awareness aligned with the NIS2 Article 27 cooperation framework.
Common Questions About Government Cybersecurity Platform Development
What does NIS2 Article 23 require for cyber incident reporting?
NIS2 Article 23 requires operators of essential and important entities to notify their national cybersecurity authority of significant incidents within 24 hours of detection (initial notification), submit a detailed report within 72 hours (with impact scope, indicators of compromise, and preliminary cause), provide monthly progress updates for ongoing incidents, and submit a final closure report on resolution. Each deadline is independently enforceable. The MIP automates the workflow and records deadline compliance timestamps that would appear in regulatory proceedings.
Why does government cybersecurity infrastructure use on-premise HSMs rather than cloud key management?
Cloud key management services route cryptographic operations through provider-managed infrastructure. For national security applications — where the keys protect incident reports from critical infrastructure operators — the risk model is different: a cloud provider compromise or compelled disclosure could expose the entire corpus of sensitive reports. An on-premise HSM running in federal infrastructure means private keys never leave physically controlled German federal systems, regardless of what happens to cloud infrastructure.
What is the difference between mandatory incident reporting and voluntary reporting on the MIP?
Mandatory reporting is required by NIS2 for registered essential and important entities. It uses authenticated accounts, attribution to a legal entity, and the full five-stage NIS2 workflow. Voluntary reporting allows any organisation — including those not covered by NIS2 — to contribute threat intelligence anonymously without registration. The two pathways are technically isolated: voluntary reports receive a random reference ID with no metadata that enables attribution, and they're processed by BSI analysts through a separate intake queue that has no connection to the authenticated system.
How do you build tamper-evident audit logging without a blockchain?
Tamper-evidence doesn't require blockchain — it requires append-only storage with hash chaining. Each audit record contains a hash of the previous record's content, so any retroactive modification breaks the chain. The chain is independently verifiable at audit time by replaying the hash sequence. For the MIP, audit records are stored in an append-only database partition with access controls that prevent any application-layer deletion or update — only insert operations are permitted. The hash chain verification runs on every audit export and on-demand during BSI internal reviews.
Building on government infrastructure compresses every mistake's consequence. A security finding that would be a remediation sprint in a SaaS product is a launch blocker on a federal cybersecurity platform. The 24-hour deadline that would be a nice-to-have for a commercial workflow is a legally enforceable obligation that must be recorded correctly in a permanent record.
The architectural decisions that distinguished this project from a standard enterprise workflow system — the append-only state machine, the anonymous pathway isolation, the on-premise HSM, the clock synchronisation monitoring — were all responses to consequence, not to technical preference. When the cost of getting it wrong includes both regulatory failure and a security breach of the authority that issues Germany's cybersecurity certifications, the engineering bar is simply different.
We've applied similar compliance-first architecture to Sandoz's global pharma web portal where MLR regulatory workflows constrained every content publishing decision, and to financial services RegTech compliance tooling. If you're building in a regulated environment where the compliance architecture has to come before the product architecture, get in touch.