Why do KRITIS programmes need both physical and identity controls?

Physical resilience limits direct disruption, but identity controls determine who can see, change, or recover the systems that keep critical services running. Without strong authentication and privileged access governance, a physical incident can become a broader operational failure because recovery paths are exposed or misused.

Why This Matters for Security Teams

KRITIS environments depend on two protection layers that are often managed separately: physical safeguards around sites, equipment, and personnel, and identity safeguards around access to systems, consoles, and recovery tooling. That separation becomes risky when an incident crosses the boundary between the plant floor and the access layer. A locked facility does not help if a valid administrator can approve unsafe changes remotely, and strong IAM does not help if an intruder can reach unprotected cabinets, network panels, or backup media. NIST SP 800-53 Rev 5 Security and Privacy Controls remains a useful reference point for mapping both access and facility-related controls into one governance view.

Security teams sometimes treat physical security as facilities’ responsibility and identity security as IT’s responsibility, but KRITIS operations usually fail at the seam between those functions. Recovery accounts, vendor access, emergency overrides, and remote maintenance paths are especially sensitive because they often receive exceptions that are never revisited. In practice, many security teams encounter that weakness only after an outage, sabotage attempt, or restoration exercise has already exposed how many critical actions were still reachable through weak identity governance, rather than through intentional resilience design.

How It Works in Practice

Effective KRITIS programmes connect site protection, trusted personnel processes, and privileged access governance into one operating model. The physical side reduces the likelihood that an attacker, insider, or accidental event can reach sensitive assets. The identity side ensures that even if someone reaches a control room, server rack, engineering workstation, or remote operations platform, they still cannot alter critical systems without proper authorisation, logging, and approval.

Practically, this means binding access to role, location, time, and task. A maintenance engineer may need entry to a substation, but that does not mean the same person should hold standing administrative access to configuration tools. Likewise, a recovery operator may need emergency privileges during an outage, but those privileges should be time-bound, monitored, and removable. Where remote operations are involved, current guidance suggests combining strong authentication with privileged access management, session recording, and segmented access paths so that emergency use does not become permanent exposure.

• Use strong authentication for remote administration and recovery functions, not just for ordinary user accounts.
• Separate physical entry approvals from system change approvals so one clearance does not imply the other.
• Apply least privilege to operators, contractors, and vendors, especially where shared systems support multiple sites.
• Review break-glass accounts, badge exceptions, and emergency access after every drill or incident.
• Log and correlate physical events with identity events so investigations can reconstruct both sides of an intrusion.

These controls align well with the access and monitoring principles in NIST SP 800-53 Rev 5 Security and Privacy Controls, particularly where organisations need to prove that recovery capability does not create uncontrolled privilege. The challenge is not only stopping unauthorised access, but ensuring that legitimate emergency access remains bounded, visible, and revocable. These controls tend to break down when legacy operational technology is administered through shared local accounts because accountability and traceability disappear at the exact moment they are most needed.

Common Variations and Edge Cases

Tighter physical and identity controls often increase operational friction, requiring organisations to balance resilience against speed, staffing, and continuity demands. That tradeoff is real in KRITIS environments where 24/7 availability matters, but it does not justify permanent exceptions.

There is no universal standard for every KRITIS sector, so implementation depends on the threat model and the operating environment. For some sites, the priority is visitor control, badge integrity, and secure zones. For others, the greater risk is remote compromise of engineering workstations or privileged cloud portals that can still affect physical processes. Identity controls must therefore extend to remote support, third-party maintenance, and emergency restoration paths, not only to office IT accounts.

Where a programme uses shared vendor access or temporary disaster recovery credentials, best practice is evolving toward tighter just-in-time issuance and stronger approval workflows, but the practical baseline remains clear: physical access should never imply automatic digital trust, and digital privilege should never bypass physical safeguards without explicit control. KRITIS teams that ignore this relationship usually discover the gap when a routine maintenance action becomes an incident response exercise, or when a site recovery succeeds technically but fails governance review. For broader resilience planning, the physical control model should also be aligned with NIST SP 800-53 Rev 5 Security and Privacy Controls so access, audit, and recovery expectations stay consistent across both worlds.

Related resources from NHI Mgmt Group

• Why do workload identity programmes still need authorisation controls if SPIFFE is in place?
• Why do identity controls matter so much in CMMC programmes?
• Why do identity programmes often leave service accounts exposed even when user controls are mature?
• How do identity controls fit into broader compliance and audit programmes?