Best Cloudflare One configuration for a 100-user law firm in 2026

1. I'm the technical lead for a 65-person financial advisory firm that went fully ZTNA two years ago; our prod stack is Cloudflare One with Entra ID, protecting a hybrid environment of on-prem legacy portfolio tools and cloud-based CRM and compliance systems, so I've lived this migration.

2. Core comparison for a 100-user law firm:
- **Data Loss Prevention (DLP) granularity and cost:** The Cloudflare One DLP engine is effective for predefined patterns (SSN, credit card) and can be tuned for custom client matter numbers, but intensive fingerprinting of entire document repositories for privilege detection will push you into a higher subscription tier. Expect an effective all-in cost of $12-$18/user/month once you add the necessary CASB components and DLP seat licenses for high-sensitivity users.
- **Legacy app tunnel performance for on-prem document management:** The pure TCP tunnel (formerly Warp Tunnel) for hosting your on-prem apps introduces about 8-12ms of additional latency versus a direct VPN connection in our tests, which is fine for database-driven apps. However, throughput for large file transfers (like pulling multi-GB case files) will be bottlenecked by your egress gateway's upload speed, not Cloudflare's network. We had to upgrade our on-prem link from 100 Mbps to 500 Mbps symmetric.
- **Access policy complexity and audit readiness:** The policy builder using Access Groups is powerful but can become unmanageable past ~50 rules. For a law firm, you must document every "Allow" rule for compliance audits. The logging and reporting API is comprehensive, but building a dashboard for state bar audits requires exporting logs to a SIEM (we use Splunk Cloud), adding about $5k/year in additional log storage and processing cost.
- **User experience for low-friction partner billing:** The Client VPN provisioned via WARP client for managed devices works transparently. For unmanaged partner devices requiring client-less access, the Browser Access session lifetime is critical. The default 12-hour session is too long for high-security access; we set it to 4 hours, which generated a 30% increase in helpdesk tickets for re-authentication from external counsel until we implemented longer-lived, certificate-based authentication for specific partner subnets.

3. My pick is your proposed architecture, but with a phased rollout starting with the cloud apps and identity integration, because the regulatory overhead for on-prem systems is significantly higher. To make a clean call, tell us the average file size pulled from your on-prem document management system daily and what your current helpdesk ticket volume for access issues is.

Entra ID is fine but that's just the start. If they're coming from on-prem AD, the sync and conditional access policy mapping is where projects like this get stuck for months. Their legacy apps will need service accounts that won't exist in Entra ID initially. That's your first gap.

Spot on about using Entra ID as the core. That's exactly where we started for a 50-person shop last year. One caveat from our rollout: don't let the conditional access policies become a monster. For that size firm, start with just three or four core policies (like requiring a compliant device for the document management system) instead of tying every app to a different set of rules. It keeps the initial user experience smooth, especially for those partners allergic to friction.

You'll also want to plan the Entra Connect sync in phases. We synced user objects first to get everyone in, but left service accounts on-prem until we could properly map them to managed identities. It prevented those legacy app breakages user36 mentioned.

Three or four policies sounds nice in theory. It'll work for about a week until a partner demands an exception for their favorite cloud storage app that the compliance officer hasn't approved. Then the monster is born anyway.

Phasing the sync is the only sane approach. But mapping service accounts to managed identities is where the real billable hours hide. The vendor docs make it sound like a few clicks. It's not.

That foundation with Entra ID is the only way to go, absolutely. But I'd gently push back on just using it as the static identity source. Where you'll get immense value is turning it into the dynamic policy engine.

The magic sauce for that environment will be feeding device compliance status from Intune (or whatever MDM they use) directly into your Cloudflare Access policies. So a partner logging in from their personal iPad gets a totally different session than someone on a hardened, managed laptop, even with the same Entra ID credentials. This lets you meet the "no friction to billing" demand, but only for low-risk apps, while automatically enforcing full tunnel Gateway connections for the sensitive document systems.

Also, for the love of all that is holy, enable continuous conditional access evaluation between Entra ID and Cloudflare One. If a user's risk score changes in Entra ID mid-session, you can have Cloudflare tear down that session immediately. For client privilege, that real-time re-evaluation is a game changer versus a once-a-day policy sync.

Yes, starting with a few core policies is the only way to keep your sanity. We did something similar, but we found you really have to bake in the exception process from day one.

When a partner inevitably requests that special access, we had a simple rule: any new policy exception had to replace an existing one. It forced the conversation about what risk they were willing to swap out, and it kept the policy count from ballooning.

Phasing the sync was crucial for us too, but I'd add a watch-out on the service accounts: test their mapped managed identities *before* you cut over the sync for the related app. We had a few that needed extra API permissions in Entra, which wasn't obvious until everything broke on a Friday afternoon 😅

Entra ID makes sense as the core IdP. But for a law firm, you need to check the licensing costs for those advanced DLP features against the actual risk. What happens if a partner's old laptop falls out of compliance? Does the session get killed immediately or just flagged? That's a contract detail, not just a config one.

Entra ID as the sole identity source is fine for a start. The real problem is you haven't said what you'll do about service principals for those legacy apps. You can't just plug Entra ID in and expect the on-prem service accounts to work. That's how you create a gap from day one.

Totally agree, that gap is where projects stall. We handled it by creating a pre-migration inventory of every service account and its dependencies, then ran them through a pilot group in Entra ID as managed identities *months* before the main user sync. The "few clicks" in the vendor docs never account for the app-specific permissions that need to be recreated.

One thing we learned the hard way: some of those old service accounts were tied to on-prem file paths for logging or config. When they become cloud principals, those paths break. You need a plan for rewriting those paths or moving the resources they point to, which can become its own mini-project.

That inventory step is the only thing that kept a healthcare project I saw last year from total collapse. They found a service account that hadn't been touched in five years, but was the only thing keeping a critical patient referral batch job alive.

The file path issue you mentioned is a silent killer. We saw it with legacy accounting software where the service account needed write access to a specific network drive letter. In the cloud, that mapped drive simply vanishes. The "mini-project" to fix it involved recreating an entire folder structure in Azure Files and hoping the app's config file was actually editable.

It's never a migration. It's always an archaeological dig followed by a rebuild.

The "one in, one out" rule for policy exceptions is a solid operational guardrail. It mirrors what we had to implement after a policy count reached unmanageable levels in a previous rollout.

You're dead right about testing the managed identities for API permissions before cutover, but I'd stress the need to test under load. A service account calling a graph API for user lookup might work fine in a single test, but fail under the concurrent load of a batch process because of throttling limits on the new managed identity. That's the kind of Friday afternoon surprise that really smarts.

Your point on editable config files is also key. We found some older apps had their service account credentials hardcoded in encrypted config sections. The "mini-project" turned into a full vendor support ticket.

Entra ID as the IdP is a solid choice, but I'd pair it with a *secondary* identity provider for their external collaborators from day one. Even if it's not used initially, having it pre-configured for guest/contractor logins will save so many headaches later when a partner firm needs limited access.

Also, test the IdP integration with all their legacy on-prem apps before committing. I've seen weird SSO issues pop up with specific Java-based apps that don't parse modern SAML assertions correctly. It's a huge blocker if you discover it late.

Entra ID as the foundation is the obvious choice. But you're just mapping a new road to the same old castle. If their on-prem AD is a mess, replicating that structure into Entra ID just moves the problem to the cloud. The goal is zero-trust, not zero-rethinking.

The dangerous gap isn't the IdP choice, it's the assumption that this clean slate magically fixes their operational debt. You'll end up with beautifully configured conditional access policies protecting a directory full of stale service accounts and legacy groups.

Exactly. This is why we force a pre-migration cleanup phase for every client.

You can't fix a broken model by migrating it. The project charter must include authority to prune stale objects and redefine group structures. If you're just syncing AD Connect as-is, you're pre-provisioning your own failure.

We make the directory cleanup a prerequisite for the first policy draft. No exceptions.