If you already use a password manager, you have done the single most effective thing an individual can do about account security. Every login has its own long random password, nothing is reused, and the manager fills it in for you. So when someone suggests you should also give every site its own email address, the reasonable reaction is a shrug. The passwords are unique already. What is left to protect?
Quite a lot, as it turns out, though not for the reason alias services usually give. The point is not that a password manager is weak. It is that a login has two halves, and a password manager was only ever built to look after one of them.
This post is about the other half, and about how the two tools divide the work when you run them together.
What a password manager actually does for you
Be generous here, because it deserves it. The attack that unique passwords defeat is the most common one there is: someone takes a list of email addresses and passwords dumped from a breach at one site and tries the same pairs at hundreds of others. It works because people reuse passwords, and it stops working the moment they do not. The UK's National Cyber Security Centre puts it plainly on its consumer guidance: a password manager "stores passwords safely for you, meaning that you can have unique passwords for each service", and the risk it removes is that "if you use the same password across different accounts and one of your accounts is compromised, a hacker can try the same password on your other accounts". The NCSC's guidance for system owners describes the same attack from the other end, where attackers use "passwords leaked from data breaches to attack other systems where users have used the same password".
NIST agrees. The current revision of its Digital Identity Guidelines, SP 800-63B-4, published in 2025, tells anyone running a login form that verifiers "SHALL allow the use of password managers and autofill functionality", and it requires new passwords to be checked against a blocklist that includes "passwords obtained from previous breach corpuses". It also drops the old advice to force periodic changes. The whole document assumes the person on the other end has a manager generating something long and random, and builds the rest of its rules around that assumption.
A manager also does something quieter that matters more than people notice. Autofill only offers a password on the domain it was saved for, so a convincing lookalike login page gets nothing, because the manager does not recognise it. That is real phishing resistance, and it comes free.
So the objection is fair. On the password side, the job is done.
The half it cannot touch
The username, though, is almost always your email address, and your email address is the one credential you reuse at every site by design. You cannot not reuse it. It is how the site reaches you, how you reset the password, how they prove you are you. A password manager will happily store it, but it cannot make it unique, because there is only one of it.
It is also the half that leaves the building. When a company is breached, what turns up in the dump is a table of email addresses, sometimes with hashed passwords, sometimes with plaintext ones, often with names and order histories attached. The address is the column that never gets hashed, because it cannot be: it has to stay readable to send you email. It is the column that gets sold, cross-referenced against other dumps, and merged into the big combined lists that fuel the next round of attacks. Passwords rotate; addresses persist. And it is the field a phishing email is addressed to. The scam that follows a breach lands in the inbox tied to the leaked address, whether or not the password ever mattered.
If you have run your address through Have I Been Pwned and found it in a dozen breaches, that list is a record of every place your one shared credential has been. Our walk-through of what to do with the results covers the triage. The short version is that the passwords in those breaches were probably unique already, and the address is what connected them.
The credential-stuffing lens, made concrete
Picture what an attacker actually holds after a breach: rows of address and password. Credential stuffing is trying each row at other services. It relies on two things lining up: the password being reused, and the address being the same one used elsewhere.
Unique passwords break the first. The pair from site A does not open site B, because site B has a different password. That is the win the manager gives you, and it is a large one.
Unique addresses break the second. If site A only ever knew one alias and site B only ever knew another, there is no shared key to try. The attacker cannot even find your account at site B from the site A dump, let alone log into it. Nor can they feed the leaked address into a password reset form somewhere else, or into a "does this account exist" check, or into a phishing template written for customers of the other services you plausibly use. The password stops the login. The address stops the targeting.
The two defences also fail independently, which is what makes them worth stacking. A unique password does nothing when the breached site stored it in plaintext and the attacker simply reads it; the alias then makes it useless everywhere else. A unique alias does nothing when the attacker's aim is the breached site itself; the strong password limits what they can do once inside.
What breach data looks like either way
Take two people whose data sits in the same dump.
The first uses a password manager and one email address everywhere. Their row reads: their real address, plus a random password that opens nothing else. Good. But that address is now on a list. It will be matched against their rows from other dumps, because the address is identical in each. Someone can build a profile: this address shops here, banks there, has an account on that forum. Spam and phishing follow to the one inbox they cannot easily change. When the next breach happens, the address matches again.
The second uses a password manager and a different alias at every site. Their row reads: an address that exists nowhere else, plus a password that opens nothing else. It matches no other dump. It tells nobody where else they have accounts. When phishing arrives at that alias, they know exactly which company leaked it, and they can turn the alias off and move on. That knowledge on its own is worth having; working out who leaked your address is otherwise a guessing game.
The first person's exposure grows with every breach. The second person's stays where it started.
How the two tools share the work
The worry people have about aliases is bookkeeping. If every site has a different address, how do you keep track of them? The answer is that you already own the tool for it, and it is the password manager. Every login entry already has a username field. Put the alias in it. The record that says "this password goes with this site" now also says "this address goes with this site", and there is nothing new to remember. Autofill fills both.
In practice the split looks like this. The alias service owns the addresses: it creates them, forwards mail from them to your real inbox, and lets you switch any one of them off. The password manager owns the map: which alias and which password belong to which site. Neither tool has to know about the other for this to work. You make an alias, paste it into the signup form, save the login in the manager as you normally would, and the association is stored where you would go looking for it anyway.
A sensible order of operations for converting existing accounts is in our guide to setting up aliases in an hour. The point for now is that a manager user is better placed to adopt aliases than anyone, because the hard part is already solved.
Where a manager's built-in integration fits
Several password managers will now create the alias for you at the point of signup, and that is a good option rather than a rival one. Bitwarden's username generator can produce a "forwarded email alias" and, according to its help pages, works with SimpleLogin, Addy.io, Firefox Relay, Fastmail, Forward Email and DuckDuckGo: you paste in an API key from the alias service, and generating a username creates a fresh alias in that account. 1Password does the same for Fastmail's Masked Email, offering "Create Masked Email" in the email field of a signup form once the two accounts are connected. Proton Pass creates aliases through SimpleLogin, which Proton owns, and Apple's password tooling sits alongside Hide My Email, whose tradeoffs we cover in our notes on its limits.
If your manager integrates with the alias service you use, turn it on. It removes the last bit of friction, which is switching tabs to make the alias. If it does not, the copy-and-paste version costs a few seconds per signup and works with anything. What matters is that the address in the username field is unique, not the mechanism that put it there.
The honest limits
An alias does nothing for a weak password. If site A had your alias and "summer2019", and site A is breached, the attacker has your account at site A. The alias stops them going anywhere else with it, but that is all it does.
A strong password does nothing for a leaked address. The list of places your real address turns up will keep growing, and each one is a spam source, a phishing target, and a data point in somebody's profile of you. If your address has already leaked, a manager does not undo that; it only makes sure the passwords beside it are useless.
And both together still lose to a phished session or a compromised device. If you type your credentials into a lookalike page, or approve a login prompt you should not have, the attacker holds a live session and neither the alias nor the password strength matters. If your laptop is running someone else's software, they can read the manager as easily as you can. Multi-factor authentication and, where offered, passkeys are the answers there. The NCSC's consumer page now recommends passkeys as your primary login where available, and nothing in this post argues otherwise.
What aliases and a password manager do together is turn a data breach at some company you signed up with years ago into a non-event: a password that opens nothing else, an address that leads nowhere else, and one switch to flip. That is a narrower promise than "security", and it is the one worth making.