Passwordless login: sparing clients the password

Tuesday, 9:12 a.m. Three of the first four messages in a small architecture practice's shared inbox open with the same line: «I can't get into the portal, I've forgotten my password.» The office manager answers each one, triggers a reset by hand, and then two of them write back because the reset email landed in junk. Before ten o'clock, roughly forty minutes have gone into work that helped nobody look at an invoice. Later that week a client asks on the phone: «You already email me the invoice — why do I need a separate password for you?» The numbers are illustrative; the question is fair.

This article is as much about what passwordless login does not fix as what it does. The gap between switching a portal on and getting clients to use it is covered separately in driving real product adoption; here we zoom in on one link of the chain, the sign-in itself. In order: what a password actually breaks for the client, what happens behind the scenes when a magic link is clicked, which threat models this helps and which it does not, how link lifetime and single use trade off, what changes once the inbox becomes the only key, whether the sign-in screen leaks your client list, what the second visit feels like, what support needs when the link never arrives, and which numbers tell you it is working.

What does a password actually break for the client?

A password assumes an account relationship: that the other person uses your system regularly, keeps the credential somewhere, and can recover it alone. That holds for online banking. It does not hold for a client who gets one quote a month and four invoices a year. Your portal is not a new account in their life — it is a document window they open a handful of times.

The ironic part is that the reset flow already rests on email ownership. The system emails a link, treats whoever clicks it as legitimate, and lets them set a new password. The real proof of identity has been inbox access all along; the password is a second layer bolted on top, and most clients skip it through the reset flow every time. Passwordless login does not invent a trust model — it makes the existing one visible and drops the redundant step.

The cost shows up in support. A routine «can I have a copy of the invoice» and a «can't log in» land in the same inbox, but the second produces nothing; it is time spent removing an obstacle you put there. Any honest reading of turning satisfaction into revenue starts with what share of your inbox answers a real question, and access tickets quietly drag that share down.

What happens behind the scenes when a magic link is clicked?

To the client the flow is two screens: a box for their email address and a link in their inbox. Behind them sits a short chain of decisions. In Rocketly's Customer Portal, the Passwordless Login (Magic Link) feature records them like this: the emailed link is single use and valid for 15 minutes, and because no permanent password is ever created there is none to reset later.

• The client types their email address; the system tries to match it to a client record.
• On a match, a short-lived, single-use link is generated and sent only to that address.
• Clicking the link consumes it; the same link will not open a second session.
• Once inside, the client runs on a separate portal session — link lifetime and session lifetime are not the same thing.
• When the session ends the client requests a fresh link; there is no stored credential to lose.

The fourth point carries more weight than it looks. Under Secure Access, the portal session opens with its own 24-hour token that never crosses into normal API access. The key handed to the client does not open the door your team uses in the CRM. The real security contribution of passwordless access is less about the link and more about how small the room behind it is.

Which threat models does this help, and which does it not?

«Magic links are more secure» is not a statement you can evaluate, because security is not measured on one axis. The useful questions are narrower: which risk goes down, which stays put, which grows? With passwords the risk centres on a stored secret; without them it moves to the client's inbox. The two fail in different places, and which failure you prefer depends on how your clients actually work.

Risk	With password-based access	With a passwordless link
The same password reused elsewhere	An open exposure; a lasting secret exists	Removed; no reusable secret is held
Credential records being exposed	Directly affected	No password record to expose
The client's email account taken over	Already affected via the reset flow	Directly affected; email is the only key
Shared mailboxes (info@, accounts@)	Who knows the password becomes unclear	Anyone with inbox access can sign in
A device left unlocked	Depends on session length	Depends on session length; no difference

The first two rows are the clear win: with no lasting secret, the surface attached to it closes. Rows three and four show where the loss sits. The inbox was already the backstop for resets, so row three is not a full loss; row four is a genuine difference. If your client works from one shared mailbox, «who signed in» was never crisp under passwords either, but passwordless ties it entirely to that mailbox. The fix is not a different method — it is per-person addresses on the record and traceable sign-in events.

How long should a link live, and how many times should it work?

A short lifetime buys security and costs usability; a long one does the reverse. The balance depends on how quickly your clients open email, and that varies by trade. A bookkeeper at a desk opens the link in two minutes; a field engineer might not look at their phone until seven in the evening. Fifteen minutes is generous for the first and tight for the second — but the answer there is not a longer window, it is making a fresh request one tap away.

Single use is a separate argument. Consuming the link on first click makes forwarding it pointless, but it produces an awkward edge case: some corporate mail systems open inbound links ahead of the recipient for security scanning, so the link is spent before your client taps it. Without knowing that, «the link doesn't work» tickets are hard to close. The right reflex is not a dead-end «invalid link» page but a screen offering a new link on the spot.

Delivery timing matters too. A sign-in link is a message the client asked for seconds ago; delay is failure. Queued behind bulk marketing sends or held by quiet-hours rules, the flow breaks. Automation design has to separate what can wait from what cannot, and the piece on speed versus business hours draws that line. A sign-in link should still go out at three in the morning, because whoever asked for it is at the screen at three in the morning.

What changes when the inbox becomes the only key?

Passwordless login moves the centre of gravity of authentication onto your email infrastructure. The first consequence is technical: deliverability stops being a marketing metric and becomes an access question. If your sign-in email lands in junk, your client cannot reach the portal. Authenticating your sending domain and keeping transactional mail off the campaign channel become product functions.

The second is record hygiene. Whose address is on the client record? For business clients it is often the accounts department's shared mailbox, watched by five people, and whoever signs the quote may not be whoever downloads the invoice. On larger accounts this is accountability as much as security: who approved what, and who saw it when. The discipline behind growing your most valuable accounts already calls for a per-person contact map, and portal access sits far more comfortably on top of it.

The third is staff turnover. With passwords there was at least a credential to revoke; here there is nothing to hand over, but access continues as long as mailbox access does — the closing move happens on the client's side. What compensates is a bounded session and a deliberately narrow view: under Finalised Documents Only, draft quotes along with draft and cancelled invoices never reach the portal, so the worst a wrong reader sees is a document you formally sent anyway.

Does the sign-in screen leak your client list?

A detail that rarely gets discussed: the response on the sign-in form can leak information by itself. If it says «link sent» for a known address and «no such client» for an unknown one, an outsider can work out who your clients are without touching a single document.

The Non-Disclosing Sign-In behaviour closes exactly this: a sign-in request does not reveal whether the address is on file, and the response stays the same either way. If the address is registered a link goes out; if not, nothing does — but the screen reads identically. As user experience that is a real concession, since a client who mistyped will not find out immediately. The mitigation is honest copy: «if your address is on file, a link is on its way — check the address if nothing arrives in a few minutes.»

How sensitive that is depends on the trade. For a design studio the consequence is mild; in healthcare, legal or insurance the client list is itself protected data. A list of policyholders approaching renewal is directly valuable to a competitor, which is why in a process built on not missing renewals the sign-in screen's behaviour is part of the process, not a stray technical detail.

What does the second visit feel like?

The most overlooked moment in a passwordless setup is the second visit. The first sign-in arrives inside an email: a quote goes out, the client taps, the portal opens. The second visit the client starts alone — remembering the address, typing their email, returning to the inbox. That is not effortless under passwords either, but expectations differ: the user knows a password is coming. Here you have to say up front that the «check your email» step repeats every time, or it lands as a surprise.

Part of setting that expectation is the portal looking like yours. With a Branded Portal, your organisation's logo and name sit in the header, so the client reaches their own documents without the sense of being pushed toward an unfamiliar tool. That is not decoration: typing your email into a screen you do not recognise is exactly the hesitation a phishing-aware user should feel.

The other half is what waits inside. After signing in, a client should meet their own open quote, outstanding invoice and next appointment, not a generic menu. Discussions of moving from segment to individual usually stay on the marketing side, but the concrete payoff shows up here, where personalisation is not an inference but the record itself.

What does support need when the link never arrives?

Every passwordless setup eventually meets this ticket: the client requests a link and nothing turns up. The cause is almost always one of three — the address on the record is wrong, the message went to junk, or a corporate filter blocked it. Support needs a fixed order for telling them apart, or every case becomes guesswork from scratch.

In practice: confirm the address out loud with the client, check the send log, then deliver a fresh link through an alternative channel. Having that last step ready saves real time; many teams reach for instant messaging, and a wa.me link with a pre-filled message makes that contact repeatable. The choice of channel is also a security decision: sending a link somewhere else assumes that somewhere else is verified too.

There is an emotional side too. Being locked out is a failure the client experiences live, and handled well it strengthens the relationship rather than denting it. Everything said about turning a bad experience into loyalty applies literally: a reply that admits the problem and offers a working alternative within minutes is more memorable than a sign-in that never went wrong. Logging those cases matters too — the Activity Log writes views, messages, revision requests and payments one by one, so you can read back what happened once access was restored.

Which numbers tell you it is working?

Passwordless login is a measurable funnel, and four numbers carry it. First, request-to-entry: how many links were requested and how many produced a sign-in. A low ratio points to delivery trouble or to a lifetime out of step with your clients' rhythm. Second, repeat-request rate: how many clients asked for more than one link for the same session. High means the first never arrived or was consumed somewhere.

Third, the share of your support inbox taken by access messages. Migrating from a password system you expect that share to ease; if it does not, the obstacle moved rather than disappeared. Fourth, the return-visit rate: how many clients come back on their own after the first invitation. That is where the portal proves itself — the first visit is a success of your email, the second of the portal.

These numbers measure behaviour, not intent. To learn why, you have to ask, and asking well is its own skill. A portal survey written without knowing the difference between a question that measures and one that does not produces a chart where everyone says «fine» and nothing changes.

Clients who have not signed in for a long stretch are a list of their own: in systematic win-back work that list is one of the clearest signals you hold for restarting a conversation.

To test the flow end to end with your own client record, open a free account and walk through the sign-in step yourself.

FAQ

Is passwordless login more secure than a password?

There is no single answer; it depends which risk you mean. Against reused passwords and exposed credential records it is clearly better, because no stored secret remains. In exchange it makes the client's inbox the only key, which is a weakness where shared company mailboxes are the norm. The right call comes from looking at which mailboxes your clients work from and how sensitive the documents in the portal are.

Isn't a 15-minute link too tight for clients?

For desk-based clients it is usually more than enough. The strain appears with people working on site or checking messages in bursts. The fix is not a longer window but making a fresh request a single tap, and saying on screen that links expire so an expired one feels expected rather than broken.

What if several people share one email address?

Where possible, hold per-person addresses on the client record. Where a shared mailbox is unavoidable, keep the portal's visible scope deliberately narrow — which is why draft and cancelled documents never reaching it matters. For steps that need approval, the signature record separately captures who signed and when.

How long does a client stay signed in?

Session length is independent of link lifetime. In Rocketly the portal session runs on its own 24-hour token, and when it expires the client requests a new link. The split is deliberate: the link is short-lived because it sits in an inbox, while the session runs longer because it sits in a browser and makes coming back the same day easy.