Skip to content

Stop using PII as evidence of identity

Date of birth, address, mother's maiden name: none of these prove you are who you say you are. After years of mass breaches, PII-based identity verification is security theatre.

Date of birth. Address. Mother's maiden name. Medicare number. Driver's licence number.

These are the things organisations still ask for when they need to verify your identity. The problem is that none of them are secret anymore, and most never were.

What the breaches actually changed

The Optus breach in September 2022 exposed personal information of roughly 10 million current and former customers, including names, dates of birth, phone numbers, and, for some, driver's licence and passport numbers. The Medibank breach followed weeks later, exposing data from 9.7 million current and former customers. Latitude Financial in 2023 hit 14 million records, including driver's licence numbers and passport details.

These are not edge cases. They are a pattern. And the pattern says: assume PII is public.

If your identity verification process relies on information that has been exposed in a breach, your verification process is checking whether an attacker has read the news, not whether they are who they claim to be.

PII was never great evidence

Even before the breaches, using PII as identity proof had structural problems.

Date of birth is not secret. You share it with roughly 20 million other people born the same day worldwide. It appears on social media, in voter rolls, in public records. The birthday paradox makes it worse: in a group of just 23 people, there is a roughly 50% chance two share the same birthday. In a customer database of 100,000 people, the chance of collision on date of birth alone is essentially guaranteed.

Mother's maiden name is a genealogy question, not a security control. It appears in public family records, social media posts, and data broker databases.

Driver's licence and passport numbers sound more convincing, but they are static identifiers. Once exposed, they cannot be changed without significant effort, and most people will not change them after a breach. They also cannot be rotated like a password.

Address changes when you move, which means the person verifying you against an address might not be verifying the right period. And address data is widely available through data brokers and previous breaches.

The common thread: all of these are something you are or something that was assigned to you. None of them require the claimant to prove they currently possess a unique, revocable token.

What identity verification should look like

The right model flips the question. Instead of asking "what do you know about this person?" it asks "can you prove you currently control this channel or device?"

That means verification based on:

  • Phishing-resistant MFA such as passkeys (FIDO2/WebAuthn) or hardware security keys. I wrote more about this in Does password complexity matter?.
  • Device-based attestation where the device itself proves its identity through a trusted hardware root.
  • Verified credentials that use cryptographic proofs without revealing the underlying data. The No Phone Home initiative pushes exactly this: verify the credential without calling back to the issuer and creating a surveillance trail.
  • Out-of-band verification through a channel the attacker is unlikely to also control, such as pushing a notification to a trusted device.

The shift is from knowledge-based authentication (what you know, which is no longer privileged knowledge) to possession-based or cryptographic authentication (what you have, or what only your device can prove).

Why organisations still do it

Change is slow for three reasons.

First, many regulations and industry standards still reference PII-based verification as acceptable. Compliance frameworks have not caught up with the breach reality.

Second, legacy systems are hard to retrofit. A banking platform that has verified customers by asking for date of birth for twenty years does not swap that out on a Tuesday afternoon.

Third, there is a convenience argument. Knowledge-based verification is easy for the user. No app to install, no key to register, no device to manage. But convenience that undermines security is not a good trade when the alternative is becoming simpler and more widely supported every year. Passkeys are evidence of that shift.

The regulatory direction

Australia's Privacy Act reforms are moving in the right direction. The Privacy and Other Legislation Amendment Act 2024 introduced requirements for organisations to disclose when substantially automated decisions significantly affect individuals' rights, starting December 2026. The broader reforms under discussion include stronger requirements around identity verification and data minimisation.

If your verification process requires you to collect and store more PII than necessary, the regulatory gap is only going to widen. Organisations that move to PII-minimising verification now will be ahead of that curve.

What to do this week

  1. Audit your verification flows. List every place your organisation asks for PII as identity proof. You will probably find more than you expect.
  2. Classify each verification by sensitivity. Which ones are protecting low-value transactions versus high-value ones? Which ones are customer-facing versus internal?
  3. Start with the highest-risk flows. Replace knowledge-based verification with phishing-resistant MFA or passkey-based verification where the stakes justify it.
  4. Stop collecting PII you do not need. If your verification process relies on collecting a driver's licence number and storing it, you are creating a breach target that doubles as a broken identity proof. I made this argument in MFA on shared accounts: the best thing you can do with unnecessary PII is stop collecting it.
  5. Push for industry change. Talk to your industry body, your regulator, your peers. The standards will not update themselves.

PII-based verification is not a thing of the past yet. But it should be.


If you want practical next steps on authentication, start with Enable MFA everywhere for what to turn on today, and Does password complexity matter? for why the password itself is not the control you think it is.

Olivier Reuland