Client Portal Security: The Questions to Ask Before You Buy
Every vendor in this category says the same six things about security. Here is what to ask instead, and what a good answer sounds like.
Client portal security assessment usually goes badly for a predictable reason: the questions asked are the ones every vendor has prepared for. Encryption in transit and at rest, a compliance certification, and role-based access are on every page in this market, and a product can have all three and still leak an engagement to the wrong client. The interesting questions are about how authorisation is decided, what happens at the edges, and what the product does when something goes wrong.
What follows is organised as questions rather than features, because the shape of the answer tells you more than its content. A vendor who answers the enforcement question with a description of their user interface has told you where the check happens, and the answer is the wrong place.
Where is authorisation actually enforced?
This is the question that matters most and is asked least. If a client is not entitled to see a document, is that enforced at the point the data is read, or is it enforced by not rendering a link to it? A portal that hides things in the interface but serves them to anybody who requests the address directly is not access controlled, it is decorated.
A good answer describes enforcement in the data layer: the query that fetches a client's deliverables is constrained by their grant, so a record they are not entitled to is not returned rather than returned and hidden. A stronger answer adds that the same constraint applies to every route without exception, including file downloads, because the download path is where this is most often forgotten.
A useful follow-up: what does the product return when a client requests something that exists but is not theirs? The correct answer is the same response as for something that does not exist. Distinguishing the two tells an attacker which identifiers are real, which is a genuine disclosure on an engagement somebody is only partly admitted to.
How is a grant scoped, and how is it revoked?
- Can a client contact be scoped to part of an engagement rather than all of it, and does every read honour that scope, including documents, requests, meetings and messages?
- Is the grant checked on each request, or is it baked into a session at sign-in? The second means revocation does not take effect until the session expires, which can be hours after somebody left a job.
- Can a grant carry an expiry, so that access to a finished engagement lapses without anybody remembering to remove it?
- What happens to grants at closure? Access left open on completed engagements is one of the most common real exposures in this category and one of the least discussed.
How are downloads served?
File download is where portal security is usually weakest, because the file often lives in object storage and the easy implementation is a long-lived public address. Ask directly: is a download served through a signed link that expires, and is the client's entitlement re-checked at the moment of download rather than at the moment the link was created?
The failure this prevents is mundane and common. A client forwards an email containing a document link to somebody outside the engagement, entirely innocently. If the link is public and permanent, that document is now outside your control indefinitely and there is no record. If it is signed and short-lived, the forward fails and the recipient sees nothing.
What happens when two clients are adversaries?
Firms that act for multiple parties in the same market eventually act for two who are in dispute, bidding against each other, or on opposite sides of a transaction. At that point a permission model is not sufficient: what is required is a barrier that denies access even to somebody who holds a valid, correctly scoped, unexpired grant.
Ask whether the product supports exclusion as a distinct concept from permission, and whether the exclusion is enforced everywhere or only on the surfaces somebody remembered. The test is whether a barred party can see the engagement in a list, open it by its address, or reach anything that hangs off it. If the answer is that the engagement is filtered from lists but reachable by address, the barrier is cosmetic.
What is recorded, and can you get it out?
Every access to client material should be recorded: who, what, when, and from where. Ask whether that record is append-only, whether it covers downloads as well as views, and whether you can export it without asking the vendor. A firm facing a dispute or a regulatory question needs that record on its own terms and on its own timetable.
Ask also what happens to client data at the end of the relationship: whether deletion is genuine or a flag, whether backups are covered and on what schedule, and whether you can obtain a complete export in a usable format rather than a database dump. Data portability is a security property, because a firm that cannot leave cannot enforce anything.
The questions that reveal maturity
- Describe the last security incident you had and what changed afterwards. A vendor with no answer either has not been operating long or is not telling you.
- Who at your company can read our clients' documents, under what process, and is it logged?
- Is multi-factor authentication available to our client contacts, and can we require it?
- Where is the data stored, and can we constrain it to a jurisdiction?
- How do you handle a client contact who leaves the client organisation without anybody telling us?