Guide

Password & MFA Policy Template

How to write a password and MFA policy for a small business — the rules to set, the outdated ones to drop, and how to enforce them across a team.

By SecureBusinessHub Editorial, International cybersecurity desk — · 9 min read

A password and MFA policy is the written document that sets your company's rules for account security: how strong passwords must be, that everyone uses a password manager, and that multi-factor authentication is switched on for anything that matters. It is a short policy with an outsized effect, because weak, reused, and unprotected credentials remain the most common way small businesses get breached. This guide is about the policy document itself — the clauses it should contain, the rules worth setting, and the outdated ones to leave out — rather than the day-to-day craft of choosing good passwords, which we cover separately.

If what you want is practical advice on creating and managing strong credentials as an individual, read our companion guide to password habits for remote teams. This document sits one level up from that: it is the rule your business adopts and enforces, one of the four foundation documents in the small business security policy framework, and a close partner to your acceptable use policy, which references these rules without spelling them out.

Why a written password policy still matters

It is tempting to assume that password rules are so obvious they do not need writing down. They do — for the same reason any policy does. A written rule sets a shared, enforceable standard, turns "we assume people use good passwords" into "we require it and can show that we do," and gives you a clean answer to the account-security questions that insurers and client questionnaires always ask. Underwriters in particular now expect multi-factor authentication as a baseline; a documented policy that requires it is often the difference between being covered on reasonable terms and being loaded with a higher premium or declined.

There is also a human reason. Most credential mistakes are not defiance; they are the path of least resistance. People reuse one memorable password across a dozen sites because remembering twelve is impossible without help. A policy that simply says "use strong passwords" fights human nature and loses. A policy that requires a password manager gives people the tool that makes the rule effortless — and that combination, rule plus tool, is what actually changes behaviour across a whole team.

What a password and MFA policy covers

Keep the policy focused. It should cover how credentials are created, stored, and protected, and how access is granted and removed. A small-business version does not need pages of cryptographic detail; it needs a handful of clear, enforceable rules that everyone can follow. The core areas are credential strength, credential storage, multi-factor authentication, and account lifecycle — what happens when someone joins, changes role, or leaves.

  • Credential strength — the minimum standard for any password protecting a company account.
  • Password storage — the requirement to use the company password manager rather than memory, browsers, or a notebook.
  • Multi-factor authentication — where it is mandatory and which forms are acceptable.
  • Account lifecycle — how accounts are created with the right access, reviewed, and promptly disabled when someone leaves.
  • Shared and service accounts — the narrow, controlled exceptions for accounts that cannot belong to one person.

The rules your policy should set

Modern guidance from bodies such as NIST has shifted, and a good policy reflects it. Length beats complexity: require a reasonable minimum length — 14 characters is a sensible floor — rather than a tangle of mandatory symbols that people satisfy with predictable substitutions. Require that every account has a unique password, and make that requirement realistic by mandating a password manager so nobody has to remember them. Screen new passwords against known-breached lists where your tools allow it, because a password's real weakness is not its shape but whether it has already leaked.

Set clear rules for storage and sharing. Passwords live in the approved password manager, not in browsers on personal devices, not in spreadsheets, and not on paper by the monitor. Credentials are never shared over email or chat; where two people genuinely need the same account, that access is granted through the password manager's sharing feature, which can be revoked cleanly when someone leaves. Spell out the joiner-mover-leaver process too: accounts are created with the minimum access the role needs, reviewed when roles change, and disabled the same day someone departs.

Multi-factor authentication rules

Multi-factor authentication is the highest-value clause in the whole policy, so make it unambiguous. State plainly that MFA is required on every account that supports it — email above all, then any system holding company or customer data, financial tools, and administrative accounts. Where you can, express a preference for stronger factors: an authenticator app or a hardware security key rather than SMS codes, which can be intercepted. You do not have to ban SMS outright, but a policy that nudges people toward app-based or hardware factors ages far better than one that treats all second factors as equal.

Cover the practical edges so the rule survives contact with reality. Say how backup codes are stored, what someone does when they lose a device, and who they contact to regain access — because an MFA policy with no recovery path just teaches people to turn MFA off. If your team is large enough to face push-based prompt fatigue, note the expectation that unexpected prompts are denied and reported, not approved to make them stop. These small clauses are what turn MFA from a good idea into a rule that holds.

What to leave out of your policy

Some traditional password rules now do more harm than good, and a modern policy is as much about what it does not require. Do not mandate frequent scheduled password changes; forced rotation pushes people toward weak, incremental passwords like Spring2026, then Summer2026, and the modern advice is to change a password only when there is a reason to believe it has been compromised. Drop rigid composition rules that demand a specific mix of character types, which mostly generate predictable patterns and frustration. And avoid arbitrary maximum lengths or bans on password managers pasting into fields — both actively undermine security. A shorter policy that requires length, uniqueness, a manager, and MFA protects you better than a long one full of rules that quietly train people to game them.

Adopting and enforcing the policy

The password policy is easier to enforce than most, because much of it can be enforced by configuration rather than trust. Turn on MFA requirements in your identity provider, set the password manager as company-standard and roll it out to everyone, and configure minimum-length and breach-screening rules where your systems support them. Then adopt the written policy the same way as any other: explain it, have staff acknowledge it, fold it into onboarding, and keep a dated record. The combination of a written rule and a technical control that backs it up is what makes this policy stick where a document alone would not.

Rolling out a password manager

The password manager is the clause that makes every other rule in this policy realistic, so its rollout deserves a little thought rather than a link dropped in a group chat. Choose one company-standard tool and provide it to everyone, rather than letting each person pick their own — a single tool means you can share credentials safely, revoke access cleanly when someone leaves, and support people when they get stuck. Explain, when you introduce it, that the goal is to make their working life easier, not harder: they will need to remember one strong passphrase instead of a dozen weak passwords, and the tool will fill in logins for them. That framing turns a security mandate into a genuine convenience, which is what drives adoption.

Plan for the migration period. People arrive with passwords reused across dozens of sites, and the manager will often flag exactly that. Rather than demand everyone fix everything overnight, ask staff to move their work accounts into the manager first, then work through reused and weak passwords over a few weeks, prioritising the accounts that matter most — email, financial tools, and anything holding customer data. A staged rollout that people can keep up with beats a big-bang mandate that overwhelms them and quietly gets abandoned.

Consider a short scenario the policy is meant to prevent. An employee reuses one password across their personal shopping accounts and their work email. Months later, an unrelated shopping site is breached and their email and password appear on a list attackers buy and test against thousands of services — a technique called credential stuffing. Because the same password guards the work email, and because MFA was never switched on, the attacker walks straight in and begins reading invoices and impersonating the employee to redirect a client payment. Every link in that chain is broken by this one policy: a unique password from the manager means the leaked credential does not match, and MFA means a leaked password alone is not enough to log in. That is the entire case for the policy in a single, unremarkable example.

Shared and service accounts

Every small business eventually hits accounts that cannot cleanly belong to one person: a shared social media login, a generic support inbox, or a service account that software uses to run automated tasks. These are the awkward exceptions your policy should address rather than pretend do not exist, because they are where good credential hygiene quietly breaks down. The rule for shared human accounts is simple in principle: avoid them where you can by using a tool's built-in team features instead, and where you genuinely cannot, keep the credential in the company password manager and share it through the manager rather than by email or a note, so access can be granted and revoked without changing the password every time someone leaves.

Service accounts — the non-human logins that connect systems together — need their own short clause. They should have long, randomly generated credentials stored in the manager, the narrowest access their job requires, and an owner who is responsible for rotating the credential if it is ever exposed. Because a person is not typing them in, service-account passwords can be far stronger than anything a human would tolerate, and they should be. Documenting who owns each one also means that when an employee leaves, you can tell which automated logins they set up and need to be reassigned, rather than discovering a critical integration was tied to a departed person's personal setup only when it breaks.

Where the password and MFA policy fits

This policy is one of the four foundations described in our small business security policy guide, and it works hand in hand with your acceptable use policy, which points to these rules for the detail. For the practical side — how to actually choose, generate, and manage strong credentials day to day — see our guide to password habits for remote teams. And if you would rather start from a professionally structured document, our editable policy template pack includes a password and MFA policy written for small businesses, ready to adapt to the tools and identity provider you already use.