A credential per device, scoped to your mailbox and nothing else, revocable one at a time without changing anything you use. What app passwords are, the two things ours deliberately cannot do, and why we do not just require a browser everywhere.
Everyone has done this. You add your work email to your phone, and the phone asks for your password, so you type the password. The real one. The one that also opens your files, your chat, your billing settings and the admin panel where you can delete a colleague.
Now that password is stored on a device that lives in your pocket, gets left in taxis, and runs software you did not audit. And it is the same password on your laptop's mail app, your tablet, and the old machine in the corner that still syncs contacts for some reason. If any one of those goes missing, the only lever you have is to change the password everywhere and reconfigure every device you own.
App passwords are the fix, and they are not a new idea. They are the standard answer to a real structural problem, and every serious mail provider offers some version. Here is ours, and why it is shaped the way it is.
It is a long, random credential that we generate, tied to one mailbox, that you give to one program instead of your real password. Your mail client, your phone, your calendar app, anything that connects with a username and a password rather than by opening a browser.
You create one from your account page in about ten seconds. Give it a label so you will recognise it later, something like "iPhone" or "Thunderbird at home". We show you the secret exactly once, at that moment, and then never again. After that the list shows only your label and when you made it.
Showing it once is not us being precious. A credential we could show you again is a credential we are storing in a form we could read, and the entire point is that we cannot. If you lose it, you do not recover it. You revoke it and make another, which takes ten seconds.
| Your account password | An app password | |
|---|---|---|
| Opens | Every product in the workspace | One mailbox |
| How many you have | One | One per device, as many as you like |
| If a device is lost | Change it everywhere, reconfigure everything | Revoke that one, nothing else changes |
| Where it is typed | A browser sign-in page | Into the program that needs it |
| Can be shown again | You set it, so you know it | No, shown once at creation |
This is where the design gets interesting, and it is the part worth understanding.
An app password only opens your mailbox. It is not a workspace credential. It will not sign anyone into the control plane, your Drive, your chat, or your wiki. Those all sit behind the single sign-on front door, which app passwords have nothing to do with. So the credential sitting on your phone is scoped to the one thing the phone actually needs.
That containment is the whole argument. A stolen laptop is a mail problem, not a company problem.
It is one credential among many, and you can kill any one of them. Each device gets its own. Lose the phone, revoke the phone, and everything else keeps working, uninterrupted, with no reconfiguration and no message to your colleagues explaining that you have changed the shared password again. Your real password never changes, because it was never on the device in the first place.
Compare that with the alternative: one password everywhere means the only response to any incident is to change it everywhere and spend an evening re-entering it on six devices, which is exactly why people do not do it.
Every member can create and revoke their own, without an admin, without a support ticket. There is nothing an admin needs to approve and nothing we need to do at our end.
That matters more than it sounds. Security features that require a request to IT get used once, during setup, by the person who is already careful. Security features you can use yourself in ten seconds get used the moment somebody loses a phone on a Saturday, which is the moment they are for.
Every creation and every revocation is written to your workspace audit trail, so there is a record without there being a gatekeeper.
If a program asks you to type a password into its own screen, give it an app password. That covers Apple Mail, Thunderbird, the mail and calendar apps on phones, and anything syncing contacts or calendars over the standard protocols.
If a program opens a browser window and asks you to sign in there, do that instead and do not create anything. That is our normal login doing its job.
Most people end up with two or three, one per device, made once and forgotten. The right time to revisit the list is when you replace a device, or when somebody leaves. Old labels sitting in the list are a small, quiet mess worth clearing.
Because we would be lying about how people use email. A standards-based mail service means real mail clients connect to it, and a large fraction of the clients installed in the world today authenticate with a username and a password, full stop. Refusing to support that would mean the automatic setup that makes migrations painless ends at a wall for anyone not using our webmail.
The honest engineering answer is not to pretend those clients do not exist. It is to make sure the credential they hold is narrow, disposable, and yours to kill.
App passwords are on every plan, with no limit, under Account once your mailbox is active.