Glossary
Passwordless authentication
Removing the shared secret the user has to remember, and attackers have to steal.
Definition
Passwordless authentication verifies a user's identity without a password they choose and remember. Instead it relies on possession of a registered device or key, control of an email account or phone number, or a biometric check on hardware the user already holds. Removing the password removes the credential most commonly reused, phished, guessed and leaked in breaches.
- Standard behind passkeys
- FIDO2 / WebAuthn
- Common methods
- Passkeys, magic links, email codes
- Not the same as
- MFA or SSO
Why passwords are the weak link
Passwords fail because of how people use them, not because the cryptography is broken. They are reused across sites, so one breach compromises many accounts. They are typed into convincing fake pages. They are stored by services that later leak them. Every mitigation invented for these problems, from complexity rules to rotation policies to security questions, pushed users towards worse habits.
Passwordless methods change the shape of the attack rather than hardening the secret. A passkey cannot be phished onto a lookalike domain because the browser binds it to the origin. An emailed code cannot be reused elsewhere because it exists for one login and expires.
The main methods, with their honest weaknesses
Passkeys (FIDO2 / WebAuthn)
A key pair stored on the device or in a platform keychain, unlocked by biometrics or a device PIN. The strongest widely available option, and phishing-resistant by design. The recovery story when a device is lost is still where most deployments struggle.
Magic links
A one-time sign-in link emailed to the user. Simple to build; inherits the security of the mailbox, and links are frequently mangled or pre-fetched by corporate email scanners.
Emailed or texted codes
A short one-time code entered into the app. Works everywhere with no device registration; SMS delivery is vulnerable to SIM-swap attacks, which is why email is often preferred.
Authenticator app codes
Time-based codes generated on a device. Common as a second factor rather than a sole one, and still phishable in real time by a proxy.
Commonly confused with
| Term | What it means | The difference |
|---|---|---|
| Multi-factor authentication | Requiring two or more distinct factors | MFA adds factors alongside a password. Passwordless replaces the password rather than supplementing it. |
| Single sign-on (SSO) | One identity provider authenticating many applications | About where authentication happens, not how. SSO can itself be password-based or passwordless. |
| Two-factor authentication | A specific case of MFA with exactly two factors | Usually password plus code. Still a password system. |
| Social login | Signing in through Google, GitHub or similar | A form of federated identity. Whether it is passwordless depends on how that provider authenticates you. |
How Polaris does it
Polaris uses emailed one-time codes and has no password path at all. A user enters an email address, receives a code, and signs in. There is nothing to reset, nothing to reuse elsewhere and no password database to breach.
The trade-off is stated rather than hidden: access to the mailbox is access to the account, so the security of a Polaris workspace rests on the security of its members' email. Teams already running strong protection on their email domain inherit it directly.
Related terms
All-in-one workspace
One data model behind documents, tasks and conversation, instead of three products and a pile of integrations.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Tool sprawl
The expensive part is not the licences. It is that nothing is authoritative any more.
Every tool a Polaris worker can be given
One catalog, one credential per tool per organisation, authorized by an owner and used by every worker who carries it.
How an AI worker gets tool access
The interesting part of tool access is not the list. It is where the credential lives and who can read it.
The vocabulary of agentic work
Definitions written to be quoted: where the term came from, how practitioners use it, and what it is not.
Questions people ask
+Is passwordless authentication more secure than a password plus MFA?
Passkeys are, because they are bound to the origin and cannot be handed to a lookalike site. Email codes and magic links are roughly comparable to password-plus-code systems: they remove reuse and leaked-database risk while making the mailbox the single point of compromise.
+What happens if someone loses access to their email?
In an email-code system, that is the recovery problem, and it is why account recovery deserves as much design attention as sign-in. Most products fall back to an administrator re-inviting the user, which places the trust in the workspace owner rather than in a security question.
+Why do products drop passwords entirely rather than offering both?
Keeping a password path preserves every weakness it was meant to remove, since attackers simply use the weaker route. Removing it also removes the password reset flow, the storage of hashes, and an entire class of support requests.
Related
All-in-one workspace
One data model behind documents, tasks and conversation, instead of three products and a pile of integrations.
Agent runtime
Not the model, not the framework: the thing that actually runs the job.
Tool sprawl
The expensive part is not the licences. It is that nothing is authoritative any more.
Per-seat pricing
The bill tracks headcount, which is only a proxy for value received.
Every tool a Polaris worker can be given
One catalog, one credential per tool per organisation, authorized by an owner and used by every worker who carries it.
How an AI worker gets tool access
The interesting part of tool access is not the list. It is where the credential lives and who can read it.