{"aiAssisted":true,"author":"Chris Cherry","body":"\nCyber infrastructure is transitioning to post-quantum cryptography, but physical access control is not. The necessary silicon is available, smart card platforms are mature, and standards are finalized. However, the Physical Access Control System (PACS) industry has yet to adopt these advancements.\n\nThe deprecation schedule is public. NIST IR 8547, currently an Initial Public Draft, sets the public transition trajectory: 112-bit-strength public-key algorithms, including RSA-2048, ECDSA P-256, and ECDH P-256, are deprecated after 2030 and disallowed after 2035, with all quantum-vulnerable public-key cryptography disallowed after 2035. For procurement and architecture decisions, 2030 is not the cliff; it is the point at which new classical designs become indefensible. NIST finalized the three primary post-quantum standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA, the Stateless Hash-Based Digital Signature Standard). CNSA 2.0 puts National Security Systems on the same trajectory, with earlier deadlines and a separate firmware signing requirement based on stateful hash-based signatures. FIPS 140-2 validations move to the CMVP Historical List on September 21, 2026; after that date, FIPS 140-2 modules should not be procured for new federal systems, though existing-system use remains a separate question.\n\nThe deprecation deadlines that drive the migration are public and time-certain regardless of when a cryptographically relevant quantum computer (CRQC) arrives. NIST IR 8547 disallows 112-bit-strength public-key algorithms after 2035, with the deprecation window opening in 2030. PACS controllers installed today have 10 to 15 year service lives, which means controllers procured in 2026 are cryptographically constrained by the public deprecation window whether CRQC arrives in 2030 or 2040. The structural condition that defines the migration is the overlap between PACS procurement and integration cycles and the regulatory deprecation deadlines, not any specific CRQC arrival date.\n\nThe compressed CRQC timeline produced by the past 18 months of research strengthens the case for urgency without being load-bearing. Caltech researchers reported in March 2026 that a functional quantum computer may be feasible by 2030 with 10,000 to 20,000 qubits rather than the millions previously estimated. Forrester's State of Quantum Computing 2026 positions Q-Day around 2030 as a credible horizon. Cloudflare moved its target for full post-quantum security to 2029. Google's Quantum AI team demonstrated an algorithmic speedup that reduces the number of qubits needed to break RSA-2048. AI systems are being used to discover new quantum algorithms and optimize existing ones, and the Oratomic team's breakthrough, reported in April 2026, was accelerated by AI. The structural argument holds whether the compressed timeline materializes or not; the compressed timeline shortens the planning horizon if it does.\n\nFour years falls within the hardware refresh cycle for controllers and readers bought today. It's shorter than the typical commercial real estate lease and shorter than a large enterprise PACS integration cycle. Meanwhile, the cyber side is already moving. AWS deployed hybrid ML-KEM TLS across KMS, S3, CloudFront, Application Load Balancer, and Certificate Manager in 2025. Microsoft integrated ML-KEM and ML-DSA into SymCrypt, the cryptographic engine inside Windows and Azure. Google Cloud rolled out quantum-safe KEMs in Cloud KMS preview in October 2025. Apple PQ3 has used ML-KEM for iMessage key encapsulation since 2024. Thales Luna hardware security modules (HSMs) ship ML-KEM and ML-DSA natively in firmware v7.9. TPM 2.0 version 1.85 added both. The hyperscalers, enterprise cryptography vendors, and platform operators are not waiting for deadlines.\n\nNo major North American PACS credential vendor has announced a post-quantum product, and no leading controller manufacturer has published a post-quantum firmware signing roadmap. OSDP 2.2.2, the reader-to-controller protocol, still uses AES-128 with pre-shared keys, and no public roadmap for version 2.3 was identified as of April 2026. This lack of progress raises important questions for the industry.\n\nThe argument that follows is not a compliance piece, because while the deprecation schedule is the forcing function, the more consequential question is what enterprises and their suppliers have actually built and not built in response to it. It is also not a federal policy piece in any direct sense, though CNSA 2.0 is illustrative because it sets the trajectory the commercial market increasingly follows through procurement obligations and contractor flow-down requirements. The frame throughout is the corporate enterprise deployment archetype, with HID-dominant controller infrastructure, multi-site real estate footprints, and security functions mature enough to ask post-quantum questions, including organizations where physical and information security are converged and organizations where they are not.\n\nIn this article, \"post-quantum-ready PACS\" means that the credential, reader-controller, firmware-signing, and controller-host trust relationships can survive the retirement of quantum-vulnerable public-key cryptography without relying on classical roots, unmanaged exceptions, or vendor-specific dead ends.\n\nThe argument applies most directly to corporate enterprise PACS, and the verticals discussed below carry different forcing functions and timelines that the text addresses where the difference matters. Mid-market deployments where PACS sits with IT or facilities have a different ownership structure that affects both the threat model and the migration path. Government deployments under Federal Information Processing Standards procurement and Federal Identity, Credential, and Access Management requirements face forcing functions commercial enterprises do not. Healthcare carries Health Insurance Portability and Accountability Act and HITRUST-driven pressures with a different cadence and different enforcement teeth. Financial services has distinct vault and trading floor patterns that require their own analysis. Hospitality and retail run installed bases measured in decades and operate under economic constraints that make voluntary cryptographic refresh implausible. The cryptographic argument applies across all of these, but the tactical response and the realistic timeline differ enough that readers should calibrate the products and timelines to their own environment rather than treating any single recommendation as universal.\n\nThe technical migration the PACS industry has not made is not a single transition but four separate ones, each operating at a different layer of the stack and each carrying its own deprecation exposure. The reader-to-controller wire protocol, governed by the Open Supervised Device Protocol (OSDP) at version 2.2.2, runs AES-128 (Advanced Encryption Standard, 128-bit) with pre-shared keys and offers no crypto agility, no negotiated key establishment, and no public roadmap for a post-quantum revision from the standards body that maintains it. The card-to-reader credential format is the layer where the silicon and smart card platforms have shipped post-quantum-capable products and the PACS-branded credential channel has not built on them, leaving the installed base on AES-128 for the cards that have any cryptographic protection at all and on no cryptographic protection for the substantial residual proximity card population. The firmware signing layer is where controllers depend on RSA-2048 or ECDSA P-256 root signatures whose forgery becomes feasible inside the deprecation window, with a procurement-relevant choice between stateful hash-based signatures, specifically the Leighton-Micali Signature (LMS) or eXtended Merkle Signature Scheme (XMSS) as defined in NIST Special Publication 800-208 and required by CNSA 2.0, and the stateless SLH-DSA alternative whose signature size raises practical implementation questions for constrained controllers. The controller-to-host Transport Layer Security (TLS) layer is the easiest of the four because hyperscaler infrastructure is already migrating and the work is largely TLS-stack version management, but enterprise Public Key Infrastructure for PACS endpoints is informal in most deployments. ML-DSA certificates are issuable today through commercial CA platforms such as AWS Private CA and DigiCert Trust Lifecycle Manager, with comparable capability rolling out across the other major hyperscaler CA services, and RFC 9881 standardized the X.509 conventions in October 2025, but the migration for the median enterprise is gated more by certificate lifecycle maturity than by algorithm availability.\n\nA PACS deployment is post-quantum-ready only when all four migrations are complete, and none of the four is complete in the commercial channel as of April 2026. The asymmetry between cyber infrastructure and physical access control is the structural condition that defines the rest of the argument, and it reflects market signals about customer pressure and procurement priority rather than questions of technical feasibility, because both sides depend on the same primitives, both sides face the same deprecation deadline, and the standards work the cyber side built on is the same standards work the physical side could have built on through its own silicon and platform suppliers. The threat model that follows treats this asymmetry as an enterprise risk rather than an industry one, and it focuses on the compromise pathways that scale rather than the ones that the PACS industry tends to discuss, because the cryptographic deprecation question is consequential precisely because the architecture it sits on top of is consequential.\n\n## The Compromise Pathways That Matter Are Not the Ones the Industry Discusses\n\nThe dominant industry framing of post-quantum risk is harvest-now-decrypt-later, where adversaries intercept ciphertext today and decrypt it once a CRQC arrives. This framing is useful for long-lived confidential data, including diplomatic cables, medical records, intellectual property held in long-term custody, and the kind of crypto-asset key material whose value persists for decades. It is a weaker framing for physical access control, because most PACS traffic does not sit in the categories that adversaries warehouse for future decryption. Door-open events are ephemeral. Badge-swipe pattern-of-life data has some residual intelligence value when it concerns specific named individuals, but the bulk of the traffic is operational telemetry that loses value within hours. The harvest-now framing carries the cryptographic urgency narrative the broader industry has organized around, and it underweights the pathways through which PACS compromise produces consequence.\n\nThe consequential post-quantum-contingent threat for PACS is signature forgery. When the classical signatures that bind firmware to controllers, certificates to credentials, and trust roots to manufacturers become forgeable, every cryptographic relationship that depends on those signatures becomes impersonable. An attacker who can forge the firmware signing root for a major controller platform converts a foothold like the 2022 Mercury vulnerability into something materially worse: a vendor-scale beachhead, where every controller in the installed base that trusts that root can be made to accept attacker-signed firmware through an accepted update path. HID Mercury controllers, by HID's own marketing, have approximately 5 million deployments globally across more than 20 OEM partners. A forged Mercury signing root is industry-wide beachhead placement across every enterprise that runs the platform, and the attacker's scaling factor is the market share of the vendor whose signing root they break rather than the security posture of any single deployment. The architectural problem for the defender is that the installed base cannot be re-signed retroactively, controllers deployed today with classical signing roots remain cryptographically fragile for their entire service life, and PACS controllers typically run for 10 to 15 years. Controllers installed in 2026 will still be in service when the deprecation window closes and through whatever period the CRQC question follows.\n\n### PACS Compromise Is Network Compromise\n\nThe framing most executives have not been given is that PACS is not an air-gapped physical security system, it is networked enterprise software. The head-end software—C·CURE, OnGuard, Pro-Watch, Synergis, Symmetry—runs on the corporate network and maintains active integrations with Active Directory or LDAP for operator authentication, with enterprise identity providers like Okta or Entra for badge provisioning workflows, with HR systems for identity lifecycle, and with video management, building management, visitor management, and elevator control systems through its integration layer. The controllers themselves are Linux devices on enterprise virtual local area networks, communicating with the head-end over TLS. Every layer of this stack is a networked software system, and every layer is reachable from the same enterprise network that hosts the rest of the organization's information technology.\n\nIn June 2022, Trellix Threat Labs disclosed a chain of vulnerabilities in HID Mercury controllers, including CVE-2022-31481, an unauthenticated remote code execution flaw scored at the maximum CVSS value of 10.0. By chaining two vulnerabilities, the researchers achieved root on the device's Linux operating system remotely, ran arbitrary programs alongside the legitimate access control software, subverted monitoring and logging, and manipulated the controller at will. The Cybersecurity and Infrastructure Security Agency published an advisory. The affected products were sold through more than 20 OEM partners, including the Carrier-owned LenelS2 brand, which propagated the vulnerability across the channel. What that research demonstrated was not primarily a physical security incident, it was a remote unauthenticated foothold with root privileges on a Linux device connected to the enterprise network, and the distance from that foothold to the broader corporate network follows the standard compromise playbooks of credential harvesting, pivot through service accounts, lateral movement to the head-end, and escalation through Active Directory trust relationships.\n\nThe PACS controller is a forgotten server class in most enterprises. It is rarely in scope for the cybersecurity oversight that an equivalent enterprise Linux server would receive, rarely monitored by the security operations center, and runs on patch cycles measured in quarters or years rather than days. Nozomi Networks' 2026 research found that only 0.3% of operational technology (OT) wireless networks use enterprise-grade authentication, with adoption concentrated on IP-edge devices like cameras where the supplicant is supported, and roughly 70% of OT systems are now connected to enterprise information technology networks by recent industry estimates. Segmentation between PACS virtual local area networks and the enterprise core is aspirational in most deployments rather than rigorously enforced. The 2022 Trellix research was an anomaly only in that it was disclosed publicly, and the architectural reality it exposed—Linux servers on the corporate network running out-of-scope cryptography with minimal cybersecurity oversight—persists after the specific common vulnerabilities and exposures are patched.\n\nThe on-premise controller-as-Linux-device scenario does not describe the majority deployment reality anymore. Most enterprises run hybrid configurations, with some sites on-premise, others hosted in the customer's own cloud tenant, and others delivered through vendor-managed software-as-a-service, and few are cloud-only. The major PACS and video surveillance system platforms offer at least three deployment modes: on-premise bare metal, customer-hosted cloud where the vendor publishes an Amazon Machine Image or equivalent Azure deployment that the customer runs in their own cloud account under standard licensing, and vendor-managed single-tenant software-as-a-service where the vendor operates the cloud tenant on the customer's behalf. Each model shifts the cybersecurity configuration responsibility to a different party, and the customer-hosted cloud model is the one that most expands the lateral movement surface in ways executives frequently do not recognize.\n\nWhen PACS is hosted in the customer's own cloud tenant, the head-end becomes a compute instance running in a virtual network the customer configured, with identity and access management roles the customer assigned, network connectivity patterns the customer architected, and audit logging that the customer enabled or did not. The PACS application's identity and access management permissions frequently include access to object storage for video evidence archives, managed database instances for the PACS database, and cross-account trust relationships to the enterprise identity provider. Each of those grants is a potential over-permission, and vendor deployment templates default toward permissive configurations because they optimize for deployment success rather than for least privilege. The network architecture decisions made at deployment determine whether a head-end compromise stays scoped to the PACS workload or pivots into production systems through virtual network peering, transit hub sharing, or cross-account trust relationships designed without input from the cloud security engineering function that would normally govern those decisions. The cloud-hosted PACS also inherits the hyperscaler's post-quantum transport-layer migration, which can create the appearance of post-quantum readiness even though the PACS application's own internal cryptography remains classical, because the major hyperscalers have deployed hybrid ML-KEM transport across their core managed services, but the PACS vendor's firmware signing, credential authentication, and internal certificate handling are unchanged by where the workload runs.\n\n### The Identity Bridge\n\nThe second consequential pathway operates through enterprise identity infrastructure, where PACS systems integrate imperfectly with the broader identity stack and the seams compound the operational consequence of any single compromise. Service accounts are frequently shared between PACS head-end software and other information technology systems, certificates issued from enterprise public key infrastructure sign both classes of system, and operator accounts on the PACS console sometimes have administrative privileges on the underlying Windows server that hosts the head-end. Terminated employees can lose single sign-on access in minutes through the identity provider while retaining badge access for days or weeks through a manual human resources to PACS deprovisioning handoff, which is a security control failure, and they can also retain shared service-account credentials that propagate across systems, which is a more consequential one because the service account exposure outlasts the offboarding event by indefinite duration.\n\nUser access reviews for physical access are less consistent than for logical access in most enterprises, and the physical access entitlement corpus is often the least-audited identity store in the organization despite being typically connected to the corporate directory. Access drift across role changes accumulates over years without a corrective mechanism that matches the cadence of logical access governance. None of this is a Q-Day problem. It is a present-tense identity governance problem, and the cryptographic deprecation window makes it more urgent by raising the consequence of any single identity compromise rather than by introducing a new failure mode.\n\n### What the Attacker Does Not Need\n\nThree negations narrow the threat model and clarify where the urgency sits. The attacker does not need to break the AES, because symmetric primitives are not the PACS weakness, and the structural assumption underneath the post-quantum migration is that AES at appropriate key lengths remains secure against quantum cryptanalysis with the practical effective security halving that Grover's algorithm implies. The attacker does not need a CRQC for most of the threat surface, because the 2022 Mercury vulnerabilities required no quantum capability at all, the protocol-level Bluetooth vulnerabilities discussed later in this analysis are present-day exploits, and the identity governance failures that compound them are present-day operational deficits. The attacker does not need industry cooperation, because the silicon and smart card platforms discussed in the next section are already shipping in production volumes from major suppliers, and the gap that defines the rest of this analysis is one of PACS-vendor product development rather than one of cryptographic feasibility or component availability.\n\nThe threat model that makes the case to a skeptical executive is not that physical access control is suddenly going to fail, it is that PACS is already a compromise path with consequences that scale beyond the building, the cryptographic deprecation window makes those consequences worse, and the supplier channel has not responded to either the present-day exposure or the deprecation timeline.\n\n## The Silicon Has Shipped, the Smart Card Platforms Have Shipped, the PACS Supply Chain Has Not Followed\n\nThe reader-to-controller wire protocol is the OSDP, currently at version 2.2.2 released by the Security Industry Association in October 2024 and codified internationally as IEC 60839-11-5:2020. The protocol uses AES-128 with cipher-based message authentication code over a Secure Channel Base Key that is established at commissioning, and the specification defines a hardcoded default key that the protocol uses during install mode before the controller issues a unique key through the secure key set command. The specification does not require rotation of the unique key after provisioning, and industry practice on rotation cadence varies considerably across deployments. The cadence at the standards body is its own data point: OSDP 2.1.7 shipped in 2015, OSDP 2.2 shipped in December 2020, and the nine-year gap between substantive updates frames the trajectory at the protocol level. Version 2.3 is in working group draft with no announced timeline and no public statement from the standards body on a post-quantum revision identified as of April 2026. Adoption of OSDP itself, even at the current version, is below 30% of new projects according to 2022 industry data, which means the majority of installed readers are still running Wiegand, a 1980s protocol with no cryptographic protection at all. HID released OSDP Transparent Mode patents in March 2026 to enable broader implementation across reader manufacturers, which is a positive architectural development that does not address the post-quantum question directly. The migration the protocol requires is the replacement of pre-shared symmetric keys with negotiated key establishment through post-quantum key encapsulation, the addition of signature verification for reader firmware and configuration data, and the introduction of crypto agility that does not require specification revisions for future algorithm rotations. The computational budget on currently shipping reader system-on-chips is insufficient for ML-KEM or ML-DSA operations in the majority of currently shipping reader products, no major reader vendor has announced a post-quantum-ready stock keeping unit as of April 2026, and the installed base of OSDP readers cannot be field-upgraded to post-quantum cryptography in most cases.\n\n### The Credential Format Is Where the Verification Reframes the Argument\n\nInfineon's SLC27 security controller began shipping on October 14, 2025. It is a contactless and dual-interface security controller with a Common Criteria-certified cryptography library that supports both ML-KEM and ML-DSA. The controller is built on the TEGRION platform with the Integrity Guard 32 architecture, which provides side-channel and fault-attack resistance at a level appropriate for smart card and secure element applications. It supports in-field updates and crypto agility, which means the algorithms it implements today are not the only algorithms it will be able to implement during its service life. The SLC27 is available in sample volumes and in high-volume production today. The certification work that produced it built on Infineon's earlier achievement, in January 2025, of the world's first Common Criteria EAL6 certification for a post-quantum-cryptography-ready security controller, which established the cryptographic and side-channel resistance architecture that the SLC27 productizes.\n\nThales launched the MultiApp 5.2 Premium PQC on October 7, 2025, becoming the first European smart card to be certified at Common Criteria EAL6+2 by France's national cybersecurity agency, ANSSI. The card integrates ML-DSA at parameter set 65 as its post-quantum signature algorithm, and it is positioned for European national identity cards, electronic health cards, driver's licenses, and electronic passports. The certification scope is specific to European government identity applications, but the underlying smart card platform is adaptable to other applications. The October 2025 launch represents the first complete quantum-safe smart card solution to obtain augmented EAL6 certification, and it gives Thales a structural lead in the smart card segment that will carry through the procurement cycles that follow.\n\nNXP announced MIFARE DUOX, a contactless smart card integrated circuit with a feature set that includes AES-256, 256-bit elliptic curve cryptography on the National Institute of Standards and Technology P-256 and brainpoolP256r1 curves, and public key infrastructure certificate handling. Safetrust announced an integration partnership with NXP in February 2025 that positioned MIFARE DUOX as a post-quantum-ready credential within the Safetrust ecosystem, with the readiness positioned as a migration bridge through hardened classical cryptography rather than as native ML-KEM or ML-DSA support. The partnership represents the most post-quantum-forward public positioning from any vendor adjacent to the PACS credential channel as of April 2026.\n\nThe credentials in enterprise deployment are HID Crescendo and iCLASS Seos, the Avigilon Alta and Brivo mobile credentials, and the MIFARE-family proximity cards still in widespread use. Neither the Infineon SLC27 nor the Thales MultiApp 5.2 will land in those deployments. Thales targets European government identity, where the certification scope and lifecycle expectations do not match enterprise corporate access, and Infineon's secure element is upstream of a different supply chain than HID and the other credential vendors source from. Both are cited here as existence proofs that post-quantum silicon and certified smart card platforms are productizable at industrial scale, not as the path forward for enterprise PACS, which runs through NXP shipping post-quantum silicon and HID extending post-quantum into its credential application layer.\n\nWhat the PACS industry has built on this foundation is the gap. No major North American PACS-branded credential vendor has announced a post-quantum-native credential product, and the installed base of credentials continues to ship with cryptographic protections that range from triple Data Encryption Standard on the older MIFARE DESFire generations, to AES-128 on the current generations, to no cryptographic protection at all on the substantial residual proximity card population at 125 kilohertz that remains particularly common in the North American enterprise installed base. The MIFARE DESFire installed base is itself heterogeneous by geography, with NXP holding greater share in Europe than in North America according to Allegion's own characterization of the market, and the EV3 generation that introduced the most recent capability set was announced only in June 2020, which means the EV3-equipped portion of the installed base is recent rather than dominant. The card-format gap is not silicon, it is not smart card platform certification, and it is not standards work. It is PACS-vendor product development, and the European government identity market has now shipped post-quantum-native smart cards while the PACS credential vendors have not built equivalent products. The fact that government identity smart cards and PACS credentials are different product categories with different procurement cycles is true, and it does not change the structural observation that the underlying technology has shipped from the silicon and platform vendors and the PACS channel has not built on it.\n\nWhether the deployed credential population can be re-keyed in field or whether the substrate forces replacement is the operational question that determines what a migration costs. The two outcomes differ in cost by an order of magnitude.\n\nThe answers depend on the chip. For credentials in enterprise deployment today, 125-kHz proximity cards have no cryptographic key to rotate, which forces substrate replacement at any post-quantum migration point. MIFARE DESFire and similar smart card families are technically re-keyable in field through the chip's secure messaging channel, but only if the issuance infrastructure exists to push new keysets at scale and only if the chip itself supports the new algorithms, which means a post-quantum migration on these families requires new chips with post-quantum-capable secure elements rather than just key rotation. HID iCLASS Seos faces the same constraint, because the underlying secure element does not support post-quantum algorithms today. Mobile credentials including Avigilon Alta, Brivo, and HID Mobile Access re-key by pushing software to the device on demand, which is the strongest operational reason to favor mobile-first credential architectures in enterprises planning around the deprecation window.\n\nThree questions are worth putting to credential vendors at the next procurement review. Can the keyset be rotated in field after issuance, and what is the operational workflow for a deployment-wide rotation? When a new cryptographic algorithm is required, is the migration a software update or a substrate replacement? What architectural features in the secure element preserve crypto agility after the credential has been issued? Vendors who cannot answer these questions concretely are selling credentials whose operational migration cost is unknowable, and that uncertainty is itself the procurement finding.\n\nThe LEAF Consortium, founded in 2023 by Wavelynx and a small group of independent reader and credential vendors, publishes an open credential format that multiple vendors can read and issue against. The open multi-vendor structure changes the migration dynamic in a way the HID-dominant channel cannot match, because the moment one consortium member ships post-quantum credentials, the rest face competitive pressure to follow. No LEAF member has announced a post-quantum-native product as of April 2026. For enterprises whose procurement cycles align with the deprecation window, LEAF-compatible readers and credentials specified in the procurement stack create migration optionality that proprietary HID-only stacks do not.\n\nPersonal identity verification cards used in federal contexts are a specific exception governed by their own migration path, with Federal Information Processing Standard 201 compliance and CNSA 2.0 trajectory applying directly, and federal credential issuance has distinct requirements that this commercial-focused analysis treats as adjacent rather than central.\n\n### Firmware Signing Is Where the Deprecation Risk Is Sharpest\n\nThe firmware signing layer is the layer where the deprecation risk is most acute architecturally and where supplier readiness is the hardest to verify from outside the vendor relationship.\n\nPACS controllers sign firmware classically, using either RSA-2048 or ECDSA on the National Institute of Standards and Technology P-256 curve, both of which are within the deprecation window that NIST IR 8547 establishes. HID Mercury's MP series, which is the platform that dominates the North American installed base under HID Global's ownership through ASSA ABLOY, features ARM TrustZone, secure boot, AES-256 for data at rest, and TLS at versions 1.2 and 1.3 for the controller-to-host connection. None of these are post-quantum primitives. Public material from HID Mercury as of April 2026 does not reference ML-KEM, ML-DSA, the LMS, the XMSS, or post-quantum cryptography in product documentation, firmware release notes, partnership announcements with post-quantum silicon vendors, or CNSA 2.0 compliance statements. The absence of these indicators is not definitive proof that no such work is underway, but it is the set of signals that would exist if post-quantum support were present or planned in any visible form, and none of them are observable in the public record.\n\nOpen-source root-of-trust projects have demonstrated that post-quantum-capable controller silicon is achievable through reasonable engineering work. Microchip's PSOC Control C3 Performance Line is marketed as CNSA 2.0-compliant for firmware verification beginning in 2025. The OpenTitan project supports the SPHINCS+ precursor to SLH-DSA, and the Caliptra project supports LMS. These are not drop-in replacements for HID Mercury controllers, and substituting them would require significant integration work, but they establish that the engineering is not blocked by physics or by the availability of cryptographic implementations.\n\nWhat CNSA 2.0 specifies for firmware and software signing is stateful hash-based signatures, specifically LMS or the XMSS as defined in NIST Special Publication 800-208, rather than the stateless SLH-DSA that NIST standardized in FIPS 205. This distinction is procurement-relevant because the two families have different operational requirements. Stateful signatures require state management infrastructure where each signing operation consumes a one-time key, and key reuse compromises the security of the entire scheme, which means the signing infrastructure must reliably track which keys have been used and never reuse them. SLH-DSA avoids the state management requirement, but it produces signatures on the order of 16 kilobytes at security category 3, which raises practical implementation questions for firmware update workflows on controllers with constrained network bandwidth or limited storage for cached signatures. A controller vendor who cannot articulate the choice between LMS, XMSS, and SLH-DSA for their firmware signing roadmap, and who cannot describe the state management architecture they will use if they choose the stateful path, is not actually building to the standard regardless of any general post-quantum positioning they may claim. This is the question to put to every PACS controller vendor at the next product review.\n\nHybrid signature schemes that combine classical and post-quantum signatures with both verified at update time are the defensible transitional posture for the period between now and full post-quantum confidence. They preserve backward compatibility while establishing the migration path. Commercial PACS controller vendors have not publicly adopted hybrid signing as of April 2026.\n\n### Controller-to-Host TLS Is the Easiest of the Four\n\nThe controller-to-host TLS layer is the easiest of the four migrations from a cryptographic-availability standpoint, and it is the migration most likely to be partially in place at any given enterprise without explicit effort.\n\nControllers communicate with head-end software over TLS, with modern deployments running version 1.2 or 1.3 with elliptic curve Diffie-Hellman ephemeral key exchange and either RSA or ECDSA certificates. Legacy deployments run earlier TLS versions or unauthenticated control channels, which is a separate and serious problem that any security leader auditing a PACS deployment should look for, because it is more common than the industry openly acknowledges. The migration to post-quantum at this layer is largely a question of TLS stack version management and certificate authority capability rather than fundamental engineering work. Hybrid key exchange combining the X25519 elliptic curve with ML-KEM at parameter set 768 is the emerging de facto standard across major TLS implementations and is deployed at scale by Cloudflare, Amazon Web Services, Google, and Microsoft. OpenSSL 3.2 and later versions have experimental support, and BoringSSL has production support. ML-DSA certificates exist, the National Institute of Standards and Technology predicted in 2024 that the first post-quantum certificates would be commercially available in 2026, and the Certificate Authority and Browser Forum is working on the identifier standardization that broader adoption requires.\n\nThe harder problem at this layer is not cryptographic availability, it is enterprise public key infrastructure maturity. Most enterprise certificate authorities do not yet issue ML-DSA certificates at production scale, and the certificate lifecycle management for PACS endpoints is informal in most deployments, with certificates issued at installation, rarely rotated, and not tracked in enterprise public key infrastructure inventory systems. The migration is achievable by 2028 to 2029 for enterprises with mature public key infrastructure governance, and it is not achievable on that timeline for the median deployment because the median deployment does not have mature public key infrastructure governance for PACS endpoints to begin with. Remote Authentication Dial-In User Service-based certificate authentication for PACS endpoints exists in some government deployments but is not standard practice in the commercial channel.\n\nThe inheritance confusion that the cloud-hosting analysis flagged is particularly acute at this layer, because the hyperscalers have deployed hybrid ML-KEM TLS across their managed services, and a cloud-hosted PACS deployment inherits the partially-migrated transport posture for free. That inherited posture does not extend to the PACS application's internal cryptographic primitives, which means a deployment running on modern cloud infrastructure can appear post-quantum-migrated at the transport layer while remaining fully classical at the application layer where the firmware signing certificates and credential authentication ceremonies actually live, and the application layer is the layer that determines whether a controller's firmware signing root or a credential's authentication exchange is post-quantum.\n\nThe supplier-side gap is the structural condition that defines what enterprises can and cannot procure within the deprecation window.\n\nA methodology note on the negative claims in this section: the assertion that no major North American PACS-branded credential vendor has announced a post-quantum-native product, that no leading controller manufacturer has published a post-quantum firmware signing roadmap, and that no public OSDP 2.3 timeline exists, reflects a public-record review conducted in April 2026 across HID, Mercury, LenelS2, Honeywell Pro-Watch, Johnson Controls C·CURE, Genetec Synergis, AMAG Symmetry, Avigilon Alta, Brivo, Kisi, Allegion, Wavelynx, Safetrust, and SIA OSDP materials. Search terms covered post-quantum, PQC, ML-KEM, ML-DSA, SLH-DSA, LMS, XMSS, CNSA 2.0, quantum-safe, firmware signing, and crypto agility. Absence of public evidence is not proof of no internal roadmap work, but it is the procurement-relevant signal available to enterprise buyers.\n\n## The Credential Hierarchy the Industry Teaches Is Not the Hierarchy That Holds Up Under Examination\n\nThe post-quantum question is not isolated to algorithm selection. It changes how credential architectures should be ranked, because the credential substrate determines where secrets live, whether trust roots can migrate, and whether the vendor roadmaps behind the credential can plausibly survive the deprecation window.\n\nIndustry training materials and integrator sales conversations teach a credential hierarchy organized by the strength of the authentication ceremony at the reader, with biometric readers ranked highest, then smart cards with personal identification numbers, then smart cards alone, then mobile credentials, and proximity cards ranked lowest because they offer no cryptographic protection at all. This hierarchy ranks the credential presentation, not the credential infrastructure. It treats the reader as the security boundary, which is appropriate for evaluating the moment of authentication but inappropriate for evaluating the lifecycle question of where secrets live, how they are protected at rest, what happens to the population when a single template store is breached, which suppliers have post-quantum roadmaps that match the deprecation window, and whether the underlying vendor will still be supporting the credential in five to ten years. Under honest analysis the hierarchy reorders, not uniformly and not as dramatically as some mobile-wallet vendor marketing would suggest, but enough that the conventional ranking is a poor guide for credential decisions made in 2026.\n\n### The Reconsidered Hierarchy\n\nThe first tier of credential architecture is the mobile wallet credential held in a hardware secure element on a known-good device platform. On iPhone with Apple Secure Element, the credential is stored in a hardware secure element with biometric authentication mediated by the Secure Enclave, which never stores raw biometric images and instead derives a mathematical representation that is bound to a device unique identifier inaccessible to Apple. The near-field communication tap requires physical proximity at approximately 5 centimeters, which structurally constrains the attack surface compared to Bluetooth Low Energy alternatives that operate over much longer ranges. The secure element architecture is uniform across supported iPhones, which is a structural advantage in a bring-your-own-device workforce because the security leader can reason about the substrate without per-device variability. Apple does not have visibility into the access events, the credential never transits Apple's servers in a form that could be correlated to physical locations, and Express Mode and Power Reserve cover the operational convenience cases that physical cards have historically claimed as their advantage. Apple's own post-quantum work is informative for the credential architecture, with Apple PQ3 in iMessage using ML-KEM for key encapsulation, but Apple has not publicly extended ML-DSA to the secure element for signatures, which means the current generation Apple Wallet credential's post-quantum posture is bounded by the secure element silicon Apple has shipped and a hardware refresh would be required for full post-quantum capability.\n\nThe vendor dependency point that matters here is that Apple Wallet employee badges do not exist independently of the PACS credential layer. Apple partnered with HID Global and ASSA ABLOY, with Allegion in the broader partner set, to build the employee badge program, and the badge is a wallet-form representation of a credential whose intelligence still flows through the PACS industry. Silverstein Properties' World Trade Center deployment, for example, runs the SwiftConnect Access Cloud as the orchestration layer, HID Origo for credential lifecycle management, HID Seos as the underlying credential technology, and HID Signo readers at the doors. The wallet form factor substitutes for the physical card form factor, but it does not substitute for the credential channel's role in the architecture. Apple's strength is the device substrate and the secure element, and the credential intelligence is still coming from HID and its partners. This is not a critique of the wallet architecture, it is the structural reality that the vendor dependency analysis later in the section needs to account for.\n\nThe Pixel and Galaxy flagship implementations occupy the same architectural tier as iPhone with structural caveats. Google's Pixel 6 through 10 use the Titan M2 secure element, which is RISC-V based and certified at Common Criteria EAL4+ AVA_VAN.5. Samsung's Galaxy S21 and later flagship devices use Knox Vault, certified at Common Criteria EAL4+ under Protection Profile 0084 from the German Federal Office for Information Security and additionally validated under FIPS 140-2. Titan M3 is rumored for the Pixel 11 in late 2026 with post-quantum positioning, though no public confirmation exists. Google Wallet's corporate badge implementation uses hardware secure element through MIFARE 2GO on capable devices rather than cloud-based host card emulation, which keeps the credential in hardware. The Android Ready SE Alliance, founded in March 2021 with members including Giesecke+Devrient, Kigen, NXP, STMicroelectronics, and Thales, exists because secure element quality varies materially across Android original equipment manufacturers, and a security leader in a bring-your-own-device workforce cannot assume uniform substrate quality across the Android device population the way the leader can on iPhone.\n\nThe second tier is the match-on-card biometric Fast Identity Online 2 smart card, with Thales SafeNet IDPrime FIDO Bio as the canonical example and FEITIAN and AuthenTrend as architecturally equivalent alternatives. The biometric sensor lives on the card itself, the template never leaves the card, and the secure element on Thales IDPrime is certified at Common Criteria EAL6+. The architecture is compliant with the three requirements that International Organization for Standardization 24745 published in 2022 sets for biometric template protection: irreversibility, unlinkability, and revocability. The operational cost is real because the architecture requires enrollment infrastructure, card issuance workflow, and replacement and revocation processes that proximity card and basic smart card deployments do not need. In life sciences and biomedical research environments where biometric enrollment is already a regulated operational practice, this tier is more accessible than in a typical corporate office because the enrollment overhead is partially absorbed by existing compliance work.\n\nThe third tier is the converged personal identity verification and Fast Identity Online 2 public key infrastructure card with personal identification number, with HID Crescendo C2300 as the exemplar product. The card combines Fast Identity Online 2 capability, public key infrastructure operations, and embedded PACS credentials—Seos, iCLASS Standard Edition, MIFARE DESFire—on a single physical credential. It is certified at Federal Information Processing Standard 140-2 Level 2 or Level 3 depending on the specific stock keeping unit, and at Common Criteria EAL5+. It is compatible with the Personal Identity Verification standard for federal contexts. The architecture combines a personal identification number as a knowledge factor with the card as a possession factor, which provides strong cryptographic assurance for the authentication ceremony but weaker user verification than the on-card biometric of the second tier or the device-based biometric of the first tier.\n\nThe fourth tier is the commercial biometric reader operating in a match-on-device mode, where the template lives on the reader rather than on the card or on the user's device. HID Signo 25B can operate in match-on-card mode, but most deployments default to on-device storage because it simplifies enrollment. IDEMIA SIGMA, IDEMIA VisionPass, and IDEMIA MorphoWave default to match-on-device or match-on-server. Suprema BioStation 3, after the BioStar 2 breach in 2019, added a Face Template on Mobile option that stores the template on the user's device, although the default deployment mode remains on-device or server-backed. Alcatraz.ai stores templates on the device by design, which is architecturally cleaner than the IDEMIA and Suprema defaults, but the architectural improvement is bundled with a proprietary closed-stack deployment that introduces commercial portability problems.\n\nThe fifth tier is the commercial biometric reader operating in match-on-server mode, where raw or lightly-encrypted biometric templates are stored centrally in the PACS infrastructure or in the biometric vendor's backend. This architecture violates all three of the requirements that International Organization for Standardization 24745 sets for biometric template protection, and it creates mass exfiltration risk that is permanent because the underlying biometric cannot be rotated the way a password or a certificate can. This is the BioStar 2 architecture, and it remains the industry default for server-backed biometric deployments in 2026 despite the lessons that should have been learned.\n\n### What BioStar 2 Demonstrated About Template Architecture\n\nThe BioStar 2 breach in August 2019 exposed 27.8 million records totaling 23 gigabytes of data, including over one million individuals' fingerprint templates in raw form. The affected organizations included the United Kingdom Metropolitan Police, multiple banks, defense contractors, and approximately 5,700 organizations in total. The exposure occurred through a poorly configured Elasticsearch database that researchers were able to both read from and write to, which meant they could replace fingerprint records, alter access entitlements, and delete logs that would have evidenced the manipulation. Plaintext administrator passwords were among the exposed data. The Suprema system integrated with Nedap AEOS, which serves enterprises across 83 countries, which extended the architectural lessons of the breach to a much broader installed base than Suprema's own customer count would suggest.\n\nThe exposure is permanent rather than recoverable, and the academic literature on biometric template reconstruction explains why. Cappelli and colleagues, writing in the Institute of Electrical and Electronics Engineers Transactions on Pattern Analysis and Machine Intelligence in 2007, demonstrated reconstruction of fingerprint images from International Organization for Standardization 19794-2 templates with greater than 90 percent success against commercial fingerprint recognition systems. Ross, Shah, and Jain published companion template-to-image reconstruction work in the same journal in the same year. Galbally's later survey work documents that template irreversibility, the assumption underneath the entire architectural premise of \"biometric templates are not biometric data,\" is academically discredited rather than merely contested. PrintListener and PrintListener++ research published at the Network and Distributed System Security Symposium in 2024 extended the attack surface by inferring fingerprint features from audio recordings of finger swipes. MasterPrint research from New York University demonstrated synthetic fingerprints that match significant fractions of the population at default sensor sensitivity settings.\n\nThe National Institute of Standards and Technology's position is that conventional cryptographic hashing cannot be applied to biometrics because biometric data is probabilistic rather than deterministic, which means the same finger presented at two different times produces slightly different sensor outputs and a hash function that produces different outputs for those slightly-different inputs is not useful for matching. Cancelable biometrics remain an active research area rather than a deployed standard. International Organization for Standardization 24745 published in 2022 is the authoritative standard on biometric information protection, and the three requirements it sets—irreversibility, unlinkability, revocability—are the architectural floor that any biometric deployment should be evaluated against. BioStar 2 violated all three, and the server-backed template storage pattern that BioStar 2 represented remains the industry default in 2026 rather than a discontinued architecture.\n\n### The Vendor Dependency Question\n\nEvery credential architecture involves vendor dependency, and the honest evaluation question is which dependencies are most defensible rather than which architecture eliminates dependency.\n\nThe conventional industry framing is that open standards such as MIFARE DESFire and OSDP provide vendor independence. This framing is partially accurate at the protocol level and substantially less accurate at the product level. A MIFARE DESFire deployment depends on NXP as the chip vendor, on the specific PACS vendor's credential issuance and key management infrastructure, on the reader vendor's firmware implementation, and on the integration with the head-end software. The wire protocol is open, the commercial stack that delivers the protocol is not necessarily portable, and the operational dependencies that determine whether the deployment can survive a vendor exit are different from the standards-level dependencies that the procurement team evaluates.\n\nThe privacy-forward biometric vendors offer architecturally better template handling than the legacy biometric vendors, with Alcatraz.ai as the clearest example, but they bundle the architectural improvement with proprietary closed-stack deployments that create their own portability problems. Adopting Alcatraz.ai means committing to infrastructure without a clean migration path to a different vendor's architecture later if the business requirements change. The architectural improvement comes with a commercial-portability cost, and a security leader has to price both costs against the alternative of a more open but architecturally weaker template handling pattern.\n\nSmart cards from Thales, FEITIAN, and AuthenTrend are architecturally excellent at the credential layer and depend on enrollment and issuance infrastructure that creates organizational dependency rather than vendor dependency in the traditional sense. The enterprise becomes dependent on the card vendors' product roadmaps, which in turn depend on the secure element silicon roadmaps from the chip vendors. This dependency chain is longer than the mobile wallet chain, and each link introduces a vendor whose business decisions can affect the deployment's continuity.\n\nMobile wallet credentials depend on Apple, Google, and Samsung continuing to invest in the corporate badge form factor as a product. Apple and Google have demonstrated multi-year commitment through their respective wallet programs, and both companies are better-capitalized than any pure-play PACS vendor by orders of magnitude, which matters for the 2030 to 2035 horizon that the post-quantum migration runs on. The dependency analysis that favors the mobile wallet form factor is not \"Apple and Google are independent of the PACS industry\" because as the partnership structure with HID and ASSA ABLOY shows they are not, it is that the wallet vendors are likely to outlast the integration partners and the mobile wallet form factor is more likely to receive continued post-quantum investment than the physical card form factor receives from PACS-branded credential vendors.\n\nOpen-standard credentials carry the advantage that the protocol persists through vendor transitions. A building can change integrators, change card vendors, change reader vendors, and retain protocol-level compatibility. Wallet-based credentials are transient and replaceable in ways that physical cards and fobs are not, with credentials provisionable remotely when a phone is lost or damaged and credentials evaporating when an employee leaves the organization. The transience is an operational strength because it solves problems the physical card form factor never solved well, and it is also a dependency on the wallet provider's continued program investment because the operational simplicity disappears if the wallet program changes direction.\n\nThe honest assessment is that no credential choice eliminates vendor dependency, the dependencies look different across architectures in their failure modes and substitution costs, and the credential selection decision is properly framed as which portfolio of dependencies the enterprise can defend rather than which architecture is independent. A biometric startup going under is a different problem than a physical card stock vendor changing product lines, and rolling from one physical card format to another is expensive and slow while rolling from one mobile wallet provider to another is fast once the underlying credential layer is portable. The right credential strategy for a given enterprise depends on the timeline horizon, the portability requirements, the vendor risk appetite, and the differential consequence of credential compromise across the enterprise's specific portfolio of facilities and assets.\n\n## Bluetooth Low Energy Has Failed at the Protocol Level Often Enough That the Pattern Is the Argument\n\nThe case for treating Bluetooth Low Energy differently from near-field communication in PACS architecture rests on roughly a decade of protocol-level and implementation-level vulnerability disclosures that share a structural pattern, and the case is strong enough that it should outweigh the operational convenience arguments that vendor-app Bluetooth Low Energy products typically lead with.\n\nThe pattern begins with BlueBorne, disclosed by Armis in September 2017, which exposed eight common vulnerabilities and exposures spanning Android, iOS, Linux, and Windows and put more than 5 billion devices at risk for zero-interaction remote code execution and man-in-the-middle attacks. A year after disclosure, approximately 2 billion devices remained unpatched, which is roughly 40 percent of the affected population. The Key Negotiation of Bluetooth attack, disclosed by Antonioli and colleagues at the USENIX Security Symposium in 2019 and tracked as CVE-2019-9506, affected Bluetooth Basic Rate and Enhanced Data Rate from version 1.0 through 5.1 by forcing negotiation of 1-byte entropy keys that rendered the encryption brute-forceable. The flaw was in the protocol itself rather than in any specific vendor's implementation, all four major Bluetooth silicon vendors were affected, and the addressable population was roughly 1 billion devices. BlueFrag, tracked as CVE-2020-0022 and disclosed in February 2020, was a zero-click remote code execution vulnerability affecting Android 8.0 through 9.0 that required only the target's Bluetooth media access control address, which on some devices could be deduced from the device's WiFi media access control address.\n\nThe Bluetooth Forward and Future Secrecy attack, disclosed by Antonioli at the Association for Computing Machinery Conference on Computer and Communications Security in 2023 and tracked as CVE-2023-24023, affected Bluetooth versions 4.2 through 5.4, which is every modern version of the protocol in active deployment. The research demonstrated six novel attacks where compromise of a single session key broke forward and future secrecy of all sessions between the two affected devices. The attacks were tested successfully against 17 Bluetooth chips across 18 devices from Intel, Broadcom, Apple, Samsung, Google, Qualcomm, and other major silicon vendors. The vulnerability was architectural in the Bluetooth standard rather than in any specific implementation, which means the standards body bears responsibility rather than any individual vendor. CVE-2023-45866, disclosed by researcher Marc Newlin in December 2023, enabled keystroke injection through a simulated Bluetooth keyboard pairing without user confirmation, and it affected Android 4.2 through 14, iOS 16.6, macOS 13.3.3 including Lockdown Mode, and Linux. The cross-platform implementation pattern indicates a class of vulnerability rather than a vendor-specific flaw.\n\nThe cadence of these disclosures matters. Roughly one major protocol-level Bluetooth vulnerability disclosure per year since 2017, with most affecting the protocol itself rather than implementation choices that vendors could have made differently. No other widely-used wireless protocol that PACS deployments could plausibly use as a credential transport has a comparable record of fundamental architectural security failures over this time horizon. The pattern is the argument, and the argument does not depend on any single vulnerability being unpatched in any specific deployment, it depends on the structural observation that the protocol's history establishes a high prior probability that the next major architectural vulnerability is closer than any vendor's roadmap acknowledges.\n\n### The Android Implementation Fragmentation Problem\n\nAcademic consensus on Android security fragmentation is consistent across multiple independent research lines, and the consequences for a security leader operating a bring-your-own-device workforce are quantifiable. Wu and colleagues, Zhou and colleagues, and Thomas and colleagues found in separate studies that 64 to 85 percent of Android security vulnerabilities derive from vendor customization of the underlying Android Open Source Project rather than from the Android codebase itself, and that 87 percent of Android devices in the field have at least one unpatched critical vulnerability at any given time. A Bluetooth Low Energy specific study of 3,501 applications drawn from the Androzoo corpus found that all of them were subject to downgrade and man-in-the-middle attacks at ranges of up to 76 meters in line-of-sight conditions.\n\nTranslated into the practical question a security leader has to answer, applied to a 5,000-person bring-your-own-device workforce as a rough heuristic, this implies on the order of 4,350 devices statistically carrying at least one known critical vulnerability at any given moment, and the leader cannot patch them because the leader does not own them and cannot enforce patch compliance against personal devices without policy mechanisms that most workforces will not absorb without significant friction. This is structural attack surface that exists independent of any specific PACS vendor's Bluetooth Low Energy implementation quality, and it cannot be remediated through vendor selection because it is a property of the substrate the credential rides on rather than a property of the credential itself.\n\nBluetooth Low Energy address randomization, the mechanism the standard provides to prevent device tracking through fixed identifiers, is implemented inconsistently across Android original equipment manufacturers. Some manufacturers leave addresses static for periods longer than the 15-minute advisory threshold the Bluetooth Special Interest Group recommends, which means the substrate cannot reliably provide the privacy property the protocol nominally offers.\n\n### The Architectural Comparison and the Operational Conclusion\n\nThe architectural distinction at the level a security executive needs to evaluate is structural rather than feature-by-feature. Wallet-native near-field communication stores the credential in a hardware secure element with a certified applet, requires physical proximity at approximately 5 centimeters for a reader to interact with the credential, has no listening surface when the device is at rest because the near-field communication radio is not constantly broadcasting, and inherits crypto agility from the device platform vendor's roadmap rather than from the PACS vendor's roadmap. Vendor-app Bluetooth Low Energy stores the credential in operating-system-managed application storage, operates over ranges of 10 to 100 meters depending on environmental conditions, requires the Bluetooth radio to be active when the credential is in use and frequently keeps the radio active when the credential is not in use, and inherits crypto agility from the PACS vendor's roadmap rather than from the device platform vendor's roadmap. The attack surface for the near-field communication path is the near-field communication stack, which is narrow and well-scrutinized because it is the same stack that handles payment transactions and transit credentials. The attack surface for the Bluetooth Low Energy path is the Bluetooth stack, which is broad, fragmented across operating system versions and original equipment manufacturer customizations, and has the disclosure history documented earlier in this section.\n\nVendor-app Bluetooth Low Energy PACS systems in current deployment are common rather than exotic. Brivo runs Bluetooth Low Energy through its mobile application. Openpath, now Avigilon Alta under Motorola Solutions following the 297 million dollar acquisition in 2021, built its product positioning around Bluetooth Low Energy \"Wave to Unlock\" gesture-based authentication. Kisi uses Bluetooth Low Energy through its application with near-field communication available for Apple Wallet integration. HID's own Mobile Access application supports both Bluetooth Low Energy and near-field communication paths.\n\nThe pattern that deserves preservation in the public record is the workaround behavior itself. Bluetooth Low Energy in the PACS market has not been deployed as a vanilla protocol — every major vendor has layered its own cryptographic constructions on top of the underlying transport, and the workaround is the admission. When vendors layer custom crypto over an underlying protocol, the security boundary moves from the well-scrutinized public protocol to the vendor's private implementation. This is not always worse, because some vendors are very good at the cryptographic work, but it is harder to evaluate from outside the vendor relationship, and the burden of proof shifts onto the vendor to demonstrate that their workarounds actually address the protocol-level problems rather than merely papering over them. IPVM's July 2021 editorial titled \"NFC Is Better Than BLE For Mobile Access\" made the equivalent argument in the trade press five years before this analysis, and the case has only strengthened since then as the disclosure cadence has continued.\n\nThe operational reality for a security leader in most organizations is that the function selecting the PACS architecture is typically physical security, which may or may not consult information security on cryptographic substrate questions, and the architecture has to work on personal devices the enterprise does not control. Mandating iPhone over Android is not available as a control in most workforces. Patching personal devices is not available. Enforcing operating system version minimums is rarely available without triggering friction the business will not absorb. The defensible posture under these constraints is wallet-native near-field communication on devices selected from an approved list, with iPhone on supported iOS versions and Android flagship devices with confirmed hardware secure element such as Pixel 6 and later or Galaxy S21 and later, with physical smart card fallback for high-security zones and for employees who cannot or will not use mobile wallet, and for environments where phone policies prohibit mobile credentials. These environments include sensitive compartmented information facilities, certain healthcare and manufacturing floors, and frontier facilities with OT and information technology convergence concerns where the calculus around personal devices in the secure zone is more restrictive than in standard office space. The posture should explicitly acknowledge that Android fragmentation is a residual risk that cannot be fully eliminated within a bring-your-own-device policy and that the residual risk is the price of the bring-your-own-device convenience the organization has chosen to operate under.\n\nThis is not an elegant architecture. The alternative of vendor-app Bluetooth Low Energy on unrestricted bring-your-own-device is worse under honest analysis, and the burden of proof for any vendor proposing the Bluetooth Low Energy path should be the protocol's disclosure history rather than the vendor's marketing claims about their own implementation.\n\n## The Industry Has Not Moved Because the Forcing Functions Have Not Reached the Vendors Who Would Have to Move\n\nThe ownership pattern in mid-to-large enterprises with mature physical security functions follows a predictable structure that produces predictable outcomes. Human resources owns onboarding and offboarding end-to-end. Physical security owns PACS end-to-end including physical identity and access management. Information technology owns the network and the enterprise identity provider. Information security may or may not be consulted on PACS architecture decisions, and the consultation is more often driven by individual relationships between specific security leaders than by formal coordination mechanisms. Facilities owns elements of the physical plant that vary by organization and by building, with door hardware and conduit usually under facilities ownership and active hardware sometimes shared between facilities and physical security.\n\nIn mid-market organizations the pattern shifts because PACS often sits with information technology or facilities directly, since physical security has not been stood up as a distinct function with its own budget and reporting line. In government deployments the pattern shifts again because Federal Information Processing Standards procurement and Federal Identity, Credential, and Access Management requirements introduce forcing functions that commercial deployments do not face, which means the ownership question matters less because the procurement standards constrain the vendor selection upstream of the ownership decision. In healthcare, the Health Insurance Portability and Accountability Act and HITRUST compliance frameworks introduce their own forcing functions that operate on a different cadence than the procurement-driven government model.\n\nWhere information security is not in the room when credential standards and PACS architecture are selected, the cryptographic assessment of those standards depends on the physical security function's judgment. Physical security organizations are staffed for operational continuity, response coordination, and physical risk management rather than for cryptographic product evaluation, and the staffing model is appropriate for the function's primary responsibilities. The selection of PACS components in this configuration happens in integrator sales conversations, and the resulting stack is whatever the integrator is positioned to sell, which is whatever the integrator's manufacturer relationships allow them to deliver at margin. This is structure rather than failure, and the structure produces the predictable outcomes that this analysis has documented throughout: factory default credentials persisting on management interfaces, pre-shared keys set at commissioning without subsequent rotation policy, firmware update cadences measured in quarters or years rather than days, and identity lifecycle handoffs that are manual and slow. The HID Mercury LP1501 installation manual, for a controller line still in widespread enterprise deployment though superseded by the MP series, lists the factory default as username \"admin\" and password \"password\" with no required rotation at provisioning, which is the kind of artifact that signals the maturity of the security expectations the channel was originally built to meet. Whether these patterns persist in any specific enterprise depends on that enterprise's specific operational maturity and the reach of its information security function into the physical security domain. They are the reported industry default rather than a universal claim about every deployment.\n\nThe cloud-hosting deployment model that increasingly characterizes hybrid PACS environments adds a fifth stakeholder that the four-party ownership pattern does not accommodate. The cloud security engineering function, which lives inside information security in some organizations and inside platform engineering in others, owns cloud landing-zone architecture, cross-account identity and access management, virtual network segmentation, and security group posture for the enterprise's cloud workloads. When PACS is deployed as a customer-hosted cloud workload, these are the configuration decisions that determine whether a head-end compromise stays scoped to the PACS workload or pivots into production systems through trust relationships that the cloud security engineering function was not consulted to design. The cloud security function is almost never consulted on these deployments. The physical security team does not know to ask them. The integrator deploying the vendor's cloud image does not know to loop them in. The cloud security function discovers the PACS workload during a quarterly account inventory or during a security event that the workload contributed to, and by then the architectural decisions that determined the blast radius have already been made. The four-party coordination problem becomes a five-party problem for any hybrid or cloud-hosted deployment, and the fifth party is typically the one best equipped to prevent the lateral movement scenario the threat model treats as the consequential pathway.\n\nThe federal market's flow-down to commercial PACS is the structural mechanism most likely to move the supplier channel before commercial customer pressure alone would. CNSA 2.0 sets the trajectory for federal contractors handling classified and controlled-unclassified data, and the Department of Defense's CMMC framework, FedRAMP authorization, and DFARS clauses propagate that trajectory through prime contractor obligations to subcontractors. A defense contractor whose facility runs a particular PACS controller and credential family has to migrate that PACS to post-quantum on the federal timeline or lose contract eligibility. The PACS vendor whose product is deployed in that facility has to ship post-quantum or lose the defense contractor as a customer. Once that vendor ships a post-quantum product line for the federal customer, the same line becomes available across the commercial market, because PACS vendors do not maintain federal-only and commercial-only product families for the same purpose. The flow-down is the reason commercial enterprises with no federal exposure will see post-quantum PACS options earlier than their own market signals would predict.\n\n### The Identity Gap Is the Compounding Factor\n\nThe gap between the enterprise identity provider and the PACS credential system is where the ownership pattern compounds into operational consequence. Information technology owns the identity provider, which is typically Okta, Microsoft Entra, Ping Identity, or ForgeRock at large enterprises and which connects to the rest of the enterprise's logical access infrastructure through standard protocols. Physical security owns the PACS credential issuance system, which speaks its own data formats and connects to the identity provider through custom integration code that is maintained outside of standard identity governance tooling. The integration is typically point-to-point, brittle in ways that surface during identity provider upgrades or PACS vendor version changes, and rarely instrumented for the kind of monitoring that logical access integrations receive by default.\n\nThe operational consequence is that a terminated employee can lose single sign-on access in minutes through the identity provider while retaining badge access for days or weeks through a manual human resources to PACS deprovisioning handoff. A role-changed employee retains physical access appropriate to their previous role because the physical access review process is less consistent than the logical access review process, and the access drift accumulates across role changes over years without a corrective mechanism that matches the cadence of logical access governance. User access reviews for physical access are a security standard in information security practice, but they are less uniformly adopted in PACS environments than in logical access environments, and the physical access entitlement corpus is often the least-audited identity store in the enterprise despite being typically connected to the corporate directory through the same kinds of trust relationships that the logical access entitlement corpus uses.\n\nIdentity and access governance platforms—SailPoint, Saviynt, One Identity, C1, and others—are designed to govern logical and physical domains together through a single policy and audit framework. Few enterprises actually use them this way. Where the integration exists, it is usually point-to-point between specific systems rather than a unified governance layer, and the enterprise pays for the gap in audit complexity, in breach response time when an identity-related incident requires coordinated revocation across both domains, and in the accumulated access drift that operates as a slow leak rather than an acute failure.\n\nNone of this is caused by the post-quantum question. All of it compounds the post-quantum question, because an organization that cannot deprovision a terminated employee's badge within 24 hours will not execute a firmware signing certificate revocation within 24 hours when a cryptographic primitive is compromised. Operational hygiene is a prerequisite for cryptographic migration rather than an adjacent concern, and the enterprises that can execute the four migrations described earlier in this analysis are the same enterprises that have already solved the operational hygiene problems that the migrations depend on for execution.\n\n### The Commercial Real Estate Dimension Is Distinct\n\nBase building PACS is a problem most tenant-side security leaders have not analyzed in detail. The landlord owns the access control for shared amenities including the main lobby, elevators, parking, common areas, loading docks, and any shared conference or event spaces. The tenant owns the access control for office floors, conference rooms, information technology closets, and any tenant-specific amenities. An employee carries credentials for both systems, often on the same physical card or mobile wallet, which means the employee experience masks the architectural separation.\n\nThe cryptographic sophistication of the tenant's credential is constrained by the weakest link in the combined system, because the credential has to work across both systems and the joint architecture is bounded by the more conservative system's capabilities. If the base building runs 1990s-era proximity readers, the tenant's mobile wallet with hardware secure element architecture is irrelevant at the lobby turnstile because the credential has to fall back to the base building's protocol to authenticate at all. Many high-assurance tenants have not inventoried the base-building PACS they depend on, which means the actual cryptographic posture of the combined credential is unknown to the function nominally responsible for it.\n\nMobile wallet integration at a base building is also a sourcing and lifecycle problem. The architecture typically spans multiple vendors operating at distinct layers: a credential orchestration layer with SwiftConnect as the most visible name in this space alongside rf IDEAS, Sharry, and Safetrust in adjacent roles, a reader manufacturer such as Wavelynx or HID, the tenant experience application that the landlord operates, the mobile wallet platform layer at Apple, Google, or Samsung, and the underlying access control system. Lateral integrations into smart lockers, parking readers, and the enterprise identity platform on the tenant side extend the dependency surface further. When any vendor in this stack changes product direction, exits the market, or has a serious security incident, the integration typically falls back to legacy physical credentials while the affected component is replaced, and the coordination required across vendors is what determines the recovery timeline.\n\nThe joiner-mover-leaver problem specific to commercial real estate is that the tenant's identity system is not integrated with the landlord's credential issuance. Onboarding a new employee for base-building access is typically a manual ticket from the tenant to the landlord. Modifying access as the employee's role changes is a manual ticket. Offboarding a terminated employee is a manual ticket. The tenant cannot automate what the landlord has not exposed, and the manual process has no enforcement mechanism against the tenant's actual human resources ground truth. Someone will invariably retain base-building access who should not have it, because the manual ticket process produces gaps that the tenant's automated identity governance would have closed if it could reach the landlord's credential issuance system.\n\nThe forcing function that does not yet exist in commercial real estate is leasing terms. Corporate real estate executives on the tenant side have leverage over base-building security posture that has not been used at scale, and elevated leasing terms that at minimum give the tenant organization optionality to adopt heightened standards, bridge technologies, and integrated joiner-mover-leaver operations—written into the lease rather than negotiated after signing—are the lever most likely to shift large landlord posture. It would not take many sophisticated tenants with large portfolios to change the calculus for base-building operators because Class A commercial real estate is a competitive leasing market, and a consistent tenant requirement for base-building PACS cryptographic hygiene and joiner-mover-leaver automation would be operationally binding on landlords within two or three lease cycles. As of April 2026, this is rarely surfaced as a leasing term in corporate real estate negotiations even at organizations whose security posture would benefit from it.\n\n### Not All Environments Carry the Same Consequence\n\nHigh-security PACS does not matter equally across all environments, and the analysis should not pretend otherwise because a tone that treats every deployment as equally exposed reads as zero-risk advocacy rather than calibrated expertise.\n\nThe environments where the cryptographic posture matters most are those where the consequential systems adjacent to the PACS deployment are themselves consequential. Artificial intelligence research and frontier model development environments hold model weights, training infrastructure, and research data that carry nation-state adversary interest, and PACS compromise in these environments is a pivot point toward those assets through the lateral movement pathway documented in the threat model. Robotics, autonomy, and drone development facilities combine OT and information technology convergence with safety-system connectivity that carries regulatory scope, and PACS compromise in these environments is adjacent to safety-certified systems where the failure modes extend beyond the building. Biomedical research and life sciences environments combine regulated biometric enrollment with patient data exposure and research intellectual property, and the International Organization for Standardization 24745 compliance interacts with the Health Insurance Portability and Accountability Act and the General Data Protection Regulation in ways that compound the consequence of any single template breach. Cryptocurrency custody, trading, and cold storage facilities face vendor longevity as a first-order risk because the question of whether a specific PACS vendor will still exist in 2032 carries different weight for a firm holding billions of dollars in digital assets than it does for a typical corporate office. Defense-adjacent environments including government contractors, classified-capable facilities, and supply chain roles for defense primes inherit federal procurement standards asymmetrically, and the PACS posture has to meet the federal compliance framework whether the enterprise has formally opted into the framework or not.\n\nThe environments where the cryptographic posture matters less include generic low-to-medium-assurance corporate office space where the consequential systems are themselves not high-value targets, environments already physically supervised by present personnel where credential compromise is a secondary control rather than a primary one, and short-lease or temporary facilities where the installed-base lifetime argument that drives the urgency does not apply because the tenant will be gone before the deprecation window matters. Hospitality and retail sit in their own category where the cryptographic posture matters in principle but the economics of the industries make voluntary cryptographic refresh implausible, with hotel PACS dominated by magnetic stripe and legacy radio frequency identification lock systems using triple Data Encryption Standard or weaker proprietary cryptography, and retail back-office installed base running on 125 kilohertz proximity with no cryptographic protection at all. Combined installed base in these sectors is measured in tens of millions of readers globally, replacement cycles are driven by break-fix economics rather than by security refresh, and even if the enterprise corporate segment achieves post-quantum migration on the optimistic timeline the hospitality and retail installed base will remain cryptographically legacy for the decade beyond.\n\nWhen classical signing roots become forgeable, tens of millions of hospitality and retail credentials become forgeable in parallel, sitting at the intersection of payment systems, loyalty programs, employee access workflows, and stored-value services in industries that touch nearly every commercial transaction. Hotel keycards interact with room-charge billing. Retail employee badges control point-of-sale access. Loyalty credentials are linked to stored-value systems. The cryptographic legacy posture of the underlying PACS layer determines how cleanly compromise propagates across those adjacencies, and a permanently-vulnerable installed base of that scale shifts the failure-mode question from individual-site exposure to systemic exposure.\n\nThere is a second-order effect on the supplier channel. The PACS vendors who serve hospitality and retail also serve the commercial enterprise segment. A vendor whose largest-volume customer base does not refresh on cryptographic timelines has limited business case to invest in post-quantum products across the product line, and the supplier channel's post-quantum investment is partially driven by the volume customers who are not asking. Hospitality and retail inaction depresses post-quantum investment that the enterprise segment would benefit from, even though the enterprise segment is willing to pay for it.\n\nThe reader who does not operate in the environments where the cryptographic posture matters most is not the primary audience for the urgency in this analysis. The reader who does operate in those environments, and there are more of them than the industry's self-conception suggests, should calibrate the urgency to their own portfolio rather than to the industry average. A single facility in the matters-most category in a portfolio that is otherwise generic office is enough to justify the architecture work that the analysis recommends, because the consequence of compromise at the consequential facility is not averaged against the unconsequential ones. The portfolio question is properly evaluated facility by facility rather than as an aggregate, and the architecture should be calibrated to the highest-consequence facility in the portfolio rather than to the median.\n\n## What Would Have to Be True for the Industry to Meet the Deadline\n\nThe conditions for a different outcome are accountable rather than aspirational, and most of them are unlikely to materialize on the timeline that would matter. The honest assessment is the structural condition of the supplier channel, the platform layer, and the enterprise operational hygiene that the migration depends on, evaluated against the four-year planning horizon set by the deprecation window. The migration is staged against refresh cycles and procurement specifications, not a forklift replacement of the installed base.\n\nPACS credential vendors would need to ship post-quantum-native products by 2028 to give enterprise procurement and integration cycles enough time to reach meaningful installed-base coverage by 2030. Thales has the MultiApp 5.2 Premium PQC in field for European government identity and the underlying smart card platform is adaptable to other applications, and the equivalent PACS-positioned product from HID, Allegion, or a comparable vendor would require announcement in 2026 for delivery in 2028. The Infineon SLC27 silicon and equivalent secure element platforms provide the foundation. The constraint is vendor prioritization rather than technical feasibility, and the likelihood is moderate if customer pressure materializes through procurement specifications and request-for-proposal language and low otherwise. The customer pressure has not yet materialized at the scale that would shift vendor roadmaps.\n\nThe OSDP working group would need to publish version 2.3 with post-quantum support by 2027 to give vendors enough time to implement the standard by 2028, and the installed base would need field-upgrade paths that most currently shipping reader hardware does not support, which means even a successful standards revision would not address the installed base for the deployments running readers that cannot accept the firmware updates the new specification would require. The likelihood is very low because no version 2.3 timeline has been announced and the protocol revision cadence has been roughly nine years between substantive updates over the past decade.\n\nController vendors would need to ship post-quantum firmware signing roadmaps by 2029 to align with the deprecation window. HID Mercury would need to announce a roadmap with specific algorithm choices, ideally LMS or XMSS to align with CNSA 2.0 specifications, and the comparable competitors would need similar announcements. Microchip's PSOC Control C3 demonstrates that CNSA 2.0-compliant controller silicon exists and is achievable through reasonable engineering work. The likelihood is low without customer pressure that has not yet emerged from the enterprise security buyers who would have to drive it.\n\nMobile wallet platforms would need to achieve full post-quantum capability by 2030 across the three relevant secure element architectures: Apple's Secure Element with ML-DSA extension to support credential signatures, Google's Titan M3 or successor with native post-quantum support across the Pixel device population, and Samsung's Knox Vault evolution with similar capability across the Galaxy flagship line. The Titan M3 is rumored for Pixel 11 in late 2026 with post-quantum positioning that has not been publicly confirmed. The likelihood is moderate, because platform vendors have clearer commercial incentives, tighter product refresh cycles, and deeper engineering capacity than PACS-industry vendors, and the post-quantum work in adjacent product categories at Apple and Google demonstrates the institutional capability to execute the migration when the platform business case is sufficient.\n\nCommercial real estate standards would need to mature by 2029 in a way that obligates landlords to specific cryptographic posture for base-building PACS. The Building Owners and Managers Association, the Urban Land Institute, or a comparable industry body would need to publish guidance, and as of April 2026 nothing of this nature is in development. Tenant-side leasing pressure is the more likely forcing function and is achievable on a faster timeline than industry-wide standards work, with the likelihood low organically and moderate if sophisticated tenants begin including cryptographic hygiene and joiner-mover-leaver requirements as standard leasing terms during the 2026 to 2028 lease renewal cycles.\n\nEnterprise operational hygiene would need to improve to support cryptographic migration. Factory password rotation, pre-shared key management with documented rotation cadence, integrated joiner-mover-leaver operations across logical and physical access, user access reviews for physical access at the same cadence as logical access, and public key infrastructure infrastructure mature enough to support certificate lifecycle management for PACS endpoints would all need to become standard practice rather than the aspirational state most enterprises currently inhabit. These are widely reported as inconsistently implemented across the enterprise PACS installed base. The likelihood is low without a forcing event, and the forcing events that would change this typically arrive as breach disclosures rather than as procurement maturation.\n\n### The Synthesis\n\n| Condition | Required by | Likelihood |\n|---|---|---|\n| PACS credential vendors ship post-quantum-native products | 2028 | Low to moderate |\n| OSDP v2.3 with post-quantum support | 2028 | Very low |\n| Controller firmware signing post-quantum roadmaps | 2029 | Low |\n| Mobile wallet platforms achieve full post-quantum capability | 2030 | Moderate |\n| Commercial real estate standards or leasing-term pressure | 2029 | Low organically |\n| Enterprise operational hygiene matures | 2028 | Low |\n\nOne condition is moderately likely. Four are unlikely. One is very unlikely. The honest assessment that follows from this distribution is that the conditions for the PACS industry to meet the 2030 deprecation deadline, are not in place. The realistic planning horizon is that PACS trails the cyber side by three to five years at minimum, that enterprises in high-consequence verticals will need to drive their own hybrid or parallel migrations rather than waiting for the supplier channel to produce fully aligned product, and that the recommendations in the next section have to assume the industry will not solve the problem on the timeline the deprecation window requires.\n\n## What the Different Audiences Should Actually Do\n\nThe recommendations that follow are organized by the audience that has the authority and the operational responsibility to act, because the same recommendation lands differently when it is directed at the security leader who has to execute it, the physical security director who has to coordinate the change, the corporate real estate executive who has to negotiate the leasing terms, the vendor who has to ship the product, and the board member who has to ask the right question at the next cybersecurity review. The audiences are not interchangeable, and the recommendations should not pretend they are.\n\n### For Information Security Leaders\n\nFive questions are worth asking at the next PACS strategy review, and the answers will locate the organization on the migration curve more reliably than any vendor's roadmap presentation will. The first question is what the written post-quantum roadmap is from each PACS vendor in the stack, covering credential, reader, controller, and head-end software, and covering each of the four migrations. A vendor who cannot produce a written roadmap with specific algorithm names, specific implementation milestones, and a specific timeline through 2030 is not actually building to the deprecation deadline regardless of any general post-quantum positioning their marketing produces, and the planning assumption should be that vendors without written roadmaps by late 2026 will not deliver in 2028.\n\nThe second question is where the PACS sits on the network and who audits its cybersecurity posture. The 2022 Trellix vulnerability chain on HID Mercury demonstrated unauthenticated remote code execution at the maximum CVSS score on the controller, which is a Linux device with network connectivity, and the controllers should be in scope for security operations center monitoring, OT-appropriate network behavior monitoring through tools like Nozomi, Claroty, or Dragos, network segmentation review, and vulnerability management cycles aligned with the vendor's firmware release cadence. If they are not, that is the finding the security leader should report to leadership rather than waiting for the next vulnerability disclosure to surface the gap. For any portion of the PACS hosted in the organization's own cloud tenant, the question extends to which Amazon Web Services or Azure account the workload lives in, what identity and access management permissions the PACS application holds, whether the workload's virtual private cloud shares trust relationships with production accounts or with accounts holding customer data, and whether the enterprise's cloud security engineering function has reviewed the deployment architecture. The answer to the last question is frequently no, and when the answer is no the finding is not a PACS problem, it is a cloud governance gap that the PACS deployment has exposed.\n\nThe third question is the measured lag between human resources offboarding and badge deactivation, and how physical access is reviewed over the lifecycle of an employment relationship. A lag measured in days or weeks rather than minutes indicates a manual identity lifecycle, and the same manual process will not accommodate the cryptographic migration's automated revocation requirements when a firmware signing certificate or a credential authentication certificate has to be revoked across the installed base. Physical access should be covered by user access review cycles equivalent to those for logical access, and the absence of this coverage is itself the finding.\n\nThe fourth question is the current state of cryptographic hygiene on PACS endpoints, including factory default credentials on management interfaces, whether a documented pre-shared key rotation policy exists for OSDP secure channels and whether the deployment supports executing it, and firmware update cadence for controllers. These patterns are widely reported as the industry default rather than as universal failures, and whether they apply in any specific environment is verifiable rather than assumed. Their presence is not a migration blocker in itself, but it signals whether the operational foundation exists for the migration the article calls for.\n\nThe fifth question is where in the portfolio PACS compromise is most consequential and whether the architecture is calibrated to that consequence. The artificial intelligence research environment, the cryptocurrency custody facility, the biomedical research floor, the defense-contract space — these do not need the same PACS posture as generic office space, and treating them uniformly underinvests in the exposed environments and overinvests in the unexposed ones.\n\nTwo additional recommendations do not fit the question format. New deployments should favor wallet-native near-field communication over vendor-app Bluetooth Low Energy, with the explicit recognition that the wallet sits on top of the PACS credential layer rather than replacing it, because the architectural case for near-field communication over Bluetooth Low Energy is overwhelming and the platform vendors have clearer post-quantum roadmaps than the PACS-industry incumbents. New match-on-server biometric systems should not be deployed at all, because they violate the requirements that International Organization for Standardization 24745 sets for biometric template protection and they create permanent-harm exposure that cannot be undone through subsequent remediation.\n\n### For Physical Security Leaders\n\nThe physical security function has the operational responsibility for PACS and the relationships with the integrator channel that determine which products get installed, and the function's highest-impact action in 2026 is to build enough cryptographic fluency to ask vendors the right questions. The distinction between ML-KEM for key exchange and ML-DSA for signatures, the procurement-relevant choice between LMS, XMSS, and SLH-DSA for firmware signing, and the architectural reasons why OSDP 2.2.2 is not a post-quantum answer, are all learnable in a two-day workshop with the information security function. Vendors who cannot answer at this level of specificity are selling roadmap rather than product, and the cryptographic fluency is what allows the physical security leader to distinguish between the two without having to take the vendor's word for it.\n\nCoordination with information security that does not happen by default should be initiated by the physical security function rather than waited for. The ownership pattern documented in the previous section does not self-correct, and physical security functions that invite information security into credential standard selection, PACS network security architecture, and firmware management decisions close the structural exclusion before a forcing function does it for the organization. This works in both directions, because information security functions that have not engaged with physical security typically have not surfaced the PACS attack surface to the security operations center either, and the coordination produces visibility benefits across both functions.\n\n### For Commercial Real Estate Leaders\n\nBase-building PACS will become a tenant expectation in high-consequence verticals, and the corporate real estate function on the landlord side should anticipate the conversation rather than wait for it. Financial services, federal contractors, biomedical and life sciences, frontier artificial intelligence and robotics tenants will begin asking post-quantum questions during 2027 and 2028 lease negotiations, and Class A buildings that cannot answer will lose differentiation in leasing markets where alternatives exist. Open-architecture readers from Wavelynx, rf IDEAS, and comparable vendors are a structural preference over proprietary stacks, because proprietary stacks create provider-dependency failure modes where a single vendor's product direction change forces the entire deployment back to legacy credentials while the integration is rebuilt.\n\nReader refresh cycles should be aligned with the deprecation window. Readers installed in 2025 will need replacement or upgrade by 2030 on the NIST IR 8547 deprecation timeline. Capital planning cycles need to incorporate the deprecation pressure in the 2026 budget year rather than in 2028 when the procurement window has compressed. The most effective forcing function on the tenant side is leasing terms that include cryptographic hygiene and joiner-mover-leaver requirements as standard conditions written into the lease rather than negotiated after signing, and a small number of sophisticated tenants with large portfolios is enough to shift the calculus for base-building operators in competitive leasing markets.\n\n### For PACS Vendors\n\nPost-quantum roadmaps should be published in 2026. The customers who will still be customers in 2030 are the ones asking now, and vendors who cannot respond will be replaced by competitors who can. Match-on-server biometric systems should be retired from active marketing as \"high security\" deployments because the architecture is indefensible under International Organization for Standardization 24745:2022 and the sophisticated customer increasingly knows it. OSDP Transparent Mode should be supported across reader platforms because HID's March 2026 patent opening enables better architectures across the industry, and the vendors that adopt it will benefit from the broader interoperability. The customer conversation has changed, and the security leaders who were not asking post-quantum questions in 2024 are asking in 2026, will ask loudly in 2028, and will have set the market expectation by 2030 that vendors who cannot answer will not be invited into procurement processes.\n\n### For Board Members and Audit Committees\n\nThree questions are worth asking at the next cybersecurity review. The first is who owns PACS cryptographic strategy in the organization. If the answer is ambiguous, the ownership gap is itself the finding the board should escalate, because the cryptographic deprecation window will not be met by an organization that has not assigned the responsibility for meeting it. The second question is when the organization's PACS will be post-quantum-ready and what the specific deliverables are for the current fiscal year. If management cannot answer with specifics, the audit finding is that management does not know, and the work that should be on this fiscal year's plan has not been planned. The third question is where in the organization's portfolio PACS compromise is most consequential and whether the architecture is differentiated to match. The artificial intelligence research environment is not generic office space, and the cryptocurrency custody facility is not generic office space, and treating consequential environments uniformly with generic environments accumulates risk silently rather than acutely. The board does not need the cryptographic details. The board needs to understand that vague answers, missing answers, and deferred answers are themselves the audit finding.\n\n## The Architecture Is Ready. The Industry Is Not.\n\nThe cryptographic primitives underneath physical access control face a deprecation window that is shorter than it looks, and they sit on a supply chain that has not moved. The silicon has been productized, with Infineon's SLC27 dual-interface security controller in production volume since October 2025. The smart card platform has been certified, with Thales's MultiApp 5.2 Premium PQC implementing ML-DSA at parameter set 65 and certified at Common Criteria EAL6+2 since October 2025. The standards are finalized, with FIPS 203, FIPS 204, and FIPS 205 published in August 2024 and the broader ecosystem of NIST IR 8547 and CNSA 2.0 setting the trajectory the commercial market is increasingly following. The hyperscalers, the HSM vendors, the mobile platform operators, and the enterprise public key infrastructure vendors are all building on this foundation.\n\nPhysical access control is not building on it. No major North American PACS credential vendor has announced a post-quantum-native product, no major controller vendor has published a post-quantum firmware signing roadmap, the OSDP has not published a version 2.3 timeline, and the installed base of readers, controllers, and credentials will still be in service when the deprecation window closes and through whatever period the CRQC question follows. The cyber side is on it. The physical side is not.\n\nThe security leader reading this analysis has four years to align with the answer. Not to complete the migration, because that is a longer horizon and the supplier channel will determine when the products that the migration requires actually become available, but to know which vendors are on the roadmap and which will be replaced, which controllers are network-accessible pivot points that should be in scope for cybersecurity oversight, which credential decisions are reversible and which are not, and which environments in the portfolio matter most. Those are the four-year questions. The two-year question is whether the organization is asking them at all.\n\nThe deadline is not coming on the nominal timeline. It is coming on the compressed one, and the day that the first major customer of a major PACS vendor asks for a written post-quantum roadmap and does not get one is the day the market begins to correct.\n","canonical_url":"https://chrischerry.me/writing/2026-04-24-post-quantum-gap-pacs","content_version":2,"post_id":"2026-04-24-post-quantum-gap-pacs","published_at":"2026-04-24T00:00:00Z","revised_at":"2026-05-14T00:00:00Z","tags":["Cybersecurity","Physical Security"],"thesis":"The cyber-versus-physical asymmetry in post-quantum migration reflects vendor prioritization rather than technical feasibility. The PACS industry has four years to align with a deprecation window the supplier channel is not yet building toward, and the security leader's job is to know which vendors are on the roadmap and which will be replaced before the procurement window narrows.","title":"The Post-Quantum Gap the PACS Industry Has Not Closed","wordCount":15392}