What to prove before public signup

Before a stranger can create an account, three things have to be true when you are alone. You can close registration without waiting for a deploy from the person who built it. The message that new account receives comes from a domain you administer, and a failure to deliver comes back to you. You can erase that one account — the row, the file it created, the session — and show that it is gone. If any of the three still requires a call, the door is not yours. Leave signup off.

This is the night the product meets someone you did not invite. It is not the inventory you demand on the last day, and it is not the afternoon you spend before paying an invoice. The last day asks whether the accounts, the domain, and the history were ever in your name. The invoice asks whether this period's commits are in a repository you can open, whether the acceptance sentence passes when you run it, and whether a second account is refused. Both can be settled while the signup form on the public URL still creates a user that only your contractor can delete. The rest of this article is the three proofs, in the order a founder can perform them in an afternoon.

None of what follows makes you a federal identity provider, and none of it is legal advice. The standards below describe controls a serious operator already expects of itself. They do not tell you what your terms of service must say, and they do not replace a lawyer when a real person asks you to delete them. What you do on that day, once a customer exists, is when a customer asks to be deleted.

You can close the door. NIST's control CM-5, Access Restrictions for Change, is one sentence: "Define, document, approve, and enforce physical and logical access restrictions associated with changes to the system" (NIST, SP 800-53 Rev. 5, September 2020, updated 10 December 2020). The discussion under it is the part a founder can use. Changes to software "can potentially have significant effects on the security of the systems or individuals' privacy," so "organizations permit only qualified and authorized individuals to access systems for purposes of initiating changes." The same paragraph lists what a restriction can look like, including "abstract layers (i.e., changes implemented into external interfaces rather than directly into systems), and change windows (i.e., changes occur only during specified times)."

Read that as the signup switch, not as a change-advisory board. Opening registration is a change to the system. Closing it is a change to the system. The person who may initiate that change has to be someone you authorised, and the mechanism has to be one you can reach when the contractor is asleep. A feature flag that lives in a project only they can log into is not a restriction you approved. It is a courtesy. The abstract-layer example in CM-5 is the shape that passes: the public form posts to an interface you control, and that interface can refuse new accounts without a code change. A comment in the repository that says "we can turn it off" is the shape that fails.

Sit down without a call and do the proof. Create no account. Find the control that stops the form. Flip it. Load the public page in a browser that has never seen the product, and confirm the form no longer creates a user. Flip it back only if the other two proofs also hold. If the only way to flip it is a pull request, you do not have a door. You have a request. The same afternoon's cousin, for a period you are being asked to pay for, is what to verify before the next invoice. That check includes a second account being refused. This one is earlier and narrower: can you stop the first stranger.

Registration is already on the list of things attackers use. The OWASP Top 10 for 2021, in the factors table for A07, maps 22 weaknesses to identification and authentication failures, with a maximum incidence rate of 14.84%, an average incidence rate of 2.55%, maximum coverage of 79.51%, average coverage of 45.72%, 132,195 occurrences, and 3,897 CVEs (OWASP, A07:2021 – Identification and Authentication Failures). Read the cells as different facts, the way the access-control table has to be read. Maximum incidence is the highest rate in any one contributing dataset, not the average, and not a prediction about your form. Coverage is how often this class was looked for. Tested is not vulnerable. The average incidence of 2.55% is not the maximum of 14.84%, and neither figure is the 79.51% coverage cell. What you take from the page is the practice the project already names: "Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes." A public signup is one of those pathways. A founder who cannot close it cannot harden it either, because hardening is a change, and CM-5 is about who may make the change.

The mail is yours. The account you just allowed will receive something: a confirmation, a reset, a receipt. If that message is sent from a domain the contractor registered, two failures arrive together. You cannot see the bounce, so you will not know the stranger never got in. And you cannot move the domain on the day you need to, because registrant changes are not instant. The full inventory of registrar, cloud root, and app-store ownership belongs at the end of the contract, and it is the handover. Tonight's proof is smaller. Send the message to an address you control. Read the From domain. Open the mailbox that receives the bounce. If either one is a person's Gmail, or a domain in an account you cannot administer, signup is early.

You can end the one account. NIST's digital identity guideline, in the section on authenticator invalidation, states: "The invalidation of an authenticator (sometimes referred to as revocation or termination) is the removal of the binding between the authenticator and a subscriber account." Then the requirement: "CSPs SHALL promptly invalidate authenticators when a subscriber account ceases to exist (e.g., subscriber's death, the discovery of a fraudulent subscriber), when requested by the subscriber, when the authenticator is compromised, or when the CSP determines that the subscriber no longer meets its eligibility requirements." The next sentence is the one operators under-weight: "The consequences of not invalidating a compromised authenticator are usually more significant than the denial-of-service potential of invalidating one in error" (NIST, SP 800-63B-4, July 2025, final 31 July 2025, superseding SP 800-63B). Elsewhere the same publication requires a mechanism to invalidate an authenticator immediately when the subscriber reports loss, theft, or suspected compromise.

You are not a credential service provider for a federal agency. The translation is still direct, and it is technical rather than legal. If a stranger's account has to cease, the person who operates the product has to be able to remove the binding tonight, not file a ticket with the firm that wrote the form. Create one account yourself, with an email you can open. Sign in. Delete the account from a screen you can reach without the contractor. Then do the three checks that make "deleted" a fact: the row is gone from the table you can query, the session you still hold is refused, and the file that account uploaded is gone from the bucket you administer. A button that hides the user in the interface, while the row remains, is not invalidation. A script only the contractor can run is not a mechanism you hold.

The same afternoon exposes the recovery path, which is where signup products usually fail the second time. If "forgot password" sends a link that logs in whoever holds the inbox, and that inbox is not confirmed to be yours on the test account, you have not proved recovery. You have proved that email delivery works. NIST's point about a fraudulent subscriber is the reason the delete has to work on an account you did not want, not only on an account you did. A test that only deletes your own friendly user never meets the case the control names.

There is a version of this afternoon where hiring more engineering is the wrong purchase. Nothing has been built, so there is no form to close and no row to delete — that is a scope conversation, not a signup audit. You are still choosing between two firms, and neither has a repository you administer. A product that does not have accounts at all, because it is a brochure, does not need this proof. A customer has already seen another customer's data — that is an incident, and the first hour is not a registration flag. The questions a later customer's security review will ask, which rows you can answer from the product and which must stay no, are your first security questionnaire. Do not borrow that spreadsheet to avoid the three proofs. The spreadsheet assumes the door is already yours.

What the three proofs look like when a product actually has roles is ordinary and visible. Gigbase, a multi-tenant workspace, had to put subscription plans and role-based access for agencies, admins, and team members in one product, with an admin who can train the knowledge assistant. A founder running tonight's test can create one user, refuse a second, and remove the first, without anyone narrating the screens. Nothing in that description is a headcount, a duration, or a result figure. The shape is the point: if signup is on, those controls are things you can touch.

On the night you are tempted to paste the URL into a group chat, do the three proofs before you paste it. Close registration and watch the public form refuse. Receive one message on a domain you administer, and find the bounce. Create one account and erase it until the row, the session, and the file are gone. Then open the door. A startup software development company that expects this will have put the switch, the sending domain, and the delete path in your accounts before the form existed, because the proofs take them nothing they were not already operating. One that needs a call in order for you to close signup is telling you who holds the change. If the first public slice is a fixed capability rather than an open-ended launch, an AI integration sprint is the shape where the acceptance sentence can include these three proofs before the URL is shared. The criteria for choosing who builds that form sit on the page written for a top saas development company. That page is criteria, and it does not rank anyone, including us.