edit: this has been lightly updated since its first posting in 2024 to reflect which product this now relates to.

It was pretty wild to launch a new product, even in 2024, that only supported passkeys for authentication. That is what we set out to achieve with PassGuard.

People asked us why we're doing that, and my answer was always the same: "We believe passkeys are the future of authentication - more secure, more convenient, and dare I say it - easier - to use than passwords”. By going all-in on passkeys from day one, we can deliver the best possible user experience and push the envelope a little on what a ‘better internet’ can actually look like.

All the same, it's a bold move for a startup like ours to make. A lot of eyebrows get raised, including from potential investors and customers who wonder if we're limiting our addressable market. Fortunately, we're going to get a lot of chances to explain our reasoning, because we've spent the past months building an alpha product that we believe showcases the full potential of passkeys. But I can give you a preview of our thinking right now.

Why we believe in passkeys

Some of you have heard of our founding team's background in security and building software for medium to large enterprise. At first glance, a SaaS product for SMBs couldn't be more different from our prior work in these areas, but it's also a continuation of that story in an important way. When we set out last year to build the best possible way that an SMB can manage its user access, a lot of people did not think it was possible to achieve better than SSO/SAML security if also combining with a seamless UX for non-technical, and certainly non-security educated users.

We did not dwell on whether it was possible or impossible, but we were certain that even under the best circumstances, it would be very hard. And the part that seemed hardest was how we could get users to adopt best in class security, above what (for example) security consulting firms would be highly paid to orchestrate (and include obscenely high on-going costs to SSO providers) whilst also not compromising on ease of use.

The fundamental problem in security - you might say the fundamental problem in product development nowadays at all - is that security controls have to handle many situations that the user has never thought of or will never anticipate. But, the user must still jump through the hoops of these controls, usually set up by developers / product managers, in anticipation of these scenarios. The proliferation of types of ‘multi factor authentication’ (MFA) is the best example of this.

However, this limits the value of common sense security practice, because if you had the foresight to do something that enhances security (like use unique, fantastically hard passwords 100% of the time), then you often also had the foresight to avoid the risky situation entirely. However, we have still seen countless examples of companies who believe they do understand best-practice / common practice security, either willfully (or unwittingly) committing some of the most easy to exploit security foibles, like sharing their own passwords in plain sight over email or Slack.

This isn't unique to our domain: many kinds of software have the problem of thinking through security and trying not to make the user experience completely suck. But our emerging domain means we have to over-index on all of the layers and patches of solutions that have been fed in through the years, and what would we do if we ‘started again today’.

What's especially hard about these risk scenarios is that they're non-deterministic - you can easily have a catastrophic security breach that's dependent on some hard-to-predict set of circumstances. Even if your security controls stop it once, they may fail to stop it the second time, purely down to human behaviour (humans make mistakes, get tired, etc) And here we were, trying to make a platform that would could deliver the most secure form of access management, and try to make this usable to any employee (or contractor), without security or IT knowledge required. How were we going to do that?

So we have taken a highly-opinionated approach with Mailpass which is what we call ‘only one way to use Mailpass’. It’s security on autopilot, which is especially helpful for teams that do not have anyone who was actually employed as their full time role to oversee security. Which is about 99% of SMBs. This is especially helpful when virtually every service / website is still suggesting - nay - enforcing, backwards policies like counter-secure password creation rules.

For example, “P@ris1234” which would ‘pass’ most password strength checkers, is far less secure than “red-badger-paris” which would currently fail most password strength advice from websites, yet is in reality far harder to ‘hack’ and yet far easier for a human to remember in their head. This is the tip of the iceberg for how users are lulled into thinking the platform they are using is somehow helping them be more secure.

Whilst this post could start to go through all of the features that achieve this ‘one way to use Mailpass’ security posture, we are focussing here on the first step of the platform for every user - registering and logging in. And for that, we use exclusively passkeys.

Passkeys summarised

Passkeys offer significant advantages over traditional authorization methods that normally utilise an email and password:

Phishing resistance: passkeys are tied to specific websites, making them useless if stolen in a phishing attack. This protects users even if they're tricked into revealing their credentials.
Elimination of weak passwords: With passkeys, users no longer have to remember complex passwords or reuse them across sites. The cryptographic keys are securely generated and managed by the device (and never actually stored by Mailpass).
Seamless multi-device experience: passkeys can sync securely across a user's devices via end-to-end encrypted cloud backup. Users can easily authenticate on any of their devices without manual setup on each one. Mailpass also has a secondary feature for multi-device without the need for cloud backup, should users wish to stay agnostic from a third-party like Apple or Google (they already own all of your data, do you want them to own all your security keys, too?)
Biometric authentication: passkeys integrate with biometrics like Face ID and Touch ID, enabling quick and secure authentication with just a glance or touch, no typing required. However, a misconception is that passkeys can only use biometrics. You can also use non-biometric methods specific to your device, like your screen unlock pattern or pin-code, for example.

When combined with the fact we never ask for a ‘backup email’ or an email address at all for that matter, the probability for an unauthorised person to make it into your Mailpass account is about as close to zero as any other form of ultra-secure authentication (or a combination) can provide today.

With passkeys, ‘multi-factor’ authentication (often just called ‘MFA’ or ‘2FA’) is also eliminated, as by design, a passkey has the double elements that things like ‘one-time’ codes were invented for to place alongside vulnerable passwords … to make them less vulnerable. You can hopefully see why we thought in 2024, removing passwords altogether was a step that felt necessary to move things forward.

So if there is to be one method that protects your access to tens, if not hundreds of other services, should that method not be the most modern and secure way available today? And one that offers the least avenues for a non-technical/security expert to make mistakes as they are signing up. We thought so, and that’s why Mailpass only uses passkeys.

Blog

Latest

Mailpass Investor Update June 2025

Powered by randomness

Why we went all-in on passkeys with PassGuard