Two-Factor Sign-In on Every Path, Not Just the Login Page

Two-factor authentication is one of the best protections an account can have. Even if someone steals a password, they still need the second factor, usually a code from an authenticator app, to get in. When people turn it on, they reasonably expect their account to be protected.

There is a catch that many applications miss. Two-factor authentication usually guards the login form. But modern applications have many other ways to sign someone in: emailed magic links, invitation links, account recovery links and sign-in through another service. If any of those paths signs a person in without asking for the second factor, the protection has a side door.

The side doors

Here are the paths we found in our own platform that could sign someone in:

• The main sign-in page, where people enter an email and password
• The admin sign-in page, used by organization staff
• Magic links, which sign someone in from an emailed link
• Billing recovery links, which help a customer fix a payment problem
• Account invitations, which welcome a new team member
• Single sign-on, where a person signs in through a connected service

Each of those is useful. Each was also a place where a person with a stolen email inbox, or a stolen link, could skip the second step if the code did not check.

Our rule: nobody signs in on a first factor alone

A user who has confirmed two-factor authentication is never signed in on the first factor alone, no matter which path they arrive by. Every path that would sign someone in first checks whether that person has two-factor turned on. If they do, the path hands off to the same two-factor challenge used by the main sign-in page instead of signing them in directly.

One gate in the code

To make the rule reliable, the decision lives in one shared place. Any code that signs a person in asks the same small gate: does this person need the second factor? If yes, the code sends them to the challenge. If a developer adds a new sign-in path in the future, our standards tell them to call that gate first.

Centralizing the rule matters. If each path implemented its own version of the check, one would eventually drift. With a single gate, there is one place to review and one place to fix.

The passkey exception

Passkeys are the one path that does not trigger an extra challenge, and that is deliberate. A passkey sign-in already requires the person to verify themselves on their own device, typically with a fingerprint, face or device PIN. It combines something they have with something they are or know in a single step. Asking for another code would add friction without adding meaningful protection. Our article on why we support passkeys explains more.

Testing every door

We test sign-in paths the way an attacker would think about them. For a test account with two-factor turned on, we try each path and confirm it ends at the challenge rather than inside the account. When a new path is added, it joins that list.

Recovery without bypass

People lose phones. A good two-factor system offers recovery codes that can be used once each, stored somewhere safe. Recovery is a legitimate second factor, not a bypass. What we avoid is any recovery flow that quietly turns two-factor off because someone clicked an email link.

Protecting the accounts attackers want most

Organizations on our platform manage members, donations, orders and private messages. Their administrators are exactly the accounts attackers want. Making sure two-factor protection holds on every path is one of the most valuable security investments we have made, and it costs customers nothing but a few seconds at sign-in. It reflects the same thinking as a hidden button is not security: protection has to exist wherever a request can enter.

Frequently asked questions

Can a magic link bypass two-factor authentication?

It should not. On our platform, a magic link for an account with two-factor turned on leads to the two-factor challenge rather than signing the person in directly.

Why do passkeys not ask for a second code?

Passkeys already require the person to verify themselves on their own device, which provides the protection a second factor is meant to add.

What should I do if I lose my two-factor device?

Use one of the recovery codes you saved when you set up two-factor authentication. Each code works once.