cloud phone role-based access control (RBAC) 2026
cloud phone role-based access control (RBAC) 2026
cloud phone RBAC in 2026 is what separates a tool that works for 5 engineers from a platform that works for 500. without RBAC, every user has either too much access (admin everything) or too little (cannot do their job). with RBAC, you give each user exactly the permissions their role needs and nothing more, the audit log tells you who did what, and your security team signs off without a fight.
this guide walks through the cloudf.one RBAC model: built-in roles, custom roles, permission scopes, IdP integration, and the workflows that hold up under SOC 2 and ISO 27001 audits. if you have not yet organized teams and seats, start there.
the RBAC mental model
three layers.
- roles: collections of permissions (e.g. “QA tester”, “billing-only”, “ops on-call”)
- permissions: specific actions (lock device, unlock device, view audit log, change billing)
- scopes: where the role applies (whole account, one team, one device pool, one tag)
a user can have one role per scope. the role determines what they can do; the scope determines where.
[SCREENSHOT: RBAC overview page showing roles, permissions matrix, and scope dropdown]
built-in roles
cloudf.one ships three built-in roles that cover 80% of needs.
| role | scope | permissions |
|---|---|---|
| admin | account | everything (devices, users, billing, audit logs, integrations) |
| member | account | lock/unlock devices, view own session history |
| viewer | account | read-only across fleet, no lock |
most teams start with these. as the team grows past 20 users you outgrow the built-in roles.
when to create custom roles
three signals.
- a user needs more than viewer but less than member (e.g. can view all sessions but only lock test devices)
- a user needs more than member but less than admin (e.g. can manage billing but not create users)
- you want to scope a member role to a specific team or device pool
custom roles solve all three.
creating a custom role
from the admin dashboard, navigate to RBAC, then Custom Roles, then Create Role.
[SCREENSHOT: custom role creation form with role name, description, permissions checklist, and scope dropdown]
three steps.
- name and describe (e.g. “QA-test-pool-only”)
- tick the permissions (lock device, view session, take screenshot, but not unlock-others or change-billing)
- set the scope (the test-pool team, or a specific device tag)
save. the role appears in the role list and can be assigned to users immediately.
a sample 5-role setup
a typical 50-engineer team uses five custom roles plus the built-in admin.
| role | scope | what they can do |
|---|---|---|
| admin | account | everything |
| QA-tester | qa-pool team | lock devices in qa-pool, screenshot, view own sessions |
| dev-engineer | dev-pool team | lock devices in dev-pool, install APK, ADB, view own sessions |
| ops-on-call | account | reboot any device, view all sessions, view audit log; cannot change billing or users |
| billing-admin | account | view and update billing, view invoices; cannot lock devices |
| security-auditor | account | read-only audit log, no other permissions |
with these five, you can onboard any new engineer in 60 seconds: pick the role, pick the team, send the invite.
permission catalog (selected)
cloudf.one exposes 40+ permissions across five categories. selected highlights.
device permissions
device:lock— lock a device for usedevice:unlock— unlock own devicedevice:unlock_any— force-unlock anyone’s locked devicedevice:reboot— reboot a devicedevice:wipe— factory reset a devicedevice:tag— change tags on a device
user and team permissions
user:invite— invite new usersuser:suspend— suspend a useruser:role_change— change a user’s roleteam:create— create a teamteam:add_user— add a user to a team
billing permissions
billing:view— view invoices and current usagebilling:update_payment— change payment methodbilling:upgrade_plan— change plan tier
security permissions
audit:view— view the audit logaudit:export— export audit log entriesrbac:create_role— create custom rolesapi:create_key— create API keyssso:configure— change SSO settings
[SCREENSHOT: full permission catalog grouped by category with checkbox toggles]
scoping permissions
a permission alone is just an action. add scope to control where it applies.
three scope types.
- account: applies to everything in the account
- team: applies only to resources in the named team
- tag: applies only to devices matching a tag
example: a “QA-lead” role with device:lock and device:unlock_any scoped to the team “qa”. the QA lead can manage their team’s devices but cannot touch dev-pool or production devices. they cannot see other teams’ sessions.
[SCREENSHOT: role scope settings page with team selector and tag selector]
scoping is what makes RBAC actually useful in larger teams. without scopes, “QA-lead” would have unlock_any across the whole account, which security teams reject.
mapping IdP groups to roles
if you use SSO via Okta, Azure AD, or Google Workspace, you can map IdP groups to cloudf.one roles. this means new joiners get the right role automatically based on their IdP group membership.
[SCREENSHOT: SSO group mapping page with IdP group on left, cloudf.one role on right, add mapping button]
a sample mapping.
| IdP group | cloudf.one role |
|---|---|
| qa-engineers | QA-tester |
| backend-engineers | dev-engineer |
| sre-on-call | ops-on-call |
| finance-team | billing-admin |
| security-team | security-auditor |
new engineer joins, HR adds them to the IdP group, they log in, get the right role. zero manual admin work.
the principle of least privilege in practice
three rules.
- start with the most restrictive role that lets the user do their immediate job. expand later if needed.
- review roles quarterly. roles drift; old contractors keep admin from a project that ended 8 months ago.
- separate duties for sensitive actions. nobody should both create users and manage billing without two-person approval if possible.
teams that follow these three pass security audits. teams that do not get rejected on the audit log review.
auditing role changes
every role assignment, removal, and custom role creation lands in the audit log. review monthly.
watch for:
- admin promotions (rare, should be deliberate)
- new custom roles with broad permissions
- self-promotions (someone changed their own role)
- role assignments outside the IdP-mapped flow (likely manual override)
if any of these surprise you, investigate. the audit log makes the investigation trivial.
API keys and RBAC
API keys inherit the role of the user who created them, but only with permissions the user explicitly grants per key.
[SCREENSHOT: API key creation form with permission scope checkboxes per key]
best practices.
- never create an API key with admin role for automation
- create a service account user with a custom role tailored to the automation’s exact needs
- rotate API keys every 90 days
- log API key usage to your SIEM
frequently asked questions
what is the maximum number of custom roles per account?
cloudf.one supports up to 100 custom roles per account in 2026. most teams use 5-15.
can I clone a built-in role to start customizing?
yes. on the role list, click “duplicate” next to any built-in role. modify the copy. saves typing.
what happens to a user when their assigned role is deleted?
the user falls back to viewer (read-only) until reassigned. they get an in-app notification. the audit log captures the event.
can two custom roles overlap permissions?
yes, but a user can only have one role per scope. if they need union of two roles, create a new combined custom role.
do role changes propagate immediately?
yes. cloudf.one refreshes user permissions on the next API call or page load, typically within 60 seconds.
ready to design your RBAC model? start a cloudf.one trial, set up the 5-role pattern above, and walk a security reviewer through it for sign-off.