Account Management for Small Businesses: Password Managers, MFA, SSO, and Offboarding

Account risk in a small business rarely begins with advanced technology; it begins with shared passwords, access that was never revoked, and critical accounts known by only one person. A sound identity solution makes sign-in easier for staff while letting the business know who has access and revoke it quickly.

The four problems to solve

• Scattered passwords: stored in personal browsers, spreadsheets, chats, or memory.
• Shared accounts: no reliable record of who signed in or changed data.
• Inconsistent MFA: important accounts still rely on passwords or SMS.
• Incomplete offboarding: sessions, tokens, API keys, forwarding rules, and application access remain after departure.

The goal is not to buy the most tools. It is to establish a trustworthy identity source, reduce password entry, apply strong authentication, and manage the entire access lifecycle.

A practical small-business architecture

1. Directory or identity provider: manages employee accounts and groups.
2. SSO: uses one business identity for supported applications.
3. Business password manager: stores credentials for systems without SSO and shares through vaults rather than messages.
4. MFA or passkeys: protects sign-in, prioritizing phishing-resistant methods for critical accounts.

SSO does not eliminate the password manager. Many websites, devices, infrastructure accounts, and emergency secrets do not support federation.

1. Inventory accounts before choosing tools

Record the application, business owner, administrators, login method, MFA, stored data, cost, and revocation process. Pay particular attention to:

• Accounts created with personal email addresses.
• Shared or ownerless administrator accounts.
• Auto-renewing applications with no active users.
• Long-lived API keys, SSH keys, and service accounts.
• Email aliases or forwarding outside the organization.
• Vendor accounts that can access customer data.

Rank by impact. Email and the identity provider come first because they can reset many other accounts, followed by finance, domains and DNS, cloud, source code, CRM, and backups.

2. Select a business password manager

Do not share one personal vault and its master password with a team. A business product should provide:

• Individual accounts with MFA.
• Vaults or collections by department, project, and sensitivity.
• Permissions for use, viewing, editing, and administration.
• Audit logs and weak or reused password reporting.
• Device and session revocation during offboarding.
• Controlled administrative recovery without one-person dependency.
• Export, backup, and provider-exit planning.
• Passkey, browser, and platform support that matches the organization.

NIST notes that password managers support long, random, unique passwords for every service. This concentration also makes the vault a high-value target, so use a strong master passphrase and phishing-resistant MFA where available.

3. Use a practical password policy

Do not force periodic password changes without evidence of compromise, and do not rely on rotating composition rules. Instead:

• Generate long, random, unique passwords with the manager.
• Use a long, unique passphrase for a memorized master password.
• Block common and known-compromised passwords.
• Allow paste and autofill.
• Rate-limit sign-in and alert on unusual behavior.
• Rotate immediately after compromise or a relevant employee departure.

4. Prioritize phishing-resistant MFA

MFA methods do not offer equal protection. SMS and manually entered OTP codes are better than passwords alone but can still be phished. NIST identifies WebAuthn and FIDO2 as phishing-resistant because credentials are bound to the legitimate domain.

1. Passkeys or security keys for email, identity, cloud, domain, and admin accounts.
2. TOTP authenticator apps where phishing-resistant methods are unavailable.
3. Push MFA with number matching and context when configured well.
4. SMS only as a transitional or controlled recovery method.

Administrator accounts should have two independent authenticators. Use one daily and seal the backup in a controlled location.

5. Deploy SSO where it creates value

SSO lets one central identity disable access across applications, reduces password count, and applies consistent sign-in policy. Prioritize applications with sensitive data, many users, or frequent staffing changes.

Before upgrading a plan solely for SSO, calculate subscription cost, manual provisioning time, orphan-account risk, and audit cost. A low-risk application may be adequately controlled through a password manager and offboarding checklist, while email, CRM, source code, and cloud generally justify SSO sooner.

6. Assign access through groups

Create role groups such as Finance, Sales, Engineering, and External Contractors. Assign application and vault access to groups, then place people in those groups. This reduces orphaned permissions and simplifies reviews.

Apply least privilege. Use administrator rights only when necessary and standard accounts for daily work. For critical systems, separate administrative accounts from ordinary email identities and audit permission changes.

7. Repeatable onboarding

1. The manager confirms role, start date, and required applications.
2. Create the account with a business email, never a personal address.
3. Add standard access groups instead of granting ad hoc permissions.
4. Register at least two suitable recovery methods.
5. Train on the password manager, MFA, phishing, and lost-device reporting.
6. Replace temporary secrets and verify sign-in.
7. Record approver, time, and granted access.

8. Same-day offboarding

1. Disable identity and email accounts and revoke sessions.
2. Recover devices, security keys, VPN profiles, and certificates.
3. Remove access to groups, vaults, repositories, cloud, and finance tools.
4. Transfer ownership of files, calendars, automations, dashboards, and advertising accounts.
5. Rotate shared passwords, API keys, SSH keys, and webhooks the person could access.
6. Inspect forwarding rules, OAuth grants, and personal access tokens.
7. Retain and delete data according to legal policy.
8. Record completion evidence and the person responsible.

Changing an email password does not revoke every form of access. Sessions, OAuth tokens, API keys, and SSH keys have separate lifecycles.

9. Emergency access and recovery

Create at least two break-glass accounts for critical identity or cloud platforms. Do not use them daily or tie them to one employee's email. Protect them with separate security keys and alert on every sign-in.

Store encrypted recovery codes plus a controlled offline copy. Quarterly, verify that emergency accounts work, backup credentials remain available, and authorized users are still correct. An overly easy recovery path can bypass MFA.

10. Service accounts and machine secrets

Do not run automation under employee accounts. Each service account needs a purpose, owner, minimum permissions, review or expiration date, and secrets in a secret manager or CI/CD vault rather than source code.

Prefer workload identity or short-lived credentials over long-lived API keys where supported. Track last use to find abandoned secrets and rotate according to risk, not merely a calendar.

11. Review access regularly

Each quarter, have managers and application owners confirm access lists. Focus on administrators, inactive accounts, transfers, expired contractors, and applications without owners. Reviews must result in actual revocation, not only a signed report.

Track simple measures: MFA coverage, phishing-resistant coverage, administrator count, offboarding time, ownerless accounts, and secrets overdue for review.

A 30-day rollout

1. Week 1: inventory applications, administrators, shared accounts, and risk.
2. Week 2: deploy the password manager, build group vaults, and enable MFA.
3. Week 3: connect SSO for critical applications and standardize permission groups.
4. Week 4: test onboarding and offboarding, validate break-glass access, and close gaps.

Start with email, identity, domains, cloud, and finance. Do not wait for a perfect inventory before protecting accounts that can reset or take over the wider environment.

Acceptance checklist

1. Every employee has an individual identity; personal accounts are not shared.
2. The business password manager uses group vaults and audit logs.
3. Email, identity, cloud, and domain accounts use phishing-resistant MFA where supported.
4. Access is assigned through groups with an approving owner.
5. Onboarding and offboarding have checklists, service levels, and evidence.
6. Session, OAuth token, API key, and SSH key revocation is in scope.
7. Two tested recovery or break-glass paths exist.
8. Service accounts do not depend on employee identities.
9. Access is reviewed at least quarterly.

Conclusion

Effective account management is not just a password manager or an MFA switch. It is a complete lifecycle from provisioning and use through review and revocation. For a small business, a directory, selective SSO, group vaults, and phishing-resistant authentication provide strong protection while keeping operations manageable.

References

• NIST SP 800-63B-4: Authentication and Authenticator Management
• NIST: Authenticator Requirements
• NIST Digital Identity Guidelines FAQ