A legal client portal should grant access by matter, document, and action. Membership of a law firm or client organisation is too broad.

One client can have several matters with different legal teams and external advisers. An account-level permission can accidentally join those separate groups.

This guide gives legal software builders a matter-access model, a sharing workflow, and proposed failure tests. It does not determine professional obligations.

A disclosed law-firm attack involved shared files

Olinsky's counsel reported unauthorised system access beginning on 17 December 2024. The firm discovered the attack on 28 January 2025.

The notification describes phishing, compromised shared-drive files, and a ransom demand that the firm did not pay. It gives no demand amount. Read counsel's March 2025 notification.

The letter is a primary incident document hosted by a third party. It does not describe a failure in a client portal.

Use it to introduce the risks of sensitive shared documents. The portal design below is a proposed control model, not a reconstruction of that incident.

Separate firm membership from matter membership

Consider a hypothetical firm with two client matters. The same finance contact works for both clients, but the legal teams differ.

That person should receive access only through an approved relationship to each matter. Knowing their employer does not settle the decision.

Resource	Required relationship	Example action
Matter overview	Active matter membership	View approved case status
Released client document	Matter membership and document permission	Read or download
Internal legal note	Approved internal team membership	Read internal work
External review package	Named adviser and assigned package	Comment on selected files
Billing record	Appropriate finance permission	View approved invoice
Matter membership settings	Restricted administrator authority	Add or remove a participant

Define which documents belong in each group. Avoid a rule that exposes every file after a client receives a matter invitation.

Describe exceptions explicitly. The system should not infer authority from a familiar email domain or a person's job title.

Enforce policy through every document route

Authorisation must cover the browser, API, previews, search, and exports. A document can escape through a secondary route even when the main screen works.

The following diagram describes one proposed request path:

Authenticated person
        |
        v
Current firm and matter membership
        |
        v
Document classification and permitted action
        |
        v
Any required sharing restriction
        |
        v
Controlled response and access record

Resolve membership on the server. Treat a matter identifier from the browser as a requested resource, not proof of permission.

OWASP's authorization guidance recommends default denial and checks for each request.

Apply the same decision to a file stored outside your application database. A storage URL must not become a permanent substitute for authorisation.

An external adviser may need three documents for one review. Give them that package rather than general client-organisation access.

Record the recipient, purpose, documents, permitted actions, and expiry. Make the recipient identity visible before the sender confirms sharing.

Use explicit invitation acceptance when recipient identity matters. Possession of a forwarded link should not silently establish a new matter membership.

If you allow anonymous links, identify that mode clearly. Explain its limits to the person creating the link.

For signed download links, document expiry and revocation behaviour. Disabling a portal account may not invalidate an already issued storage link.

Downloaded copies create another boundary. Your portal cannot guarantee removal of a copy that a recipient already holds.

These trade-offs belong in the product design and client agreement. Do not hide them behind a generic label such as secure sharing.

Treat departures and recovery as access changes

Removing a lawyer from a matter should affect future document requests. Include cached permissions, active sessions, export jobs, and sharing links.

Firm departure may require wider removal. Keep that event distinct from reassignment of one matter.

Use individual staff identities so the audit record can identify an actor. Shared credentials make investigation and removal harder.

Account recovery must not create new matter membership. After recovery, apply the account's current approved relationships.

For disputed ownership or client representatives, route the decision through an authorised process. An email-address change alone should not transfer document authority.

The admin-tool access guide covers support and ownership workflows that can affect these boundaries.

Test the cases that should be denied

Create synthetic matters and documents. Run these proposed checks before inviting real clients.

Test	Expected result
A client requests another matter's document	The server denies access
A client guesses an internal-note identifier	No internal content is returned
A removed adviser follows an old portal link	Current membership is required
A finance user requests an unrelated legal file	Finance access does not grant document access
An invitation is forwarded to another account	The original recipient restriction is enforced
A search spans several matters	Results include only permitted documents
An export runs after membership removal	Execution and retrieval follow the documented access policy

Record the actor, matter, document, action, and decision. Avoid copying privileged document text into general logs.

Assign a retention owner for application audit records. Identity-provider sign-in events cannot explain every document action.

Download the legal portal review sheet to record policy decisions and evidence.

Plan your legal portal identity with NamoID

NamoID Customer Identity can provide hosted sign-in, passkeys, TOTP MFA, and identity-session revocation for your portal.

Your application still owns matter membership, document permissions, sharing, and application sessions. NamoID does not determine legal privilege or professional compliance.

Our engineers can help you review account invitations, recovery, and the integration boundary before you launch.

Message the NamoID team in Slack for an early response. Share your stack and a sanitised matter-access model.

Keep client names, matter details, credentials, and incident evidence out of the community channel.