Zero Assumptions · Week 10 of 25 · Pillar 2 closes: Software stack & contextual risk
Someone badged into your server room at 02:17.
Your SOC knows about it.
Your building access control system and your IT security stack are separate. The badge entry generated a log in one system. Your SOC monitors the other. The physical and logical access worlds have never shared a signal — and that gap is exactly where the most damaging insider threats and physical intrusions live.
|
|
Pillar 2 closes this week — Software stack & contextual risk
Weeks 6–10 have covered the operational layer that determines whether your identity controls actually work in practice: risk assessment gaps, session vulnerability, board accountability, signal isolation, and now the final gap — the physical/logical access divide. Pillar 3 begins next week: Hardware root of trust.
|
Last week we covered the signal isolation problem — how your EDR, SIEM, identity provider, and network monitoring tools each generate individually correct signals that never get correlated in real time. This week we address the most overlooked gap in that signal landscape: physical access.
The assumption that underlies almost every enterprise security architecture: physical security is a facilities management function. IT security handles logical access. The two disciplines operate independently, report to different parts of the organisation, and use different systems.
The reality: the most sophisticated attacks increasingly combine physical and logical access. A valid badge entry at 02:17 from a user whose cloud account authenticated from Stockholm at 02:09 is not a security event in either system independently. It is a critical incident — but only if the two systems share a signal.
|
34%
Of security breaches involve an insider threat component — either a malicious insider, a compromised employee credential used for physical access, or a social engineering attack that required physical presence. None of these are detectable from IT security tools alone.
Source: Verizon Data Breach Investigations Report 2024
|
The physical/logical access gap — three attack scenarios your current stack cannot detect
Each scenario below is a documented attack pattern. Each one generates signals in at least two systems. Neither system alone would classify it as a security event. Combined, each is a critical incident.
| Scenario |
Physical signal |
Logical signal |
Combined verdict |
| Stolen badge + cloned credential |
Valid badge entry, server room, 02:17 |
Same user authenticates to cloud from different country at 02:09 |
Critical — impossible for one person to be in two locations. Badge is stolen or cloned. |
| Tailgating into restricted zone |
Two people enter server room on one badge swipe at 14:33 |
Privileged data access spike from that zone 12 minutes later |
Critical — unauthorised physical presence correlates with data access event. |
| Malicious insider — data exfiltration |
Employee badges into office at 21:45 on a Sunday — no other staff present |
Large file transfer to personal cloud storage at 22:03 from same workstation |
Critical — out-of-hours physical access correlates with anomalous data movement. |
| Terminated employee access |
Badge deactivated in HR system but not in physical access control — entry succeeds |
IT account deprovisioned — no logical access possible |
Critical — terminated employee has physical but not logical access. Both systems must deprovision simultaneously. |
|
67%
Of organisations have no integration between their physical access control system and their IT security monitoring stack — meaning physical access events are invisible to the SOC unless an analyst manually reviews a separate badge system report. That report is typically reviewed weekly, not in real time.
Source: ASIS International — Security Convergence Report 2023
|
|
The blueprint — physical/logical convergence in three steps
Step 1 — Feed physical access events into your SIEM in real time: Most modern access control systems (Lenel, Genetec, Software House, Honeywell Pro-Watch) have syslog or API output. Connect the physical access log feed to your SIEM as a data source — not a weekly report. This is the minimum viable integration and requires no change to the physical access system itself. Once the feed is live, your existing correlation rules can reference physical events alongside logical ones.
Step 2 — Build cross-domain correlation rules around the four scenarios above: Impossible geographic presence, tailgating + data access, out-of-hours badge + file transfer, deprovisioning gap. Each of these can be expressed as a SIEM correlation rule in under an hour. The scenarios above are not edge cases — they are the most common physical/logical attack patterns in the breach data. Building rules for them is not advanced threat hunting, it is catching the obvious.
Step 3 — Unify deprovisioning across physical and logical access: When an employee leaves, both their IT account and their physical access credential must be deactivated in the same automated workflow — triggered by the same HR system event. A leaver who retains physical access for three days after their IT account is deprovisioned is an insider threat risk for exactly those three days. Automating both in a single lifecycle workflow eliminates the gap entirely.
|
Identity is the thread that runs through every regulation — and hardware keys are how you prove it
Over the past ten weeks we have covered ten different attack vectors and ten different compliance obligations. The common thread running through all of them is identity — specifically, the ability to prove, in real time and retrospectively, that the right person accessed the right resource at the right time using a credential that could not have been intercepted, replayed, or impersonated.
This is not an abstract principle. Every major regulatory framework that governs your organisation — NIS2, DORA, ISO 27001, SOC 2, GDPR, and for critical infrastructure NERC CIP — has at its core an authentication requirement. The question regulators ask in an audit is always a version of the same thing: can you prove who accessed what, when, using a credential that could not have been compromised?
Password-based MFA cannot answer that question. A phishable credential cannot answer that question. A hardware security key — anchored in asymmetric cryptography, physically bound to a certified chip, generating an unforgeable audit trail at every authentication event — is the only control that can.
| Regulation |
Authentication requirement |
Hardware key status |
| NIS2 Article 21 |
Multi-factor authentication — phishing-resistant implied for essential entities |
✓ Fully compliant |
| DORA Article 9 |
Strong authentication for all ICT systems — phishing-resistant MFA for privileged access |
✓ Fully compliant |
| ISO 27001:2022 A.8.5 |
Secure authentication — MFA required where technically feasible |
✓ Fully compliant |
| GDPR Article 32 |
Appropriate technical measures to ensure data security — authentication is a named control |
✓ Exceeds baseline |
| SOC 2 Type II CC6.1 |
Logical access controls — MFA for all systems in scope |
✓ Fully compliant |
| NERC CIP-007-6 |
System access controls for critical infrastructure — MFA for interactive remote access |
✓ Fully compliant |
|
NeoWave & Feitian — hardware keys that make compliance provable, not just claimable
NeoWave — the compliance anchor for regulated and sovereign environments
French-engineered, ANSSI Security Visa certified, CC EAL6+ secure element. FIDO2 for cloud and modern authentication, PIV for Windows domain and physical access control integration. NeoWave is the only hardware authentication device that satisfies both the NIS2 Article 21 phishing-resistant MFA requirement and the EU sovereign supply chain expectation that regulators in France, Germany, and the Nordics are increasingly applying to critical infrastructure operators. When your auditor asks for evidence of phishing-resistant MFA — and evidence that the supply chain of your authentication hardware is free from adversarial jurisdiction exposure — NeoWave answers both questions with a single document: the ANSSI Security Visa certificate.
The NIS2 compliance case: Article 20 (board approval of risk measures) + Article 21 (phishing-resistant MFA) + ANSSI certification = the most defensible authentication posture available to an EU essential entity today.
Feitian BioPass K49 — the compliance anchor for workforce-scale deployment
CC EAL6+ secure element — the highest assurance level in production authentication hardware. On-device fingerprint verification: the template never leaves the chip, authentication is user-bound not device-bound. FIDO2 + PIV across cloud, on-premises, and physical access control — the unified identity anchor that closes the physical/logical gap we covered this week. PQC-ready via dedicated ML-KEM/ML-DSA co-processor, satisfying the forward-looking cryptographic requirements in the EU's COM(2026) 13 PQC transition policy and DORA's long-term digital resilience mandate. The biometric binding addresses the SOC 2 and ISO 27001 requirement for authentication that proves user identity, not just device possession — a distinction that matters in a SOC 2 Type II audit when the auditor asks whether a shared workstation with a plugged-in key constitutes compliant access control.
The workforce compliance case: NIS2 Article 21 + DORA Article 9 + ISO 27001 A.8.5 + SOC 2 CC6.1 + PQC-readiness = the most complete compliance coverage available at scale, with biometric proof of user identity at every authentication event.
|
|
Pillar 2 complete — what we covered in Weeks 6–10
Week 6 — Risk assessment integration: Identity drift is invisible between assessment cycles. Continuous monitoring catches what annual tests miss.
Week 7 — Session token vulnerability: 207 days to detect, 50% of incidents at the weekend. CAE and device-bound tokens close the window.
Week 8 — Boardroom accountability: NIS2 Article 20 personal liability. Five documents every CISO must deliver to their board.
Week 9 — Signal orchestration: Your tools see the same attacker — in isolation. One entity anchor across every tool fixes the correlation problem.
Week 10 — Physical/logical convergence: The badge entry your SOC never saw. Convergence closes the final signal gap.
Week 11 (next — Pillar 3 begins): Hardware root of trust. Not all security anchors are equal — and the chip inside your key determines everything about what you can actually prove to a regulator.
|
Next week — Pillar 3 begins: Hardware root of trust
Week 11 — The chip is the control
Everything we've covered in Pillars 1 and 2 assumes there is a trustworthy hardware credential at the base of the identity stack. Week 11 asks: what does "trustworthy" actually mean at the chip level? What is a secure element, what does CC EAL6+ certification test for, and why does the answer determine whether every other control in your stack is actually standing on solid ground?
Week 12 — Post-quantum readiness
Harvest Now, Decrypt Later attacks are already in progress. The credentials your organisation issues today will still be in circulation when quantum computers can break RSA and ECC. The window to transition is closing faster than most procurement cycles can move.
|
Free passwordless audit
Can you prove — to a regulator, today — who accessed what, when, using a credential that could not have been compromised?
In a free 30-minute passwordless audit we'll map your current authentication stack against your regulatory obligations — NIS2, DORA, ISO 27001, SOC 2 — identify the specific gaps between what you have deployed and what each framework requires you to prove, and show you what a hardware key deployment looks like operationally for your environment.
No sales deck. No follow-up unless you ask.
|
Ten weeks. Ten assumptions. Every single one of them had the same fix at its foundation: a hardware credential that proves identity — not just device possession, not just knowledge of a password, but cryptographic proof that the right person authenticated from the right device. The regulations have caught up with the attackers. The question is whether your authentication stack has too.
Mikael Rodin
Managing Director, Ciptor
P.S. If you've read all ten volumes and still have SMS OTP or push notification MFA as your primary control — book a free audit. We'll map exactly which of your regulatory obligations are currently unmet and what it takes to close each one. No pitch. Just the gap analysis.
New to the series? Start at ciptor.com/zero-assumptions/zero-assumptions-vol-1/