Cloudflare Organizations addresses the issue of access management (RBAC) in a multi-account environment. This is crucial for SREs and architects, where thousands of users and disparate accounts create fragility in management.
The problem does not manifest immediately — until the number of accounts begins to grow faster than they can be administered. In enterprise scenarios, teams segment resources through separate Cloudflare Accounts to adhere to the principle of least privilege. This reduces the risk of excessive access but creates a side effect: control becomes fragmented. Administrators are forced to manually be present in each account, and their permissions can be altered or revoked. With thousands of accounts and users, this turns into an unstable system where RBAC exists formally but becomes operationally complex.
The solution is to add a layer of abstraction over the accounts. Cloudflare Organizations introduces an organizational layer that unifies multiple accounts into a single structure. The key idea is to centralize user management, policies, and analytics without violating access boundaries within individual accounts. This is a compromise: on one hand, team isolation is preserved, while on the other hand, a control point emerges for administrators. An important limitation: the system does not automatically elevate privileges. Any addition of an account requires the involvement of a Super Administrator, which reduces the risk of uncontrolled access.
Architecturally, Organizations is built on top of a Tenant system that was previously used for the partner ecosystem. This provided a ready-made model for multi-tenancy and allowed a focus on consolidating authorization. As part of this work, the access check system has been revamped: outdated paths have been removed, and logic has been unified through domain-scoped roles. The changes are substantial — approximately 133,000 lines of code have been added and 32,000 lines of legacy code removed. This is not merely a refactor but an alignment of the access model, which is important for further expanding roles at the organizational and account levels.
A separate emphasis is on performance. Access checks on listing operations (e.g., /accounts or /zones) historically degraded with a large number of resources. After the changes, a 27% improvement in performance has been recorded. This is a direct result of simplifying the authorization model and eliminating redundant checks. For high-load scenarios, this is critical: latency in the control plane begins to affect the UX of administrators and automation.
The new Org Super Administrator role becomes the central control point. It does not require membership in child accounts but has full access to them. This eliminates the need for manually adding administrators to each account. At the same time, such users do not appear in the UI of the specific account, preserving local management cleanliness. This is an interesting compromise between transparency and centralized control.
From an operational perspective, an aggregated analytics layer has been added. Administrators can view HTTP traffic across all accounts and zones in a single dashboard. Currently, this is limited to HTTP analytics, but the architecture allows for expansion. This is an important step toward unified observability at the organizational level, although it is not yet a complete observability system.
Another layer is centralized policies. Organizations allows sharing policies (e.g., WAF) between accounts. This changes the security management model: now the security team can update rules once and apply them across the entire organization. At the same time, the rights to modify remain with the team owning the original account. This reduces configuration duplication and the risk of desynchronization but requires careful management of the source of truth.
The implementation process is intentionally designed to be self-service. Cloudflare does not automatically create organizations. This prevents implicit privilege escalation. Creating an organization and adding accounts requires explicit agreement among administrators. This approach increases the operational burden at the start but makes the access model predictable.
In summary, this is an evolutionary improvement of RBAC in a multi-account architecture. Organizations does not replace the existing model but adds a layer of coordination. The main gain is a reduction in administrative fragility and improved performance of access checks. Limitations are also evident: the system requires discipline in role management and currently does not cover all scenarios for analytics and policies. But the foundation is laid — and it is clearly designed for further expansion.