Start with applications and people, not settings
List every private system the team reaches: administration panel, code hosting, analytics, NAS, staging site, SSH hosts, RDP systems and internal APIs. Record who uses it, whether the access is interactive or machine-to-machine, and how painful an outage would be.
Then define a small set of identities: staff, administrators, contractors and service accounts. Ten custom policies for ten people are harder to audit than three groups with clear exceptions.
Use the existing identity provider as the control point
If the team already uses Google Workspace or another supported provider, connect it to Cloudflare Access so joins, role changes and departures start from one directory. Require MFA at the identity provider or policy layer based on the risk of each application.
Keep at least one documented emergency administrator workflow. It should be protected and reviewed, not a shared password that everyone quietly relies on.
Group applications by access pattern
Public customer applications may use Tunnel without Access. Internal browser tools use Access with staff or admin groups. SSH, RDP, NAS and private hostnames may use WARP or a protocol-specific route. Automated APIs use service credentials instead of employee sessions.
This separation keeps a convenient public website from inheriting employee login rules and prevents a service token from becoming a general staff credential.
- ▸ Public: website and customer API routes
- ▸ Staff: wiki, analytics and internal operations tools
- ▸ Admin: infrastructure panels, SSH and RDP
- ▸ Contractor: one project application with an expiry date
- ▸ Machine: scoped service-to-service routes
Pilot one low-risk application
Choose an internal web application used by two or three people. Publish it through Tunnel, add an Access policy and test normal login, expired sessions, a denied account and administrator recovery.
Run the old path in parallel long enough to collect real feedback. When the pilot is stable, repeat the pattern for higher-value applications.
Add WARP only for workflows that need private routing
Browser-based Access does not require every device to join a private network. Introduce WARP for private IPs, hostnames or protocols that need it, then use split tunnel and network policies to limit which traffic enters the Cloudflare path.
Test on the actual macOS, Windows or mobile devices the team uses. DNS behavior, conflicting VPN clients and endpoint permissions can change the result.
Make offboarding a test, not a document
Disable a test identity and confirm it cannot start a new session. Review session duration, WARP enrollment, service tokens and any local application accounts that survive identity-provider removal.
A real departure checklist should name who disables the identity, who removes device or application credentials and who reviews access logs.
- ▸ Disable the primary identity
- ▸ Revoke device enrollment where used
- ▸ Remove app-local roles and API keys
- ▸ Rotate shared credentials that could not be eliminated
- ▸ Review active sessions and recent access
Keep the operating model small
Review the application and group inventory on a regular schedule, not only after an incident. Delete stale policies and expired contractor rules. Monitor connector health and the application itself so a healthy tunnel does not hide a failed origin.
For a 10-person team, a one-page policy map and named owners are more valuable than an enterprise control catalog nobody maintains.