Physical Access Convergence
Volume. 15 · 6 min read · Why your badge and your token are still two different things — and why that's a control gap
See how this applies to your environment
Book a 30-minute briefing with Ciptor. We'll walk through what live-fire validation typically uncovers in environments like yours.
Closing the last gap in your hardware identity architecture
Volumes 11–14 covered the chip-level security properties that make hardware tokens the correct authentication primitive, the supply chain criteria that determine which tokens can be trusted, biometric binding as a deployment-time control, and token lifecycle governance as the operational discipline that prevents ghost credentials. Vol. 15 closes with the architectural question those four volumes were building toward: what happens when you extend that same hardware root of trust to control physical entry as well?
THE ASSUMPTION
Legacy environments — VPN gateways, smartcard workstation login, on-premises PKI — can't support modern FIDO2 passwordless architectures, so they stay on separate tracks: old PIV/PKI for legacy systems, new FIDO2 for cloud apps, and building badge readers on a third physical access controller entirely. Managing three separate credential systems is an operational burden, but the security posture is equivalent.
The Reality
Disconnected logical and physical access layers don't just create administrative overhead — they create detection blind spots that attackers actively exploit. When a terminated employee's badge is deactivated but their PIV certificate remains live, or when an attacker authenticates to VPN from a location the user never physically entered, your SIEM has no way to correlate the anomaly. These aren't theoretical edge cases; they are the mechanics of several major enterprise breaches in the last three years.
THE BLUEPRINT
Deploy hybrid hardware tokens capable of running FIDO2 alongside PIV and legacy PKI protocols on the same certified secure element, and connect those tokens to card readers at every physical entry point. A single cryptographic root now controls workstation login, cloud SSO, legacy VPN, and building access simultaneously. One decommission action revokes everything. NIS2 Article 21(2)(i) audit evidence is generated as an operational by-product of a single unified log.
The Detection Gap No One Is Logging
Most CISOs can tell you the state of their logical access controls. They can name the IdP, describe the MFA policy, and point to the FIDO2 deployment rollout plan. Fewer can tell you, with confidence, whether their physical access control system shares identity data with their SIEM — and whether a terminated identity that was deprovisioned from Active Directory was also revoked from the building access controller on the same day.
Detection Blind Spots: Disconnected Access Layers
Scenarios your SIEM cannot see when physical and logical access are separate
- Terminated employee badge deactivated, PIV certificate remains valid — ghost credential persists for logical access after physical access removed
- Attacker authenticates to VPN or cloud SSO from a geography the user has never physically entered — no physical presence baseline to correlate against
- Insider accesses server room physically after logical privileges were restricted — no unified deprovisioning triggered physical revocation
- Contractor accesses building during off-hours without corresponding system login — no anomaly detected because audit logs are in separate systems
This is not an access policy failure. It is an architecture failure: the decision to manage logical and physical identity in separate stacks with no shared revocation or audit pipeline. The convergence architecture described in this volume eliminates that gap structurally.
The Convergence Architecture
A converged hardware token architecture uses a single certified secure element — one physical token — to carry all the credential material required for every access layer simultaneously. The token becomes the portable hardware root of trust for the user's entire access footprint.
The card reader is the physical layer component that completes this architecture. Without readers that are compatible with the token's smart card protocols at every entry point, building access remains on a separate credential. With them, the same tap that logs a user into their workstation is the same cryptographic authentication that opens the door — rooted in the same hardware, verifiable in the same audit log.
Hardware: NeoWave Winkeo-C
Winkeo-C — The European Sovereign Reference Token
Manufactured in France · FIDO2 / WebAuthn · ANSSI Visa de Sécurité
- CC EAL6+ certified secure element — highest chip-level tamper resistance available in a commercial FIDO2 token
- ANSSI Visa de Sécurité — French national cybersecurity agency's highest endorsement; direct audit artefact for NIS2 Article 21 evidence
- FIDO2 / WebAuthn + U2F — phishing-resistant authentication for all modern IdPs (Entra ID, Okta, Google Workspace)
- USB-C + NFC — works across workstations, laptops, tablets, and NFC-enabled card readers
- Made in France — complete European supply chain; no third-country firmware exposure
- Physical access compatible — NFC interface supports smart card readers at building entry points
Hardware: Feitian BioPass K49
BioPass K49 — Biometric Convergence at EAL6+
FIDO2 + PIV + Biometric · Multi-protocol · Post-quantum ready
- CC EAL6+ certified chip — hardware-level tamper resistance validated across all protocols
- FIPS 140-3 Level 3 — validated cryptographic boundary for regulated and government environments
- FIDO2 + PIV + OATH + OpenPGP — full multi-protocol support; one token covers cloud apps and legacy PIV infrastructure simultaneously
- On-chip fingerprint biometric — biometric is verified and never leaves the token; no server-side biometric database
- Post-quantum cryptography ready — firmware architecture designed for PQC algorithm transition
- USB-A / USB-C + NFC — covers every device in the fleet, including NFC card readers for physical access
Completing the Architecture: Card Readers
The hardware tokens above carry the logical and physical credential on a single secure element. The card reader is the physical-layer infrastructure that makes building access part of the same cryptographic proof — not a separate system. Without readers capable of authenticating the same token, physical access remains on a separate credential stack and the convergence architecture is incomplete.
Ciptor Card Reader Selection
A wide range of certified card readers for every deployment point
Ciptor stocks card readers across all form factors required for a full convergence deployment — from desktop USB readers for workstation authentication to door-mounted contactless readers for building entry points. All readers are sourced against the same supply chain standards we apply to the tokens themselves.
Desktop USB Readers
Workstation and laptop login via smart card and FIDO2 token — compatible with PIV and Windows Hello workflows
Door-Mounted Contactless
NFC/contactless readers for building entry, server rooms, and secure zones — compatible with the same token your users carry for logical access
Multi-Protocol Readers
Readers that handle both contact (PIV smart card) and contactless (NFC/FIDO2) in a single unit — simplifies mixed-fleet deployments
PACS Integration
Readers compatible with major Physical Access Control Systems — we can advise on compatibility with your existing PACS before you specify
If you're specifying a converged architecture, we can help you select readers compatible with your existing PACS, your PIV card management platform, and the token models above — before you commit to a deployment.
NIS2 Directive · Article 21(2)(i)
Physical and logical access controls under a single audit requirement
NIS2 Article 21(2)(i) requires documented policies and procedures covering access control and authentication across the organisation's network and information systems — which regulators are interpreting to include physical access to facilities that house critical infrastructure. A converged architecture that generates a unified audit log across both perimeters satisfies this requirement with a single control, rather than two separate documentation sets for two separate access systems.
Audit Evidence Generated by a Converged Architecture
NIS2 Art. 21(2)(i)
Unified Access Log
Single event source correlates physical entry with logical authentication — anomalies surface automatically
NIS2 Art. 21(2)(i)
Simultaneous Revocation
One deprovisioning action terminates all access layers — audit trail confirms physical and logical revocation at the same timestamp
NIS2 Art. 21(2)(b)
Incident Detection
Physical/logical correlation enables detection of location-anomaly attacks that would be invisible in siloed systems
NIS2 Art. 21(2)(i)
Supply Chain Assurance
CC EAL6+ certification and ANSSI endorsement provide documented hardware assurance for both token and reader procurement
Volumes 11–15 have established the hardware root of trust: what makes a token trustworthy at chip level, how supply chain determines sovereignty, how biometrics bind credential to person, how lifecycle governance prevents ghost credentials, and how convergence extends that root to physical access. Regulatory Accountability — begins with Vol. 16.
