Because the signup creates an access path outside normal provisioning, approval, and offboarding workflows. That means the organisation may have an active account that was never fully reviewed, classified, or tied to policy. The risk is not just the app, but the unmanaged identity lifecycle behind it.
Why browser-based SaaS signups are an IAM problem, not just an app onboarding problem
Browser-first signup paths bypass the controls IAM teams usually rely on to make identity trustworthy. A user can create an account before provisioning, approval, entitlement design, or offboarding logic is fully in place, which means the organisation inherits an identity it may not have deliberately issued, reviewed, or classified.
That matters because the control failure is not limited to one SaaS app. Once a browser-based signup succeeds, the resulting account can become a standing access path with its own authentication state, recovery options, and lifecycle obligations. For IAM, the risk is that the system now contains an identity asset that exists outside the normal governance model.
The practical issue is ownership. If the signup flow is self-service, federated loosely, or tied to a shadow admin process, no one may clearly own review, recertification, privilege reduction, or revocation. That is why browser-based SaaS signups often surface as identity governance gaps before they show up as a visible security incident.
Where unmanaged signup creates the most identity exposure
Signup risk usually shows up in four places: classification, privilege, lifecycle, and visibility. If the account is created before the business purpose is recorded, the team cannot easily tell whether it should exist at all. If the app assigns default roles, the account may start with more access than intended. If the account is never reconciled with joiner-mover-leaver processes, it can outlive the need that created it.
Browser signup also tends to fragment evidence. An IAM team may know that a login exists, but not whether it was created by a human request, an automation flow, or a delegated business owner. That gap complicates access reviews, because the team cannot confidently answer who approved it, why it exists, or when it should be removed.
When SaaS onboarding is paired with external identity federation, the risk can become broader rather than smaller. A federated login may reduce password management, but it does not automatically solve entitlements, conditional access, or account retirement. For that reason, browser signup should be treated as an identity lifecycle event, not just an authentication event. NHIMG’s NHI Lifecycle Management Guide and Lifecycle Processes for Managing NHIs both reinforce the same core control pattern: if something can create durable access, it must also be governable across its full lifecycle.
What IAM teams should do before browser signup becomes shadow access
The right response is to decide which SaaS signups are truly self-service and which must be gated by policy. Not every signup needs a ticket, but every signup should have an ownership model, a review rule, and a revocation path. If a system creates accounts outside the directory or onboarding process, the IAM team should verify whether that account can still be discovered, classified, and disabled centrally.
Practically, the team should verify three things first: whether the signup is tied to a trusted identity source, whether the resulting account is mapped to a business owner or access policy, and whether offboarding will actually remove access instead of merely disabling one login method. If any of those are missing, the app is not just onboarding users, it is creating unmanaged identity debt.
Another important judgement is whether the SaaS app is allowed to assign meaningful access on first use. If the answer is yes, then the signup path needs stronger controls than a normal marketing or product funnel. In that case, Identity Security Programme Guide and Identity Security Posture Management (ISPM) Guide are useful navigation points because they frame signup as part of a broader identity control environment, not a one-off app event.
Risk and Threat Considerations
Browser-based signup creates a weak point where access can be established before governance catches up. That becomes risky when accounts are duplicated, orphaned, over-permissioned, or left active after the original business need has ended. It also creates an attractive path for abuse when attackers can self-register, take over dormant accounts, or blend into normal user creation patterns.
Failure mechanism: the organisation loses control over identity proofing, ownership, and deprovisioning, so an account can persist with legitimate-looking access but without reliable review or lifecycle enforcement.
Impact: the SaaS account can become a foothold for data access, privilege accumulation, lateral movement, or policy bypass, especially when downstream integrations trust that identity more than the onboarding process did.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Browser signups create user identities that still need authenticated access control. |
| IA-5 — Authenticator Management | Signup paths often create unmanaged credentials, recovery, and lifecycle risk. | |
| AC-2 — Account Management | The core issue is unmanaged account creation, review, and deprovisioning. | |
| Recommendation — Require centrally managed authentication before allowing SaaS access. Control credential issuance, rotation, and revocation for browser-created accounts. Enforce account approval, ownership, review, and timely removal. | ||
| NIST CSF 2.0 | PR.AA-05 — Manage Identity and Access Credentials | The signup flow changes how identities and credentials enter the environment. |
| GV.RM-01 — Risk Management Strategy | Browser signup is a governance and risk decision about tolerated identity exposure. | |
| Recommendation — Manage identity creation and credentials through approved onboarding paths. Set risk tolerance for self-service SaaS signup and exceptions. | ||
Practitioner Guidance
What to prioritise: Start with any SaaS that allows users to create accounts before IT or IAM sees the request. Those are the systems most likely to hide unmanaged access, because the identity exists first and the governance conversation happens later.
What to verify: Confirm that each browser-created account has a business owner, a policy basis, and a removal path. If you cannot produce evidence for those three items, treat the account as an exception that needs remediation, not as a routine signup.
Common mistake: teams often focus on whether the signup uses SSO or federation and assume that solves the risk. It does not, because federated authentication can still leave you with uncontrolled account creation, weak entitlement assignment, and poor offboarding.
Practitioner takeaway: The IAM question is not whether browser signup is convenient, it is whether the organisation can still prove who owns the resulting identity, what it may access, and how it will be removed.