Cloudflare Organizations Enters Public Beta: Unified Multi-Account Management

Enterprises running Cloudflare at scale share a common pain point. Cloudflare accounts are split across business units and subsidiaries, each with its own WAF rules and DNS configurations. There was no cross-account management mechanism for enforcing a unified security policy—super admins had to log into each account individually.

Cloudflare Organizations, released as a public beta on April 6, is the official answer. It places an organizational layer “above” individual accounts, enabling cross-account management, analytics, and policy distribution from a single pane.

What It Does

Organizations provides four capabilities:

Feature	Description
Account List	Flat view of all accounts under the organization. Up to 500 accounts and 500 zones
Org Super Administrator	Organization-level super admin role. Can manage all accounts without per-account membership
Aggregated Analytics	Cross-organization HTTP traffic dashboard
Shared Configurations	Distribute WAF custom rulesets and Gateway policies to multiple accounts at once

The per-organization limit is 500 accounts and 500 zones. This is the same category of functionality as AWS Organizations and Google Cloud’s organization resource—the multi-account management layer that every cloud service needs beyond a certain scale.

The Real Work Was Unifying the Authorization System

On the surface it looks like “they added a management console,” but internally it was a much larger effort. Cloudflare’s authorization system had accumulated multiple mechanisms over years of growth. Building Organizations required consolidating them into a single domain-scoped roles system.

The code change totaled approximately 133,000 lines added and 32,000 lines deleted. Not a simple feature addition—it was a full rewrite of existing authorization checks.

A side effect of this unification: permission checks on enumeration API endpoints like /accounts and /zones became 27% faster. Users with access to thousands of accounts previously experienced significantly slow responses, which the authorization logic cleanup resolved.

graph TD
    A[Legacy Auth System] --> B[Legacy Roles]
    A --> C[Tenant System<br/>for Partners]
    A --> D[Per-Account<br/>Membership]
    B --> E[Domain-Scoped Roles<br/>Unified Auth System]
    C --> E
    D --> E
    E --> F[Organizations]
    E --> G[Existing Account Management]
    E --> H[Partner Ecosystem]

Org Super Administrator Permission Model

The new Org Super Administrator role implicitly holds Super Administrator privileges across all child accounts in the organization. It operates independently of per-account member management and does not appear in child account member lists.

graph TD
    O[Organization] --> OSA[Org Super Administrator]
    O --> A1[Account A]
    O --> A2[Account B]
    O --> A3[Account C]
    OSA -.->|Implicit Super Admin| A1
    OSA -.->|Implicit Super Admin| A2
    OSA -.->|Implicit Super Admin| A3
    A1 --> M1[Account A<br/>Member List]
    OSA -.->|Not Visible| M1

This is a deliberate security design. By hiding the organizational administrator from child account members, account-level attackers have a harder time identifying and targeting the org admin. The tradeoff is reduced visibility into “who can touch this account.”

How Shared Configurations Work

WAF custom rulesets and Gateway policies can be distributed from a source account to multiple target accounts. The key point: users with configuration management permissions on the source account can update shared policies without being organization administrators. This enables a workflow where the security team manages company-wide WAF rules while each business unit’s account admins only touch their own account-specific settings.

graph LR
    SA[Source Account<br/>Managed by Security Team] -->|WAF Ruleset Distribution| T1[Business Unit A Account]
    SA -->|WAF Ruleset Distribution| T2[Business Unit B Account]
    SA -->|Gateway Policy Distribution| T3[Subsidiary Account]
    SEC[Security Team] -->|Config Management Permissions| SA

This is conceptually similar to AWS Service Control Policies (SCPs) or Azure Management Groups policies, but Cloudflare’s implementation is scoped to WAF and Gateway. It’s specialized for rolling out security policies across the organization rather than applying organization-wide guardrails.

Terraform Support

The Terraform provider supports Organizations from day one. Organizations, account assignments, and configurations can all be managed as code. In enterprise environments, clicking through a GUI to configure hundreds of accounts isn’t realistic, so IaC support was essential.

Cloudflare has been investing heavily in its Terraform provider, with nearly all major resources—Workers, Pages, WAF, DNS, Tunnels—already Terraform-manageable. Organizations is a natural extension of that effort.

Security-First Rollout

For the beta launch, Cloudflare has been thorough about preventing privilege escalation:

• No automatic Organization creation. Enterprise account Super Administrators receive a dashboard invitation
• One Organization per company only
• No silent expansion of existing user permissions
• Cloudflare support cannot make configuration changes on behalf of customers

Permission model changes always carry risk. Cloudflare took a similarly cautious approach when they rolled out Client-Side Security’s GNN+LLM detection to all users, and Organizations follows the same playbook.

Roadmap

Currently limited to enterprise customers, with plans to expand to Pay-as-you-go plan customers over the coming months. Partner ecosystem support requires special-case consideration and has no set timeline.

Planned additions include organization-level audit logs, billing reports, expanded per-product analytics dashboards, additional user roles, and self-serve account creation. Audit logs in particular are a priority need—without cross-organization operation history during incident response in a multi-account environment, the feature isn’t production-ready.