Verification is an access-control primitive

The system assumption

The assumption is that registration is a convenience feature, so the priority is to make it frictionless. Verification feels like a UX tax. The default role feels like a sensible starting point so new users are not blocked. Both framings treat sign-up as onboarding. But sign-up is where the system decides two security facts: who this account is allowed to claim to be, and what it is allowed to do. Those are access-control decisions wearing onboarding clothes.

Where the assumption breaks

Unverified identity

If registration never confirms control of the email or phone number supplied, then the address is just a string the user typed. They can type someone else's. Now the account is associated with an identity the registrant does not own, and everything downstream that trusts that association is wrong: notifications, password resets sent to "the account's" email, any access granted because the address matches an allowlist or a known customer. Verification is what turns "an email the user typed" into "an identity the user demonstrably controls." Without it, identity is self-asserted.

Over-privileged defaults

If a newly created account is assigned a role with broad powers, then the registration form is an authorization grant. We examined a production system, reachable on the internet, where open sign-up with no verification placed each new user in the organization-owner role. The distance from "anonymous stranger" to "administrator of a live environment" was one sign-up form. No exploit. The default did the work.

Reconstructing it

  open registration, no verification, owner-by-default

  anyone on the internet
        |  POST /signup  { email: "anything@example.com" }
        v
  account created, marked verified? no, but usable
        |  default role assigned
        v
  role = Organization Owner   <-- full administrative control

Why the obvious defenses didn't solve it

"It is behind a login." A login that anyone can create for themselves is not a barrier. Requiring an account only matters if creating an account requires something the attacker does not have. Free, unverified registration makes the login a formality.

"We will verify later / on first sensitive action." Deferred verification leaves a window in which an unverified identity is already trusted, and in the over-privileged case the very first action can be sensitive. If the default role can already do damage, "verify later" is too late.

Rate limiting the sign-up form. Useful against bulk abuse, irrelevant to the core flaw. One carefully chosen registration is enough when it grants a real identity or a real privilege.

Root cause

The root cause is that identity and privilege were granted by default rather than earned by proof. Verification is the proof that an identity claim is genuine; least-privilege defaults ensure that a fresh, unproven account can do almost nothing until it earns more. Both flip the burden the right way: the system should assume a new account is anonymous and unprivileged until it demonstrates otherwise, not assume it is trustworthy until something goes wrong.

How to test for this class of failure

• Register with an address or number you do not control and see whether the account becomes usable, and whether any trust (resets, notifications, access) is extended to that unverified identity.
• Immediately after registering, enumerate what the new account can do. Look at its role, its permissions, and every endpoint it can reach. The question is not "did it log in" but "what did it just become."
• Check for internet-exposed instances of self-hosted tools with registration enabled. Default configurations often assume a trusted network that is not there.
• Test whether verification, where present, is actually enforced or merely requested. A verification email that is optional to the flow is not verification.

How to design the control correctly

• Verify before trusting the identity. Confirm control of the email or phone before the associated identity is used for anything security-relevant. Until then, treat the address as unproven.
• Default to least privilege. A new account starts with the minimum, and elevation to any meaningful role requires an explicit, authorized grant, not a default assignment.
• Gate registration to its context. If a tool is meant for one organization, do not leave open public sign-up on an internet-reachable instance. Restrict who can register, or require invitation.
• Separate "account exists" from "account is trusted." Model verification state explicitly, and make trusted actions check it, so an unverified account cannot slip into a trusted path by default.

What we took away from it

It is easy to file verification and default roles under product polish, the sort of thing you tighten after launch. The corpus says otherwise: these decisions set the floor for everything else. An unverified identity poisons every feature that trusts identity, and an over-privileged default makes registration itself the exploit. We treat the sign-up path as a security boundary now, and the first thing we ask of any new account is not whether it can log in, but exactly how much it was handed for free.