--- title: Critical infrastructure and utilities canonical: https://www.secnostic.com/en/solutions/infrastructure language: en dateModified: 2026-08-23 alternate-de: https://www.secnostic.com/de/solutions/infrastructure --- # Critical infrastructure and utilities - URL: https://www.secnostic.com/en/solutions/infrastructure - Audience: Asset overview for essential services - Positioning: Critical services in view secnostic shows which facilities, IT/OT systems, networks, and suppliers keep your critical services running. Operations and security see dependencies, maintenance risks, vulnerabilities, and response paths in one shared picture. **See distributed sites, and prove it** Distributed sites and long-lived control systems turn visibility itself into the security task. [NIS2](https://eur-lex.europa.eu/eli/dir/2022/2555) requires registration and risk management, the [national critical-infrastructure act](https://www.bundesregierung.de/breg-de/aktuelles/kritis-dachgesetz-2383682) adds physical resilience, and proving [attack detection](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/oh-sza.html) depends on a current picture of every asset and conduit. **Situation.** Utilities manage distributed sites, long-lived OT, supplier access, and narrow maintenance windows. Without a shared picture, incidents, patches, and vendor advisories become slow, expensive, and risky. **Challenges** - unclear dependencies between facilities, IT/OT networks, remote access, and suppliers - maintenance and changes without a reliable view of affected services, sites, and communication paths - aging components, firmware states, and vulnerabilities where it remains unclear what comes first - response under time pressure, when site, owner, access, and fallback path have to be found first **Approach.** secnostic brings observation, inventory, risk, lifecycle, access, and alerting into one place. Your team sees what runs where, why it matters, who owns it, and which change affects which service. **Outcomes** - faster root-cause work during incidents and advisories - maintenance and patches planned by affected service and zone - a clear order for vulnerabilities, EOL/EOS, and spare parts - auditable proof for NIS2 and critical-infrastructure duties **What a blind spot in critical services costs** In an incident, what counts is how fast you know what is affected, who owns it, and what must be proven. - **Unattended remote maintenance**: Supplier and maintenance access is a main entry point when purpose, owner, and approval are not recorded. - **Unknown dependencies**: Which asset carries which service, and across which zone, often becomes clear only when it fails. - **Missing attack detection**: Without dependable logging and detection, the required attack-detection maturity for the proof is missing. - **Evidence by hand**: Otherwise the proof for section 8a, NIS2, and auditors is assembled from spreadsheets just before the deadline. **From signal to evidence** Four steps that turn day-to-day operations into dependable evidence, instead of hunting for it before the audit. 1. **See** What runs at which site? The sensor and existing sources deliver assets, networks, and conduits across every site, passive-first with approval for active queries. 2. **Understand** What does the critical service depend on? The graph links assets, zones, owners, and remote access, so dependencies and operational impact become visible. 3. **Detect** Would an attack be noticed in time? Logging, detection, and response bring attack detection to the required maturity level, tied to real assets. 4. **Prove** Is the proof ready for the auditor? The section 8a proof, the 24h and 72h reports, and the conduit register all come from the same current data. **In practice, following the obligations** Recurring critical-infrastructure obligations become clear workflows that meet the real deadlines. - **Remote maintenance window**: Announce: A supplier requests a maintenance window for a facility at one site.; Check conduit: Purpose, owner, approval, and permitted paths of the access are in the model.; Watch: The sensor observes which devices and connections appear during the window.; Prove: Activity and changes stay traceable after the window closes. - **Reportable incident**: Detect: Attack detection fires and an event becomes security-relevant.; Scope it: The graph shows affected assets, services, sites, and dependencies at once.; Report in 24h: The early warning goes out on time, with a dependable scope instead of a guess.; Follow in 72h: The detailed report uses the same context, without gathering everything again. - **Prepare the section 8a proof**: Scope: Essential systems, processes, roles, and people are named in the model.; Measures: Risks, measures, and exceptions are anchored to real assets and zones.; Maturity: The state of attack detection is backed by logging and response.; Package: The proof is produced as one coherent record for the auditor. - **Register with BSI and BBK**: Capture: Critical facilities, services, and operator data are maintained in one place.; Reconcile: The same data carries the NIS2 registration with the BSI and the critical-infrastructure registration with the BBK.; Keep current: Changes to facilities and sites flow in continuously, not once a year.; Prove: Registration rests on dependable operating data instead of a snapshot. **Deployment steps** 1. **Observe**: Sensors, imports, and existing tools provide controlled observations from IT, OT, identity, cloud, remote access, and networks. 2. **Classify**: Assets are mapped to services, sites, facilities, zones, owners, suppliers, and maintenance windows. 3. **Assess**: Vulnerabilities, lifecycle, exposure, firmware states, and operational impact are prioritized in critical-service context. 4. **Plan**: Measures, exceptions, maintenance work, owners, and review dates stay connected to the affected assets, zones, and services. 5. **Respond**: Relevant events are routed to accountable people and documented with acceptance, escalation, history, and affected dependencies. **What becomes visible** - **Service and facility view**: Critical services, sites, facilities, operator responsibility, and technical dependencies are connected in one operating picture. - **OT zones and communication paths**: Zones, conduits, remote access, and transitions between IT, DMZ, OT, cloud, and suppliers become distinguishable. - **Maintenance and lifecycle**: Firmware states, vendors, EOL/EOS, spare-part needs, maintenance windows, and exceptions become tangible per service and site. - **Incident, measures, and evidence view**: Findings are evaluated by criticality, exposure, operational impact, owner, measure status, and evidence need. **FAQ** - Q: How does asset transparency help daily operations? A: Operations teams see faster which facility, system, supplier, and communication path belongs to a critical service. Incidents, maintenance work, vendor advisories, and handovers require less searching and fewer assumptions. - Q: Why is a classic asset list not enough? A: A list shows individual systems, but rarely service context, communication paths, operational impact, maintenance windows, remote access, and ownership. Control room, IT, OT, and suppliers need that context. - Q: How does secnostic reduce outage and response time? A: secnostic connects observations, assets, zones, risks, owners, and measures. During an incident or advisory, teams can see which services are affected, who must decide, and which next steps are sensible. - Q: Is evidence for NIS2 and critical infrastructure still covered? A: Yes. Operational context creates evidence from daily work instead of from a separate text collection: scope, assets, risks, measures, exceptions, owners, and review dates stay traceably connected. - Q: What is a sensible starting point? A: Start small and close to operations: one critical service, one site, one recurring maintenance topic, or one concrete vulnerability situation. Data sources, gaps, and prioritized measures can then expand in a structured way. **Sources** - [EU NIS2 directive](https://eur-lex.europa.eu/eli/dir/2022/2555): Consolidated text of EU Directive 2022/2555 (NIS2) on measures for a high common level of cybersecurity across the Union. - [German government KRITIS umbrella act](https://www.bundesregierung.de/breg-de/aktuelles/kritis-dachgesetz-2383682): German Federal Government article on the KRITIS umbrella act and cross-sector resilience requirements. - [German BSI-KritisV ordinance](https://www.gesetze-im-internet.de/bsi-kritisv/BJNR095800016.html): German ordinance defining critical infrastructure under the BSI Act in its current version. - [BSI B3S water and wastewater](https://www.bsi.bund.de/SharedDocs/Textbausteine/DE/KRITIS/B3S/Wasser/b3s-wasser-abwasser.html): BSI note on the sector-specific security standard for water and wastewater. - [BSI SzA guidance](https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KRITIS/oh-sza.html): BSI guidance on systems for attack detection (SzA) for critical infrastructure operators. - [CISA OT asset inventory guidance](https://www.cisa.gov/resources-tools/resources/foundations-ot-cybersecurity-asset-inventory-guidance-owners-and-operators): Joint agency guidance published in August 2025 on building an OT asset inventory with taxonomy, data management, and lifecycle maintenance. - [NIST SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final): NIST guide to operational technology and industrial control system security. - [ENISA Threat Landscape 2025](https://www.enisa.europa.eu/publications/enisa-threat-landscape-2025): ENISA report on the European threat landscape and observed attack trends.