Week ending September 18, 2026 — Sector Watch

The OpenID Foundation and FIDO Alliance published post-quantum migration assessments a day apart this week, and both landed on the same conclusion from different standards: the signature algorithm is the easy part. OpenID’s September 17 write-up notes the IETF standard enabling ML-DSA for OpenID Connect is already done, then spends the rest of the piece on what still isn’t — oversized PQC signatures that blow past cookie-size assumptions baked into browsers, a JWKS-parsing bug already surfacing in libraries that choke on the new key type, and a client-registration model that locks a relying party to one signing algorithm with no fallback during a mixed classical/post-quantum transition. FIDO’s September 16 piece, from a co-chair of its own PQC Study Group, makes the parallel case for passkeys: migrating means reissuing an entire X.509 attestation trust chain and swapping the ECDH key agreement inside CTAP’s PIN protocols for a post-quantum KEM, both harder than replacing the credential key pair itself. Both standards are quantum-safe at the spec layer. Neither is quantum-safe anywhere a user or a relying-party library would notice yet.

Standards in motion

Enterprise & web identity

OpenID Connect’s post-quantum path is specified; the ecosystem around it isn’t. Post-Quantum OpenID Connect, posted September 17 by Phil Schmieder (University of Wuppertal) and Cloudflare’s Ethan Heilman for the OpenID Foundation, opens by noting the underlying cryptography is finished — “the IETF standard enabling ML-DSA signatures for OpenID Connect is done.” What follows is a catalog of what breaks once implementers try to use it: ML-DSA and SLH-DSA signatures run 10 to 100 times larger than RSA’s, enough to strain ID token size assumptions built around browsers’ roughly 4KB cookie limits; a JWKS-parsing bug already surfaces in libraries that reject the new AKP key type outright; and most JWT libraries the authors surveyed list “no plans yet” for ML-DSA support. OpenID Connect’s own registration model compounds it — id_token_signed_response_alg locks a relying party to one algorithm at registration, with no negotiated fallback for a transition period running both classical and post-quantum signatures at once. Adoption read: the cryptographic standard exists; the libraries and the negotiation mechanism implementers would need to actually deploy it don’t yet.

FIDO’s post-quantum migration runs through attestation and PIN protocols, not just the signature algorithm. Writing on FIDO Alliance’s news channel September 16, Johann-Philipp Thiers — a co-chair of FIDO’s PQC Study Group — lays out three places a passkey migration has to clear before the credential key pair does. Hardware authenticators with limited memory and compute have to fit larger PQC keys and signatures through transport limits like CTAP-HID’s message-size cap. The X.509 attestation chain that lets a relying party trust a given authenticator model runs on ECC or RSA today and has to be reissued wholesale, not swapped key by key. And CTAP’s PIN/UV Auth Protocols use ECDH for their secure channel, which a PQC migration would replace with a key-encapsulation mechanism like ML-KEM — again pushing larger messages through the same constrained transport. His assessment of FIDO’s underlying design is a genuine positive: “FIDO already has a relatively high degree of crypto-agility… FIDO is therefore in a comparatively good position.” What’s missing is coordination across operating systems, browsers, authenticator vendors, metadata services, and certification programs — not the algorithm.

Telecom trust

SK Telecom proposes RCS as the verification channel for AI agent payments, not another in-app approval screen. SK Telecom hosted the GSMA RCS Group’s standardization meeting in Seoul September 15–18, with AT&T, T-Mobile, Vodafone, Orange, Apple, Google, and Samsung among the attendees, and used the September 17 session to propose “AI Agent Approval over RCS”: when an AI agent is about to book something or spend money on a user’s behalf, the final approval runs as a verified RCS message — carrying the sender’s registered business name and logo and an in-message approve button — rather than a confirmation screen inside whichever app the agent runs in. The pitch is a portable, consistent trust signal on RCS’s existing sender-verification machinery, regardless of which AI agent triggered the request, instead of each agent vendor building its own approval UX inside its own app. It’s a proposal on GSMA’s agenda, not an adopted standard — the September 17 session was where the case got made, not where it got decided.

Implementations & adoption

GOV.UK One Login puts passkeys in front of 23 million users, and a tenth of them switched in a month. The UK’s Government Digital Service rolled out FIDO2/WebAuthn passkey sign-in across GOV.UK One Login, which serves 23 million people across more than 250 government services, using a phased release that prompts users to set one up at natural moments — like signing in — rather than forcing the switch. In the first month, GDS reports, almost 10% of users — around 300,000 people — had already set one up, cutting sign-in time by more than half and moving users off the password-and-SMS-code flow the National Cyber Security Centre has been recommending against. Adoption read: 23 million potential users and roughly 300,000 already switched in the first month is passkey adoption at national-identity scale, not an enterprise pilot.

Singpass adds Android passkeys, eight months after iPhone. Singapore’s national digital identity system, Singpass, extended passkey login to Android users this week, following an iPhone beta that launched June 30. About 800,000 passkeys were registered as of September 9, against a base of 5.5 million users across more than 1,400 government and private-sector services, including HealthHub, IRAS, CPF Board, and DBS Bank. Desktop support is due by year-end. Adoption read: a second national digital-ID system moving to WebAuthn-based sign-in, on the same anti-phishing rationale GOV.UK cited — Singapore’s government put 2025 phishing losses at S$39.9 million.

Entrust’s cryptographic bill-of-materials platform expansion names a data format, not a cryptographic standard. Entrust’s September 14 release ties a platform expansion to CBOM (Cryptographic Bill of Materials), the inventory format behind the live NIST/CISA deadline under Executive Order 14412, which gives the two agencies roughly 270 days from the June 22 signing to publish minimum CBOM elements. The release names no post-quantum algorithm — no ML-KEM, no ML-DSA — no FIPS number, and no CycloneDX or other CBOM schema by name; the standards content it cites is the regulatory drivers behind the platform, the EO and the EU’s DORA and NIS2 rules, not a specification it says the platform implements. That isn’t evidence the platform doesn’t implement one — vendor copy is written for buyers, not for standards readers — only that this release doesn’t say which, if any, it does.