Passwordless sign-in for learners: fewer resets, better security

Someone who signs in to your LMS once a year for a compliance refresher is never going to remember their password. So they click “forgot password”, wait for an email, invent a new password they’ll forget again, or give up and log a ticket. Passwordless sign-in removes the password altogether. This guide explains how it works, where the security trade-offs really are, and when it’s worth adding SAML single sign-on on top.

Why passwords fail occasional learners

Passwords work best for systems people use every day. A training platform is often the opposite: people sign in when they’re enrolled, when a reminder arrives, or when a certificate is about to lapse.

That creates a predictable set of problems:

• Forgotten passwords. With months between sign-ins, many learners start with a reset, often on the day training is due.
• Reuse. People who can’t remember yet another password reuse one from somewhere else. If that other site is breached, the same email and password can be tried against your LMS.
• Workarounds. Strict password rules lead to passwords on sticky notes, or predictable variations like adding a number each time.
• Support load. Every lockout and reset is a ticket for your help desk or L&D team.

There’s also a quieter point. Most password systems let people reset their password by email, which means the inbox already controls the account. The password is the part people forget, not the part that protects them. Passwordless sign-in simply makes that explicit.

How passwordless sign-in works

Email one-time codes

1. The learner enters their email address.
2. The LMS generates a short random code and emails it to them.
3. The learner types the code in, and the LMS checks it.

A well-designed code works once, expires within minutes, and stops working after a few wrong tries. There’s nothing to remember, nothing reused from another site, and no password to leak.

Some systems email a sign-in link instead of a code. Codes are handy when someone reads email on their phone but is signing in on a work computer, because they can simply type the code across.

Google, Microsoft or LinkedIn accounts

With “sign in with” buttons, the LMS hands sign-in to the provider using standard protocols such as OAuth 2.0 and OpenID Connect. The provider checks who the person is, including any two-step verification on their account, and tells the LMS who they are and their verified email address. The LMS never sees their password.

This suits staff who already sign in to Microsoft 365 or Google Workspace every day: one click and they’re in.

The security trade-offs, honestly

Passwordless isn’t magic. It moves trust somewhere else, and you should know where.

A few specifics worth understanding:

• The email account matters most. Anyone who can read a learner’s email can sign in as that learner. Multi-factor authentication on work mailboxes does more for LMS security than any password rule.
• Expiry and limited tries stop guessing. A six-digit code has around a million possible values, so three tries gives a guesser only a few-in-a-million chance, and each code lives for minutes. Limits on how often codes can be requested slow things down further.
• Codes can still be phished. A fake sign-in page can ask for a code and use it straight away. Teach people to enter codes only on your LMS’s real address, and that nobody, support included, will ever ask them for one.
• Shared mailboxes weaken your records. If several people can read one inbox, any of them can sign in as its owner. Each learner needs their own address for training records to mean anything.
• Leavers need removing everywhere. A personal Google or LinkedIn account doesn’t disappear when someone leaves. Suspend or archive them in the LMS as part of offboarding, not only in your directory.
• Email delivery is part of the system. Codes that land in spam or arrive late cause failed sign-ins. Ask IT to let the LMS’s emails through your mail filters.

Plan for recovery before you need it

With passwordless sign-in, “forgot password” tickets largely disappear. The usual support question becomes “I didn’t get my code”, and the answer is almost always to check the spam folder, confirm the address, and request a new code.

Administrators need more thought. If you rely on single sign-on and your identity provider has an outage, or a setting is changed by mistake, you need a way in that doesn’t depend on whatever broke. Good practice:

• Keep at least two administrators, so one person losing access doesn’t lock out the organisation.
• Make sure administrators have a recovery path that doesn’t depend on your identity provider.
• Try that recovery path once, calmly, before you need it on a bad day.
• If you limit administrators to office IP ranges, check how remote administrators will get in.

When to add SAML single sign-on

Email codes and social sign-in suit most learners. SAML single sign-on is worth adding when:

• Your staff are already managed in Microsoft Entra ID, Okta or Google Workspace.
• You want your identity provider’s multi-factor and access policies to apply to training too.
• You want people to lose access as soon as they’re disabled in your directory.
• Security reviews or customer questionnaires ask for single sign-on.

It isn’t the whole answer if many learners sit outside your directory, such as contractors, volunteers, customers or other organisations’ staff. In that case, use SSO for your own staff and keep email codes for everyone else. We cover setup in more detail in single sign-on for your LMS.

How Acadenix does it

Acadenix has no passwords at all. People sign in in one of these ways:

• Email codes. People enter their email and receive a six-digit code. It works once, for five minutes, and stops working after three wrong tries. Ask for codes too often and you’re asked to wait.
• Google, Microsoft and LinkedIn. Each method is switched on or off in Settings → Authentication, and can be limited to particular verified email domains. Before a change is saved, you see how many people and sessions it affects.
• Your own sign-in apps. Organisations can use their own Google, Microsoft or LinkedIn app. With your own Microsoft app, only accounts in your tenant can use it.
• SAML single sign-on on Gold. Connect Microsoft Entra ID, Okta or Google Workspace. Learner accounts can be created at first sign-in, but only for addresses on your organisation’s email domains. The first time someone signs in through SAML, a code is emailed to confirm the link, once per person. Other methods you’ve switched on remain the fallback. See plans and pricing.

For administrators there are extra safeguards. Administrators can be limited to your IP ranges without affecting learners, and idle sessions sign out. If your usual sign-in stops working, an administrator can still get in with a recovery code sent to their email, and that path can’t be switched off. Suspending someone’s account stops them signing in straight away, and Email History shows which emails were sent or failed in the last 30 days, without keeping message contents or codes. There’s more detail on our security page.

Key takeaways

• For occasional learners, passwords create resets, reuse and tickets without adding much protection.
• Email codes and work-account sign-in remove the password; the inbox or provider account becomes the key, so protect it with multi-factor authentication.
• Single-use codes that expire quickly and allow few tries make guessing impractical, but people still need to know never to share one.
• Plan administrator recovery and offboarding before you switch methods on.
• Add SAML single sign-on when your staff live in a central identity provider, and keep email codes for everyone else.

If passwords are the biggest source of your training support tickets, see how passwordless sign-in works with your own people. Request an evaluation and set up the sign-in methods that suit your organisation.