Sign-in options, and what each one would take

Six-digit code by email

The patient types their email, we send a code, they type it in. No password exists anywhere in the system, so there is nothing to forget, nothing to reset, and nothing for support to unlock.

Try it: the demo · Cost: nothing beyond what we run today · Weak point: depends on an email arriving

Stay signed in for up to 30 days

The best sign-in is the one that never happens. Sessions now last 30 days, and a patient stays signed in as long as they visit at least every 3 days. Someone checking their plan weekly would enter a code roughly once a month rather than every visit.

Just changed: 21 Aug · Trade-off: shared devices, which is why Sign out is in the header of every page · Limit: the 3-day idle window is the maximum this plan allows

Land on the page you were trying to reach

If a patient clicks a link to their medications and is not signed in, they get the code and then land on that page, not a generic dashboard. This should be built into every reminder we send: renewals, results ready, scripts expiring.

Cost: nothing, it is a link convention · Action: add it to the comms templates so it becomes habit

One sign-in across every Primal Zone site

Because sign-in now runs on our own domain, any other Primal Zone property pointed at the same identity provider shares the session. A patient signs in once and is already signed in on the next site. Nothing to build per site, only to point each one at the same place.

Needs: a second property to point at it · Cost: configuration only

Remember me on this device

After a patient signs in once, their email is remembered on that device, so next time the field is already filled and they press one button. A "not you?" link clears it.

Effort: about an hour, inside the sign-in work already planned · Note: remembers the address only, never a credential

Catch people who are not patients yet

Someone presses Log in but has never registered. Instead of turning them away, we ask for their name and mobile, create the record, and let them straight in. Nobody hits a dead end.

Effort: about half a day · Care needed: the check must never reveal whether an address belongs to a patient

Face ID and fingerprint (passkeys)

The one everybody wants: open the portal, touch the sensor, you are in. No email, no code, nothing to intercept. It is supported and switched off, but we cannot have it without also bringing passwords back.

Passkeys live on the same connection as passwords, and Auth0 refuses to disable the password half: "authentication_methods.password.enabled false is not yet supported". Turning passkeys on would reintroduce the password prompt we deliberately removed, and patients would get different experiences depending on which one they happen to have.

What it needs: a plan or product change at Auth0, or accepting passwords as a fallback alongside · Recommendation: do not trade the clean code-only experience for it yet

Code by text message instead of email

Tempting, because email is our weakest link. But Australian sender-ID registration is lead time we do not control, every message costs money forever, and a text code is the weakest of all the options for security.

Better use: a fallback for patients who cannot receive email, not the default

Sign in with Google or Apple

Removed on purpose. It hands part of a health login to a third party, gives us no control over the policy behind it, and is not appropriate for a patient portal.