Should organisations disable open signup and automatic membership for some customer workspaces?

Yes, when access must be controlled by invitation or verified policy rather than open registration. Disabling signup is appropriate for closed betas, sensitive customer environments, and contractor-heavy workspaces. Turning off automatic membership is also useful when domain-matched users should not join without approval, especially where SSO or explicit invites define the access boundary.

Why This Matters for Security Teams

Open signup and automatic membership are not just product convenience settings. They define the boundary between a public service and a controlled customer environment. If that boundary is too loose, access decisions drift from explicit approval to implicit trust, which is exactly where tenant sprawl, data exposure, and privilege creep begin. NHI Management Group’s research shows that only 5.7% of organisations have full visibility into their service accounts, a reminder that identity growth is often faster than governance. The same pattern appears in customer workspaces when join rules are left to default behaviour rather than policy.

This matters because workspace membership often determines who can see data, create integrations, manage secrets, and invite others. A small mistake in signup logic can become a large operational issue when contractors, subsidiaries, or trial users are mixed into the same environment. NIST SP 800-53 Rev. 5 Security and Privacy Controls treats access control as a core security function, and that principle applies here even when the “users” are customers rather than employees. In practice, many security teams encounter unauthorized workspace access only after a customer reports unexpected membership, rather than through intentional governance.

How It Works in Practice

The practical decision is whether workspace entry should be policy-driven access control or self-service access by default. For closed or sensitive workspaces, organisations typically disable open signup, require invitation-only onboarding, and use explicit approval for membership changes. This is especially important where SSO establishes the access boundary, because authenticated identity does not automatically mean authorised tenancy.

Automatic membership based on email domain matching can be useful, but only when the domain is a reliable proxy for trust and the business has accepted that anyone in that domain may join. In practice, that assumption often fails with contractors, acquired subsidiaries, reseller relationships, and shared domains used across multiple business units. The safer pattern is to separate authentication from authorisation: verify identity through SSO, then evaluate whether the user is entitled to join that specific workspace.

Common controls include:

• Invitation-only signup for sensitive or early-stage workspaces.
• Admin approval for domain-matched users before tenancy is granted.
• Role assignment after join, not during self-registration.
• Periodic review of dormant, external, and contractor memberships.
• Logging of joins, invites, and membership changes for audit and incident response.

Where workspace membership can also grant access to integrations, API keys, or embedded secrets, the issue becomes an NHI problem as well as a human access problem. The Hugging Face Spaces breach is a useful reminder that workspace boundaries and exposed credentials often fail together, not separately. These controls tend to break down when customer self-service, reseller administration, and contractor onboarding are all handled in the same tenant because the approval path becomes ambiguous.

Common Variations and Edge Cases

Tighter signup controls often increase onboarding friction, requiring organisations to balance user experience against tenant security. That tradeoff is real, especially for SaaS products that depend on rapid trial conversion or community-led adoption. The right answer is not always to block all self-service, but to scope it carefully.

There is no universal standard for this yet, but current guidance suggests three common variants. First, public workspaces may allow open signup with limited permissions until an admin upgrades access. Second, enterprise customer workspaces usually benefit from invitation-only entry plus SSO enforcement. Third, partner or contractor-heavy environments often need explicit approval even when the email domain matches, because domain trust does not equal business trust.

Another edge case is automation. If account creation is tied to procurement, SCIM, or HR-driven provisioning, automatic membership may be acceptable only when the upstream system is authoritative and the join is still constrained by policy. The key is to avoid treating convenience rules as security controls. Organisations should also watch for inherited access, shared workspaces, and guest accounts that bypass the normal approval flow. The Ultimate Guide to NHIs is especially relevant here because workspace access often extends to service accounts, API keys, and other non-human identities once a user is inside.

In practice, automatic membership works best in low-risk, low-data environments, and it becomes brittle where legal, contractual, or secret-bearing data must be segmented by customer.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?
• Should organisations prioritise external exposure or internal credential governance first?