News, events & blog

The Most Secure Login Can Still Have an Insecure Back Door

If you protect login with strong authentication but let users regain access through an email link, a couple of personal questions, or a support agent who can be talked into anything, that recovery flow becomes the weakest link in your entire identity setup.

That's not a small detail. Account recovery is an identity decision: when someone loses their usual credential, how do you actually know the person asking for access is who they claim to be?

Recovery is a different problem than login

Authentication asks a simple question: can this person prove they control a credential already tied to the account? Recovery exists precisely because that proof might be gone. 

• a phone got lost
• apasskey isn't available anymore
• someone switched devices. 

So you need a different basis for trust. NIST's current Digital Identity Guidelines treat recovery as its own category, separate from ordinary login. NIST recognizes recovery codes, recovery contacts, and repeated identity proofing as valid recovery methods, and requires recovery events to trigger notifications so users can catch fraudulent attempts. The underlying principle applies even if you don't formally follow NIST: recovery shouldn't quietly lower the assurance level of the whole account.

Attackers strike after onboarding, not just at signup

Identity risk doesn't end the moment someone successfully registers.

Entrust's 2026 Identity Fraud Report, built on over a billion verification attempts across 195 countries, found that most payment fraud happens after onboarding, and flagged account takeover as a particular risk in industries where accounts hold long-term value.

That should change how you think about identity verification. It's not just a gate at signup. If you verified someone's identity strongly the first time, you have more options later when normal login fails: NIST's latest guidance even recommends recovery flows that repeat parts of that original identity proofing. Verification, done well once, can pay off twice.

Passkeys fix login. They don't fix recovery.

Passkeys remove a lot of the weakness baked into passwords: no reusable secret to send around, resistance to standard phishing, and their standards foundation just hit another milestone. But swapping a password for a passkey doesn't make the recovery question go away. Someone can still lose a device. An authenticator can still become unavailable. You still need a policy for binding new authenticators and handling the exceptions.

The right architecture isn't "password → passkey." 

It's: 

establish identity → bind strong authentication → manage authenticators → recover with the right level of assurance when something breaks → authenticate again.

Match recovery to what's actually at stake

Not every account deserves the same recovery process. Losing a newsletter login and losing a bank account have very different consequences, so your recovery assurance should scale with the risk.

Worth asking your team:

• What could an attacker do once they've successfully "recovered" this account?
• Is our recovery weaker than the authentication it bypasses?
• Was the customer's identity verified strongly enough to support re-checking it later?
• Does the legitimate user get notified, independently, when recovery happens?
• Can support staff override security controls — and under what conditions?

Lock recovery down too hard and you'll shut out real customers. Make it too easy and your strong authentication is just theater.

Recovery is also a customer experience problem

People lose credentials. Any system that assumes they won't is unrealistic. NIST itself acknowledges this: recovery happens rarely, so it's allowed to be a little less convenient than everyday login — even involving a waiting period.

That gives you a clean design principle: optimize everyday authentication for convenience, and optimize recovery for confidence. They don't need to be the same experience. A customer might sign in daily with a fast passkey tap, while losing every authenticator at once is rare enough to justify asking for stronger proof.

The international problem and where eeID fits

For global services, recovery gets harder because your customers don't share one identity system. An Estonian customer might use an ID-card, Mobile-ID, or Smart-ID. Someone elsewhere in Europe uses a different national eID or an eIDAS-supported method. Others need document-based verification. Building each route separately means more engineering work and inconsistent assurance across markets.

That's the fragmentation eeID, from the Estonian Internet Foundation, is built to remove. It brings Estonian ID-card, Mobile-ID, Smart-ID and Smart-ID+, eIDAS, Latvian and Lithuanian solutions, Belgium's CSAM, Czechia's MojeID, Portugal's Autenticação.gov, and Sweden's Freja+ together in one integration, with Veriff and FIDO-based authentication covering international identification. That lets you treat identity as a reusable security layer instead of a box you check once at registration.

Picture a modern identity setup as a chain: identify → authenticate → authorize → monitor risk → recover securely → authenticate again. The weakest link sets the security level for the whole thing.

If you swap a phishable password for a passkey but leave an easily-manipulated recovery flow in place, you've polished the most visible part of the system without closing the door an attacker actually wants to walk through. The fix usually isn't more friction everywhere, it's stronger evidence exactly at the moments trust needs to be rebuilt.

Identity verification pays for itself more than once. eeID combines electronic identity, international ID methods, document verification, and passkey authentication in one service, with usage-based pricing: as of the price list effective 1 April 2026, passkey authentication runs €0.01, eID-based verification €0.08, and document verification €0.10 per request, excluding VAT.

Learn more about eeID service and contact us at info@internet.ee to book a demo!