Cloudflare access: manage it with members, or with a partner?

In practice there are five, and one of them should be ruled out immediately. Which one you pick decides more than convenience: it decides who holds responsibility, who holds the invoice, and how easily access comes back when the work ends.

• Sharing the password: The most common and the worst option. Nobody can tell who changed what, two-factor authentication becomes decorative, and if the password isn't rotated when the work ends, access quietly continues. Cloudflare's member system exists precisely to make this unnecessary.
• Member invite (member + role): The account stays yours; the agency or teammate signs in with their own Cloudflare user under a limited role. The default — and in most cases the correct — route.
• Partner (Tenant) model: The account is created and managed by a party holding a Cloudflare partner agreement; you are an account inside that structure.
• Organizations: A top-level container for managing several Cloudflare accounts at once. It requires an Enterprise account and is in public beta.
• API token: Access granted to a tool, not a person. For a deploy pipeline or an automation, this — rather than a user invite — is usually the right answer.

API tokens are not an alternative to the others but a complement: if a script needs to purge cache or write a DNS record, minting a narrowly scoped token for that job is far safer than granting account permissions to whoever runs the script. Revoking a token is also easier than removing a person from an account.

Member invites run through Manage Account → Members in the Cloudflare dashboard. Two conditions apply to whoever sends the invite: they must hold the Super Administrator role and have a verified email address (Cloudflare Docs). The invited person signs in with their own Cloudflare user — no password is shared, and every change is attributable in the audit log.

Permissions in Cloudflare are not a single checkbox but a policy. Each policy combines three parts: the person receiving the permission (actor), the scope it applies to (resource group) and what they may do within it (permission group, i.e. roles) (Cloudflare Docs).

Three scopes: account, domain, resource

• Account-scoped roles apply across the whole account and every domain in it. Super Administrator, Administrator, Administrator Read Only, Billing, Analytics, Audit Logs Viewer, Cache Purge, DNS and Minimal Account Access all sit here.
• Domain-scoped roles apply to one domain inside the account. If you run several brands, or a production and a staging domain, this is how you bind an agency to only the domain they work on.
• Resource-scoped roles are the finest grain — permissions limited to a single resource such as one Access application or one Tunnel. Cloudflare marks this scope as beta (Cloudflare Docs).

The role names sound technical, but the choice is simple: the role should match the job. Reading performance reports only? Analytics. Purging cache after releases? Cache Purge. Handling domain migration and DNS records? DNS. Publishing the site on Cloudflare Pages/Workers? Workers Platform Admin. Auditing the setup without touching it? Administrator Read Only. Super Administrator also covers managing members and billing — handing that to an outside party needs a genuinely strong reason.

One caveat: a member's effective permissions are the union of what is granted to them directly and what they inherit through group membership. Permissions stack rather than constrain each other, and the Members view shows only directly assigned policies — inherited ones live in the Groups tab (Cloudflare Docs). Before you relax about having granted a narrow role, check the group memberships too.

Pros

• Ownership stays with you. The account, the domain and the billing relationship remain in the brand's name; when the agency changes, nothing has to be migrated — a membership is simply revoked.
• Permissions can genuinely be narrowed. Domain- and resource-scoped roles let you tune the grey area between "can see everything" and "can do nothing".
• It leaves a trail. Because everyone signs in as themselves, the audit log shows who changed what and when. Shared passwords destroy that information entirely.
• Revocation is instant. When the work ends you revoke the membership — no password rotation, no team-wide announcement, no hunting for a forgotten session.
• No extra cost. Cloudflare's documentation does not gate member invites behind a plan; only adding an existing user without an email confirmation is Enterprise-only (Cloudflare Docs).

Cons

• The admin work is yours. Inviting, picking the right role and cleaning up leavers is the brand's job. Nobody sends a reminder; the freelancer who left six months ago may still be a member.
• The role list is crowded. Finding the right one among dozens takes time the first time, and a wrong pick either blocks the work or over-grants.
• Group inheritance surprises people. Because permissions are a union, a role you believed was narrow may have been widened by a policy inherited from a group.
• Single-Super-Administrator risk. If one person is the account's only super admin and they are unreachable, nobody can manage members or billing. Keeping at least two is a good habit.
• It doesn't scale on the agency side. For an agency, every client means another invite, another account, another dashboard; across dozens of clients that gets messy.

The partner model is built on Cloudflare's Tenant structure. Cloudflare describes the Tenant API as a provisioning mechanism that helps Channel and Alliance partners set up and manage Cloudflare accounts and services for their customers (Cloudflare Docs). It is not a setting a brand can switch on in the dashboard; it is the technical expression of a commercial relationship between two companies.

The mechanics are clear: once a partner agreement is signed, Cloudflare creates a dedicated Tenant account and adds the partner's user to it as a Tenant admin. Tenant admins become the default Super Administrator for every account and zone contained in the Tenant (Cloudflare Docs). The partner then provisions customer accounts, subscriptions and zones through the API or the dashboard.

There is also Organizations: a top-level container that gathers several Cloudflare accounts so they can be managed without a separate membership on each one. Organization members automatically receive Super Administrator permissions on child accounts; creating one requires an Enterprise account, and the feature is in public beta (Cloudflare Docs). For groups running multiple brands at enterprise scale, it is an alternative path to the partner model.

Pros

• Setup work leaves the brand. Creating accounts, adding domains and assigning subscriptions happen on the partner side, programmatically.
• Built for many customers. Managing dozens of accounts from one structure is faster and more consistent than chasing invitations.
• One point of contact. Billing, support and technical responsibility sit in one place; the brand doesn't need its own Cloudflare relationship.
• Standardised configuration. The same security and performance settings can be applied to every customer account repeatably.

Cons

• Not open to everyone. The Tenant structure requires a signed partner agreement with Cloudflare — not a model you can adopt over an afternoon by deciding to.
• The default permission is the widest one. A Tenant admin is Super Administrator by default on every account inside. The "DNS only" precision of the membership model simply isn't there to begin with.
• It creates lock-in. If the partner created the account, ending the relationship turns handover into a technical work item rather than a revoked invitation.
• Transparency is contractual. How much of the dashboard the brand can reach, see and change is not a technical default — it is whatever the agreement says.
• Too heavy at small scale. For a single brand with a single domain, the abstraction it introduces is larger than the problem it solves.

For one domain, one brand and outside support — which describes very nearly every cosmetics brand — the right answer is scoped membership. The account is opened in the brand's name, and the agency is invited with their own user under a role that matches the work they do. The partner model was designed for parties that provision and operate many customer accounts; it is not a menu option a brand picks to make life easier.

A short checklist for granting access:

• Open the account in your own name; keep the domain and billing relationship with the brand.
• Don't hand out Super Administrator; pick the narrowest role that matches the job and bind it to a domain scope where possible.
• Keep at least two Super Administrators; an account depending on one person is a single point of failure.
• Require two-factor authentication (2FA) from everyone.
• For automation and deploys, mint a narrowly scoped API token instead of inviting a user.
• Review the member list and audit logs quarterly; clean out whoever has left.
• Revoke membership the same day the work ends — access left in place "just in case" is access nobody remembers.

To see where these sit on the map: Cloudflare, Cloudflare member roles, Cloudflare partnership and, on the infrastructure side, DNS.