TL;DR: Russian cyberattacks against Polish critical infrastructure are described by Anomali as part of a longer pattern spanning power grids, energy, transport, and destructive malware such as NotPetya, with implications that extend beyond Poland to any operator facing state-linked pressure. The central lesson is that resilience, segmentation, and identity hardening matter more than assuming attacks will stay contained or purely espionage-focused.
NHIMG editorial — based on content published by Anomali: Poland's Critical Infrastructure Under Threat: Lessons Learned
By the numbers:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: What breaks when vendor access is not tightly controlled in critical infrastructure?
A: The main failure is loss of accountability and excessive blast radius.
Q: Why do service accounts increase risk in cloud and legacy environments?
A: Service accounts increase risk because they often carry broad privileges, are embedded in applications, and are hard to rotate without breaking dependencies.
Q: How do organisations know if branch segmentation is actually working?
A: Branch segmentation is working only if teams can prove that devices can communicate solely with the systems they need and nothing else.
Practitioner guidance
- Harden remote access into critical networks Require strong MFA for all administrative and vendor pathways, and separate business access from operational access so one compromise does not cross both zones.
- Inventory and review service accounts monthly Track every service account, API key, and shared credential that can reach OT-adjacent systems, then rotate or remove anything without a current owner.
- Reduce blast radius with identity-based segmentation Limit engineering, supplier, and emergency-access accounts to the smallest set of systems required, and verify that conditional access is enforced before OT administration begins.
What's in the full article
Anomali's full article covers the operational detail this post intentionally leaves for the source:
- Source-linked breakdown of the 2015, 2016, 2017, and 2022-present attack patterns against Poland and neighbouring states
- Practical recommendations for MFA, service account governance, vulnerability assessment, and incident response planning
- Operational guidance for protecting ICS, SCADA, and other critical infrastructure systems from state-linked intrusion
- Source citations and references that map the historical pattern to named incidents and public threat reporting
👉 Read Anomali's analysis of Poland's critical infrastructure threat pattern →
Poland critical infrastructure attacks: what defenders should re-evaluate?
Explore further
Critical infrastructure compromise is an identity problem before it becomes an availability problem. State-linked campaigns still depend on remote access, trusted vendors, and privileged accounts to move from perimeter contact into operational environments. That means the first failure is usually governance of who and what is allowed to authenticate, not the final payload. Practitioners should treat access pathways as part of resilience engineering, not just security administration.
A question worth separating out:
Q: Who is accountable when a supplier pathway leads to critical infrastructure exposure?
A: Accountability sits with the operator, not just the supplier, because the operator owns the trust model, access approvals, and monitoring expectations. Frameworks such as the NIST Cybersecurity Framework place governance and risk ownership on the organisation that depends on the service. Suppliers matter, but delegated access still needs explicit lifecycle control and review.
👉 Read our full editorial: Poland critical infrastructure attacks expose the limits of deterrence