One experienced administrator knows the service and can help everyone else. Because that person can sign in today, it feels natural to conclude that the business controls the tenant.
Current access and recoverable control are different questions. For a material SaaS service, separately record the organizational account holder, privileged roles, identity and recovery path, removal trigger and last lawful handoff test.
Fact: framework guidance does not supply a provider recovery route
NIST publishes SP 800-53 Revision 5 and SP 800-63B. SP 800-63B includes authenticator-lifecycle context, including loss and theft events.
These framework-level, largely US-origin materials do not supply a recovery mechanism for a specific provider, determine contractual account ownership, authorize access or resolve employment and privacy questions.
Signal: present access is being treated as recoverable control
Investigate when a privileged role uses an individual address with no organizational route; departure does not reopen the tenant record; no second person can describe recovery; or contract owner and technical administrator cannot identify each other.
Counter-signals include a named service owner, mapped privileged roles, provider-specific recovery route, lawful offboarding trigger and tested handoff result. They support continuity review. They do not prove entitlement or recoverability in every event.
Action: build a tenant-control card
For each material service, record the tenant’s business purpose and dependent service; the organizational account holder as described in available vendor or contract records; each privileged role and assigned identity; the identity-provider, authenticator and recovery path without secrets; the event that removes, changes or escalates access; and the date, scope and result of the last lawful handoff or recovery test.
The card is an evidence and responsibility map, not a secret store. It should contain no passwords, recovery codes, session data or unnecessary personal information. It does not prove the provider will accept a recovery request.
The hidden variable is evidence of recoverable tenant control. The service owner identifies materiality. IT and security maintain identity facts. Human resources may trigger departure. Procurement or counsel retains account-holder evidence.
Owner Q&A
Should the card include passwords or codes?
No. Identify the governed route and responsible role. Credential storage requires a separately approved security design.
Is a second administrator enough?
Not necessarily. Two accounts may depend on the same identity route, device or unsupported recovery assumption.
What should reopen the record?
An administrator departure, owner-email change, lost authenticator, identity-provider change, vendor notice or unresolved test is a useful watch indicator.
Next verification
For one material provider, ask whether the account-holder record, privileged roles and recovery route remain usable if the current administrator becomes unavailable. Any test should follow current provider terms, local rules, security boundaries and data-handling requirements.
Limitations: the card is not proof of entitlement
This record does not prove legal ownership, contractual transfer rights, security adequacy, privacy compliance, employment authority or successful recovery. It supports no universal rule about administrator count. Provider terms, local employment limits, privacy treatment and actual recovery ability remain Not assessed.
This is general risk education, not professional or certified advice. NIST supplies bounded US institutional identity and control context; whether a comparable issue can arise for you depends on current local rules, provider terms, account records, roles, systems and evidence.