On this page · 9 sections
Summary. On 21 August 2026 Cloudflare added saved login profiles to the dashboard sign-in page. A profile stores an email address, a login method and the last-used profile locally in the browser, and a device can hold up to 5 of them. Selecting one prefills the email field for a password login or resumes the associated SSO or social login flow. The changelog post links to exactly two documentation pages. Neither mentions saved profiles. The login page carries a "Last updated Apr 20, 2026" stamp, four months before the change; the dashboard SSO page was updated on 14 August 2026, one week before it. Dashboard SSO is free on every plan tier, from the $0 Free plan to Business at $250/mo billed monthly, so this affects paid and unpaid Cloudflare accounts alike.
That gap is the story. A credential-hint cache landed on the authentication path of a control plane that fronts DNS, WAF and Zero Trust policy, and the three pages an access reviewer would open next are silent about it.
What actually shipped
The changelog post is short and specific. Cloudflare states that after a successful sign-in, "users can choose to save a login profile on that device. Saved profiles store the email address, login method, and last-used profile locally in the browser."
Three details carry the operational weight:
Saved profiles appear directly on the login page, before authentication. Selecting one "can prefill the email field for password logins or resume the associated SSO or social login flow." Up to five login profiles can be saved per device, and profiles can be removed from the list at any time.
Nothing here is a credential store. The changelog does not claim profiles hold passwords, tokens or session cookies, and we found no source that says they do. What they hold is the pairing of a work email address with the authentication method behind it, sitting in browser storage on whatever machine the sign-in happened on.
The documentation gap, page by page
We fetched the Cloudflare Fundamentals pages that an access review would touch, in Markdown, on 24 August 2026, and searched each for any mention of saved or login profiles. The result is uniform.
| Documentation page | Last updated | Mentions saved login profiles |
|---|---|---|
| Log in to Cloudflare | 20 April 2026 | No |
| Set up dashboard SSO | 14 August 2026 | No |
| Account security | 20 April 2026 | No |
| Two-factor authentication | 20 April 2026 | No |
| Manage account members | 20 April 2026 | No |
| Manage roles | 10 August 2026 | No |
| User profiles index | 20 April 2026 | No |
The dashboard SSO page is the one that matters most, because it is the page the changelog itself points at and because it was edited on 14 August 2026, only seven days before the feature went out. It carries a "Limitations" section listing four things dashboard SSO does not support: plus-addressed emails such as example+2@domain.com, a separate email-based policy on the Zero Trust SSO application that does not match the SSO domain policy, multiple Zero Trust domain policies, and deleting the auto-generated allow email domain policy. Saved login profiles are not among them, in either direction. The page neither permits nor restricts them.
Cloudflare's own Log in to Cloudflare page still describes exactly three sign-in options as of its 20 April 2026 revision: email and password, Single Sign-On, and social login with Apple, Google or GitHub. A returning user in late August 2026 sees a fourth affordance on that screen that the page does not document.
Why this lands harder on SSO-enforced domains
Dashboard SSO at Cloudflare is domain-wide by design, and the docs say so plainly. The enable step carries a caution that enabling SSO for an email domain "will apply globally to all users with that domain, regardless of which accounts those users have access to. All users will be required to authenticate via the specified identity provider, including users registered on Cloudflare prior to the domain being configured for SSO."
So the population that can save a profile is the entire email domain, not a team you picked. The prerequisites reinforce how broad that is: you must control the email domain and prove it with a TXT record, public providers such as @gmail.com are not allowed, and every user with that domain must be an employee, which is why Cloudflare excludes university domains like @harvard.edu. You must also be a Super Administrator with API access, and a Cloudflare Zero Trust organization must exist, at any tier including Free.
Set the two facts side by side. Enrolment in SSO is an administrator decision applied to every address in the domain. Saving a login profile is an end-user decision applied to one browser. We found no documented administrator control that disables, restricts or audits saved profiles for an SSO-enforced domain, and no documented way to see which devices hold one. If such a control exists, it is not on the SSO page, the login page, the roles page or the account security page.
The practical shape of the risk is mundane rather than dramatic: a shared workstation, a contractor laptop, a kiosk in a support room. The profile does not sign anyone in on its own. It does tell whoever opens that browser which corporate email addresses administer Cloudflare there, and which identity provider stands behind them. That is reconnaissance handed over before any authentication challenge, and it is the same category of exposure covered in our note on device code phishing controls in Entra, Okta and Google Workspace.
Who should care, and how to tell if that is you
Check three things. First, whether your organisation has an enabled SSO connector on a verified domain, which you can confirm from the connector list in the dashboard or the sso_connectors API. Second, whether Cloudflare dashboard access is reached from shared or unmanaged devices anywhere in your estate. Third, whether your browser fleet policy clears site data on exit for dash.cloudflare.com. If the answers are yes, yes and no, saved profiles change your exposure and no Cloudflare document currently tells you by how much.
Cost is not the filter here. Dashboard SSO is listed as available on Free, Pro, Business and Enterprise plans, and Cloudflare's plans page shows the Free plan at $0/month, Pro at $25/mo billed monthly, and Business at $200/mo billed annually or $250/mo billed monthly, with the Zero Trust tier free forever for teams under 50 users as of 24 August 2026. A two-person startup on the Free plan gets the same login screen as an enterprise.
What to do now
Treat this as a browser-storage question, not a Cloudflare question, because that is where the data sits.
Clear existing profiles on any shared device. The changelog confirms saved profiles can be removed from the profile list at any time, which is the only removal mechanism Cloudflare documents. Add dash.cloudflare.com to the on-exit site-data clearing list in your managed browser policy. That is enforceable from your MDM today and does not wait on a Cloudflare feature.
Keep the bypass path intact and tested, because it is unrelated to profiles and far more likely to hurt you. Cloudflare documents two ways back in if SSO breaks: add a backup identity provider such as Cloudflare One-time PIN, or disable dashboard SSO. The SSO page also warns that deleting the auto-generated allow email domain policy locks your administrators out of the dashboard entirely. Test the backup IdP before you need it.
Re-check the login page in a few weeks. Cloudflare ships documentation and product on separate cadences, which we saw again in the Cloudflare One client 2026.7.1343.0 known-issue fork and in the Wrangler optional OAuth scopes gap. The reference page usually catches up. Until it does, the changelog is the only authority on what a saved profile contains.
The real cost here is not the feature. It is that an access review run against Cloudflare's documentation in the last week of August 2026 would not know the feature exists.
India-specific considerations
For teams operating under India's Digital Personal Data Protection Act 2023, a work email address stored in a browser is personal data held on an endpoint, and the storage sits outside the Cloudflare account boundary an audit usually scopes. Organisations building consumer identity flows face the same question one layer down, which is why we cover passkeys versus SMS OTP for Indian WebAuthn migrations separately. The control that matters is endpoint browser policy, and it belongs in the same register as your other device hardening entries.
FAQ
How eCorpIT can help
eCorpIT is an ISO 27001:2022 certified, CMMI Level 5 engineering organisation, and our senior-led identity teams run access reviews across cloud control planes where the product ships faster than the documentation. We map who can reach each console, from which devices, under which identity provider, and we design applications aligned with DPDP Act 2023 requirements. If your Cloudflare estate has grown past the point where anyone can name every Super Administrator, book an access review with our identity team.
References
Last updated 24 August 2026.
