Small teams rarely lose accounts because someone failed to invent a sufficiently complicated variation of the company name. They lose them because passwords are reused, access belongs to former colleagues, recovery channels are weak or a convincing phishing page captures a valid login.

The solution is not another annual reminder to “use strong passwords.” It is an authentication system that makes the safe action easier than the unsafe one.

Quick verdict: Give every person a password manager, require unique generated passwords, enable multi-factor authentication, prefer passkeys or security keys for critical accounts and review access whenever roles change.

Habit 1: sharing passwords in chat or email

A password sent through email or chat becomes another copy to protect. It may remain in search results, backups, notifications and multiple devices long after the original need has passed.

Use a team password manager that supports item or collection sharing. A person receives access without learning or copying the underlying secret into another system. When they leave the team, remove their access centrally and rotate important credentials.

Never send recovery codes through the same channel that protects the account. Store recovery information in a restricted vault and document who may use it.

Habit 2: reusing a memorable password

Password reuse turns one compromised service into a route to other accounts. The practical answer is a unique random password for every site, generated and stored by a password manager.

Current NIST authentication guidance says verifiers should allow password managers and paste functionality. It also says single-factor passwords should be at least 15 characters and rejects arbitrary composition rules such as forcing a mixture of character types. Read the exact requirements in NIST SP 800-63B.

For users, the simple rule is:

Habit 3: adding predictable variations

Changing CompanySummer2025! to CompanyAutumn2025! does not create meaningful separation between accounts. Patterns are easier to guess, share and reuse than teams realize.

Generated credentials remove the need for human creativity. If a service rejects long generated passwords, record the limitation and use the strongest unique value it accepts.

Habit 4: relying on SMS alone for important accounts

Any second factor is usually an improvement over password-only access, but methods differ in phishing resistance.

NIST states clearly that passwords are not phishing-resistant. Codes copied from SMS or an authenticator app can also be entered into a convincing fake login page. Cryptographic authenticators—such as passkeys and hardware security keys—can bind authentication to the legitimate service and provide stronger phishing resistance.

Use this priority for critical accounts when supported:

  1. passkey or hardware security key;
  2. authenticator app;
  3. SMS as a fallback when stronger methods are unavailable;
  4. password only as a temporary exception requiring remediation.

Start with email, the password manager, domain registrar, cloud storage, financial systems, source control and administrator accounts. These services can unlock many others.

Habit 5: one shared account for the whole team

Shared accounts hide accountability and make offboarding dangerous. Prefer named user accounts with the minimum permissions required.

If a service genuinely provides only one login:

Paying for the correct number of seats may cost less than recovering an account with no trustworthy access history.

Habit 6: treating recovery as an afterthought

An account can be well protected and still fail operationally if the only administrator leaves, loses a device or controls the recovery email personally.

For each critical system, record:

Recovery email accounts require equal or stronger protection than the accounts they can reset.

Habit 7: leaving old access active

Offboarding should not depend on remembering every app a person ever used. Maintain an access register and use a checklist triggered by role changes.

At minimum:

  1. Suspend the primary company identity.
  2. Remove access to the password manager.
  3. Revoke active sessions where supported.
  4. Transfer ownership of files, calendars and automations.
  5. Remove API tokens and app passwords.
  6. Rotate credentials the person could view or export.
  7. Check forwarding rules and delegated access.
  8. Confirm that recovery channels remain controlled by the company.

The same process applies when a contractor finishes a project or an employee changes role.

Habit 8: approving every unexpected login prompt

Repeated MFA prompts can be an attack, not a technical annoyance. Teach people to reject unrequested prompts and report them.

Never ask a colleague to read a one-time code aloud unless an approved support process explicitly requires it. Legitimate support staff should not need a password, passkey or recovery code.

Encourage a pause before login:

Password managers can provide a useful phishing signal because they normally fill credentials only on the stored domain.

A small-team security baseline

Every person

Every critical service

Every quarter

Introduce passkeys without creating recovery problems

Passkeys replace a shared secret with public-key cryptography. The private credential remains on an authenticator or within a synchronized credential provider, while the service stores a public key. The FIDO Alliance passkey overview explains how passkeys are designed to resist phishing and remove password reuse.

Before a team rollout, answer:

Passkeys improve authentication; they do not eliminate identity, device and recovery management.

Responding to a suspected compromise

If someone entered a password on a suspicious page:

  1. Use a known-safe device and navigate directly to the real service.
  2. Change the exposed password.
  3. Sign out other sessions.
  4. Review MFA methods and recovery settings.
  5. Check forwarding rules, connected apps and recent activity.
  6. Change reused passwords on other services immediately.
  7. Notify the designated security owner.
  8. Preserve relevant evidence and follow contractual or legal reporting requirements.

Do not wait for proof that the attacker used the credential. Treat confirmed disclosure as an incident.

Final recommendation

The strongest small-team password policy is a system, not a lecture: approved manager, unique credentials, strong MFA, named access, controlled recovery and prompt offboarding.

Start with the accounts that can reset or control everything else. Once email, password management, domains and administrators are protected, expand the same baseline across the remaining software stack.

Sources and further reading