ZealiD Blog

What SharePoint Cannot Do for Client-Facing Document Management

Written by Philip Hallenborg | May 29, 2026

Last updated: May 2026. Regulatory information current as of May 2026.

SharePoint was built for internal teams, not for clients. If your law firm uses it to share documents externally, you are relying on an identity model that was never designed for the people you actually need to reach. For managing partners, COOs, and compliance leads at mid-size law firms, this gap creates a security exposure that most firms have confirmed but few have addressed.

The question that exposes the gap

When a firm tells me they use SharePoint for client document sharing, I ask one follow-up question: how many of your external clients actually connect?

The room usually goes quiet. The honest answer, across every firm I have spoken with in the UK and the Nordics, is that most clients never complete the connection process. The invitations go out. The clients see an unfamiliar Microsoft login screen, a guest access flow they do not understand, or a prompt to install an authenticator app they have never used. They email the firm back and ask to just send the documents by email instead. The firm complies, because the alternative is losing the client's cooperation entirely.

This is not a configuration problem. It is an architecture problem. SharePoint's access control is built on Microsoft Entra ID (formerly Azure Active Directory), which assumes the person on the other end is an employee of an organisation with its own IT department, managed devices, and single sign-on. That works for internal collaboration. It fails at the exact point where law firms need it most: the client.

The high-net-worth individual who will never log into SharePoint

Consider the client profile that generates the most sensitive document exchange at a law firm: a high-net-worth individual in an estate matter, a property transaction, or a complex tax advisory engagement. This person is not going to create a Microsoft account. They are not going to navigate a guest access invitation. They will receive the link, encounter an unfamiliar login screen, lose the password they just created, and call the firm's reception asking someone to just email the documents.

That phone call is where the firm's entire security posture collapses. The compliance team spent months configuring SharePoint permissions. IT set up conditional access policies. None of it matters, because the client never entered the system in the first place. The documents end up in an email attachment, unencrypted, sitting in an inbox with no access control, no audit trail, and no way to revoke access after the matter closes.

The authenticator apps that SharePoint relies on for multi-factor authentication make this worse, not better. They verify that a device is present. They do not verify who is holding it. Under GDPR Article 32, controllers must implement technical measures that ensure a level of security appropriate to the risk. For law firms processing client identification documents, financial records, and privileged communications, "someone with access to this phone" is not an appropriate standard. ZealiD's analysis of onboarding data across professional services firms confirms that MFA drop-off rates for external clients exceed 60% in the first session.

Why Scandinavian firms never tried

Almost none of the professional services firms I have spoken with across Scandinavia use SharePoint for client-facing document exchange. Not because they tried and it failed. Because they already knew it would not work for their clients.

These firms use SharePoint internally, often extensively. But for the client layer, they use email, or ad hoc tools, or nothing structured at all. They understood instinctively what UK firms are now discovering through experience: SharePoint's identity model does not fit external clients who are individuals or small businesses without IT infrastructure.

The result is the same in both markets. Firms have strong internal document management and no purpose-built system for the client relationship. The gap between those two realities is where compliance risk accumulates.

The "everyone link" workaround and what it means for record-keeping

When SharePoint's external sharing proves too difficult for clients, staff find workarounds. The most common is generating OneDrive external links. In practice, this creates broad "everyone links" into the firm's environment, meaning anyone with the URL can access the shared content without authentication.

A UK firm with 180 staff described exactly this pattern in early 2026: because SharePoint limits external sharing in ways that clients cannot navigate, their staff regularly resort to OneDrive links that bypass the controls the firm believes are in place. The firm had confirmed this risk internally but had not yet addressed it. Another firm described their existing proprietary client portal, built on a basic CRM, as having lost its focus on providing clients with easy document access.

Under Regulation 40 of the Money Laundering, Terrorist Financing and Transfer of Funds Regulations 2017, firms must maintain adequate records of customer due diligence measures and supporting evidence for a period of five years. When documents arrive through uncontrolled sharing links, the firm cannot demonstrate a verifiable chain of custody for those records. The same gap affects firms that share documents over email — the compliance exposure is structurally identical.

SharePoint for internal work vs. client-facing document exchange

The core problem is not SharePoint's functionality — it is that the system was built for a different user. The table below shows where that assumption breaks down.

SharePoint capability comparison: internal vs. client-facing use
Capability SharePoint (internal) SharePoint (client-facing)
Identity verification Entra ID / SSO for employees Guest access or anonymous links with no regulated identity check
Client adoption Not applicable — staff use it because IT mandates it Most clients never complete the connection process
Multi-factor authentication Authenticator app tied to managed devices Authenticator app verifies device, not person
Access control Role-based, managed by IT Ad hoc links, often with "everyone" permissions
Audit trail Full internal logging Limited or absent for external link access
Access revocation Centralised via IT admin Manual, per-link, frequently forgotten
Compliance with GDPR Article 32 Supported when properly configured Gaps in confidentiality assurance for external users

The SRA's information and cyber security guidance explicitly highlights the risk of firms' growing dependence on IT systems without corresponding controls for external access. In 2024 and 2025, the SRA intervened in 47 practices citing IT security failures as a primary or contributing factor.

What happens when the audit finds this

Three scenarios that firms discover too late.

First, a regulator asks for evidence that client identity was verified before document access was granted. The firm produces SharePoint access logs showing a guest email invitation was accepted. This does not demonstrate who accepted it, whether the device was theirs, or whether the verification meets the standard required under Regulation 40 of the MLR 2017. The audit trail proves access happened. It cannot prove identity.

Second, a matter closes and the firm discovers that an OneDrive link shared eighteen months earlier is still active. The document it points to contains client due diligence information. Under GDPR Article 17, the firm has an obligation to erase personal data when it is no longer needed. A link that was never revoked is a data breach waiting to be reported.

Third, a client disputes a signed document. The firm's evidence is a timestamp and an email confirmation. A qualified electronic signature under eIDAS Article 25(2) carries the legal presumption of a handwritten signature. An email confirmation carries none.

What purpose-built looks like

After nine years of building identity infrastructure, the pattern is consistent. The systems that work for client-facing use start with identity, not documents. When identity is the foundation, access management, audit trails, signing, and compliance evidence follow as consequences of the architecture, not as features to configure separately.

The moment that changes how a managing partner thinks about this is not a feature demonstration. It is seeing internal staff and external clients managed side by side in the same workspace, with the same level of identity assurance, the same audit trail, and the same access controls. No separate guest access flow. No Microsoft account requirement. No authenticator app the client will never install.

Trust Circle was built on this principle. As a workspace from ZealiD, a Qualified Trust Service Provider on the EU Trusted List since 2020, every participant's identity is verified to a regulated standard before they access, share, or sign anything. The compliance evidence is not a report you run after the fact. It is the way the system works from the first interaction.

What to do next

If your firm uses SharePoint internally and email or ad hoc links externally, ask the same question: how many of your external clients actually connect to your current system? If the honest answer is "very few," the problem is not training, configuration, or change management. The system was never built for the people you need to reach.

Start by auditing your last twelve months of external sharing activity. Count the active OneDrive links still pointing at closed-matter documents. Count the guest access invitations that were sent but never completed. The number will tell you more about your actual compliance exposure than any configuration review.

Key takeaways

  • SharePoint's identity model is built for employees, not external clients. Most clients never complete the guest access flow.
  • When clients cannot connect, staff create "everyone links" that bypass the controls the firm believes are in place.
  • Under Regulation 40 of the MLR 2017, firms must maintain verifiable records of CDD measures for five years. Uncontrolled sharing links do not meet this standard.
  • MFA verifies device presence, not identity. Under GDPR Article 32, device-level verification is not sufficient for processing client identification documents and privileged communications.
  • The SRA intervened in 47 practices in 2024 and 2025 citing IT security failures. External access controls are in scope.
  • Purpose-built client workspaces start with regulated identity verification. Compliance evidence is a consequence of the architecture, not a configuration option.

References

General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, Articles 17 and 32 (Right to erasure; Security of processing). European Union, 2016. https://eur-lex.europa.eu/eli/reg/2016/679/oj

Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017, Regulation 40 (Record-keeping). UK Government. https://www.legislation.gov.uk/uksi/2017/692/regulation/40

Solicitors Regulation Authority. "Information and cyber security." Risk Outlook, updated 2025. https://www.sra.org.uk/sra/research-publications/risk-outlook-2020-21/information-and-cyber-security/