On October 5, 2026, Denmark announced a breach affecting 8.8 million records in its Central Person Register. Names, addresses, and national ID numbers leaked through a company with lawful access. Within days, the Danish Resilience Agency issued guidance: knowledge-based authentication using this data should no longer be considered sufficient for high-risk operations.
This advice isn't new. NIST SP 800-63-4 already states that knowledge-based authentication "does not constitute an acceptable secret for digital authentication." Turkey's national ID database leaked in 2016. India's Aadhaar numbers have leaked multiple times from third-party systems. The pattern is clear: personal data will leak, and when it does, any authentication system built on "something you know about yourself" fails.
What Changed
The Denmark breach eliminates a category of authentication secrets that organizations have relied on for decades. If you're using CPR numbers, addresses, or dates of birth to verify Danish callers or account recovery requests, those checks now offer zero assurance. An attacker with the leaked dataset can answer every question correctly.
More broadly, this breach reinforces what security standards have stated for years: personal data is not cryptographic material. It can't be rotated like a password. It can't be revoked like a certificate. Once it's public, it's permanently compromised as an authentication factor.
Key Findings
Knowledge-based authentication has no floor. Adding more questions just creates more opportunities for future leaks. The next breach might expose mother's maiden names, previous addresses, or employment history. Building deeper knowledge checks is building on sand.
Phone-based and account recovery flows are now your weakest link. Many organizations use strong authentication for web logins but fall back to personal data verification during phone calls or password resets. Attackers will target these decoupled flows where authentication happens on a different device than the access request.
[OpenID Connect Client-Initiated Back-Channel Communication Authentication (CIBA)](https://openid.net/specs/openid-client-initiated-Back-Channel Communication-authentication-core-1_0.html) solves decoupled authentication. CIBA lets you send an authentication request directly to a user's device during a phone call. The user approves on their phone, and your agent sees the result. You get strong authentication without requiring the user to be at a computer.
Channel binding prevents man-in-the-middle attacks in decoupled flows. When authentication happens on a different device than the access request, you need to tie the two together. CIBA supports this through binding mechanisms like displaying a random code in the authentication app that the user reads to the agent, who verifies it matches the request before proceeding.
Open standards reduce switching costs. Organizations using OpenID Connect and CIBA can integrate with multiple identity providers and switch vendors without rebuilding their authentication stack. For high-security use cases, look for vendors certified against FAPI-CIBA conformance profiles, which validate compliance through a thorough test suite.
What This Means for Your Team
If you're authenticating Danish users, you have an immediate compliance problem. The Danish Resilience Agency's guidance specifically calls out high-risk operations like account recovery. Review every flow where you verify identity using CPR numbers or personal data.
If you're not authenticating Danish users, you still have a problem. Your country's national ID system, social security numbers, or civil registry will eventually leak. Knowledge-based authentication is a time bomb with an unknown fuse.
The technical challenge isn't implementing strong authentication for web logins; most organizations already do that with OAuth 2.0 and OpenID Connect. The challenge is extending strong authentication to phone calls, chat support, account recovery, and any other scenario where the user isn't logging in through your web or mobile app.
Action Items by Priority
Immediate: Audit your phone and account recovery flows. Map every scenario where your team verifies identity using personal data. Call centers, helpdesks, account recovery processes, and fraud investigation workflows are common gaps. Document what data you're using and what access it grants.
Week one: Replace personal data checks with push authentication. Implement OpenID Connect CIBA to send authentication requests to users' phones during support calls. The agent initiates the request, the user approves on their device, and the agent sees a success or failure result. This works with national electronic IDs, authenticator apps, or any identity provider that supports CIBA.
Week two: Add channel binding to decoupled flows. Configure your CIBA implementation to display a random code in the user's authentication app. The user reads this code to the agent, who verifies it matches before proceeding. This prevents an attacker from intercepting the authentication request and approving it on their own device.
Month one: Evaluate identity provider certification. If you operate in financial services or handle sensitive data, prioritize vendors with OpenID Certification against FAPI-CIBA profiles. Certification validates that the implementation follows security practices and handles edge cases correctly.
Ongoing: Remove personal data from authentication entirely. Stop collecting dates of birth, mother's maiden names, or previous addresses for authentication purposes. If you need this data for other reasons, store it separately and never use it to verify identity. Train your support team to refuse authentication attempts based on personal data, even if the caller provides correct answers.
