Who can actually control your business accounts?

Start with a practical question: if the person who set up your business email left tomorrow, could someone else take over? Ask the same question about your domain, accounting system and password manager. These accounts let people reset access, move money and control information the business needs.

A strong password won’t help if a former contractor is still the only administrator. Nor will it help when the recovery code is sitting in an inbox nobody can open. Ownership, permissions, authentication and recovery all need to work together.

Map the authority behind each account

For each account, record the service, tenant or organization identifier, role, resource scope, recovery method and person responsible for it. Then look at the application identities behind scheduled jobs and integrations. These often have their own credentials and access lifetimes, so removing them may require a different process from disabling a person’s login.

Take an invoicing integration that can read customer details and create payment requests. The employee who connected it may have left, but the integration’s credentials can outlive that employee’s interactive login. Your access review needs to cover both the person and the permission granted to the application.

Disabling sign-in may leave sessions running

Modern services often issue an access token for API requests and a refresh token for obtaining later access tokens. Web applications may also maintain their own session cookies. Microsoft’s Entra guidance explains that an application-issued session is controlled by that application, and that the effect of revocation depends on how access is granted and reevaluated. A single identity-provider action does not necessarily terminate every application session immediately.

Microsoft: access tokens, application sessions and revocation

Treat offboarding as a checklist you complete at each service: block new sign-ins, revoke provider sessions where supported, deprovision downstream accounts, review delegated access, and reassign or remove business integrations. Before rotating an integration’s credentials, find out which production workflow depends on them. Otherwise, an access cleanup can quietly break something the business still uses.

Check the permissions behind the role

A role label is a convenient bundle, but the real question is whether the identity can read, change, delete, delegate or administer a resource. Document sensitive permissions explicitly. An editor who can publish content does not automatically need user management; a billing contact does not automatically need a cloud administrator role.

For each privileged grant, record who approved it, its scope and a review date. Include inherited group membership and third-party access in the review. If the service supports time-limited administration, use it where it fits the business workflow. Keep emergency access tightly controlled and exercise the documented recovery path without removing the last working administrator.

Leave a record someone else can use

A short entry can carry a lot of useful information: “Finance workspace; operations owns the account; two named administrators; phishing-resistant MFA required; recovery material in the restricted vault; integration owner assigned; access reviewed September 8.” Include a reference to the credentials, never the secret values themselves. Another authorized person should be able to find the controls and understand why access was granted.

Pay particular attention to new administrators, changed MFA methods, recovery-contact changes and new application grants. Each changes who can get in or what they can do. Match those events to approved work before treating them as suspicious, and investigate the ones nobody can explain.

Start with five critical services

• Business email: who can create accounts, reset passwords, and review security alerts?

• Domain registration: who controls the address customers use to find you?

• Password manager: how do authorized people obtain access and recover it?

• File storage: who can share, delete, and restore business information?

• Accounting and payments: who can approve a transaction or change payment details?

For each service, record its owner, administrators, approved recovery route, and the location of its security settings. Keep this inventory private. Reference the credential’s location in your password manager; do not copy passwords into the inventory.

Give each person the access their work needs

Use individual accounts where the provider supports them. Separate everyday work from administration where practical, and give administrative privileges only to people who need them. When someone changes roles or leaves, review their access across all five services.

The owner is accountable for the account; everyone else still needs their own login. Decide how another authorized person would take over through the provider’s emergency-access or recovery process, and make sure that process is usable before you need it.

Protect the sign-in and the way back in

Enable multifactor authentication, prioritizing email and administrator accounts. Prefer phishing-resistant options such as supported passkeys or security keys. Check the provider’s guidance: different authentication and recovery options offer different protections.

Check the recovery contacts as carefully as the administrators. A former employee’s personal inbox or phone should not be the company’s only way back in. Store backup codes under restricted access, and keep a working authorized administrator session available during any planned recovery exercise.

Read next: MFA and passkeys — choose a stronger way to sign in

Sources & further reading

NIST: Multi-factor authentication for small businesses

NIST: Cybersecurity Framework 2.0 Small Business Quick-Start Guide

Technical review: September 8, 2026. This is Short Circuit LLC’s original guidance, with primary sources linked beside the relevant explanations. Examples are illustrative.