Passwordless by design: why the client portal has no password to forget

It is nine in the evening, the VAT deadline is tomorrow, and the client’s bookkeeper is trying to upload the last two documents. She created a login three months ago and has not touched it since. The password is not in her manager, not on the sticky note, not the one she assumes it is. She clicks “forgot password,” the reset email does not arrive, and she does the rational thing: she attaches the files to a reply and sends them to your inbox. The Portal you set up so carefully has just lost to email, at the one moment it mattered.

This is the ordinary failure of client portals, and it is worth being honest about. Portals do not usually fail because clients dislike them. They fail because of the password.

Passwords are friction for people who log in twice a year

A password is a reasonable ask for someone who uses a system every day. It is an unreasonable ask for the person a firm most needs to reach: the Client User who logs in a handful of times a year, under time pressure, often on a phone.

That user has no muscle memory for your portal. By their second visit, the password is gone. The reset flow — which is really a second, worse login — becomes the thing standing between them and the upload, and every extra step is another reason to give up and reply to your email instead. Once they do that, the whole point of structured collection has leaked away: the file is back in an inbox, off its Request Item, with no status and no trail.

So the friction is not a minor UX complaint. It is the mechanism by which portals quietly fail and firms drift back to the chase. If you want the fuller picture of what makes a client portal actually get used, we wrote about designing a portal clients will actually use; the password is the single biggest lever in it.

Magic links: nothing to remember, nothing to reset

Clivanta’s Portal is passwordless by default. A Client User enters their email and receives a one-time, time-limited magic link. Clicking it signs them in. There is no password to create at onboarding, none to forget three months later, and none to reset at nine in the evening.

The mechanics are deliberately plain:

• Single-use. Each link authenticates once and is then spent. A forwarded or reused link does not grant a second session.
• Short-lived. Links expire on a tight window — on the order of thirty minutes — so an old email sitting in an inbox is not a standing key to the account.
• Rate-limited. Re-requests are throttled, so the sign-in path cannot be hammered.

For the client, the entire login is: open email, tap link, upload. For an occasional user on a phone, that is the difference between finishing the task and abandoning it.

There is a second door for clients who want one. A Client User who logs in often, or simply prefers a direct login, can set an optional password afterwards. Passwordless is the default because it fits the common case; the option is there for the exception. Neither changes anything on the firm’s side of the workflow.

Passwordless is not the same as careless

It is fair to ask whether removing the password removes security. It does not, and it is worth walking through why rather than asserting it.

A magic link is a possession-based, single-use credential delivered to an address you already treat as the client’s identity. Because it is one-time and expiring, it is not a secret the client stores badly on a sticky note or reuses across ten other sites — which is where a great deal of real-world password risk actually lives. The link cannot be guessed, it cannot be reused, and it goes stale quickly.

Just as important, access is not invisible. Sign-in through the Portal is part of the same audited history that runs through the rest of Clivanta. The immutable activity log records access alongside every other meaningful action on a Request Item — the ask, the submission, the review decision, the acceptance to Evidence. So “who accessed this, and when” is a stored fact, not a guess reconstructed from mail-server logs after the fact. For a firm that has to keep a defensible record, that continuity matters as much as the login method. You can read the fuller security posture if you need the detail for a due-diligence conversation.

The honest summary is this: passwordless trades a memorised secret, which occasional users manage badly, for a possession-based one-time credential, which the system manages well. That is a better fit for the actual threat model of an occasional client, not a looser one.

The point is that the client shows up

Every design choice in a collection tool eventually answers to one question: did the client complete the task, in the system, so the record is whole? A password is a small thing that quietly answers “no” — not through any dramatic failure, just through the slow attrition of forgotten logins and unarrived reset emails, until the client is back in your inbox and you are back to sorting attachments by hand.

Taking the password away removes the most common reason a client bounces off the Portal at the worst possible moment. The upload lands on the right Request Item. The status updates. The trail stays intact. And your team is not fielding a panicked “I can’t get in” the night before a filing. The product overview shows where this sits in the wider request-and-response loop.

The best password is the one your client never has to think about.