Free Password and MFA Policy Template and Generator

This policy sets the rules for how [Company Name] (the "company") protects the passwords, passkeys, and other credentials that control access to its systems and information, and when and how multi-factor authentication (MFA) is required. Stolen, guessed, and reused passwords are among the most common ways attackers get into a business, and a small number of consistent rules closes most of that risk.

Our approach. The policy follows current NIST guidance in SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025). That means long passphrases instead of short, complex passwords; a password manager instead of memorizing dozens of passwords; password changes driven by evidence of compromise rather than a fixed calendar; and MFA on every account worth attacking, with phishing-resistant MFA where the stakes are highest.

The policy is designed to help the company meet its legal, regulatory, contractual, and cyber insurance obligations. It does not replace them. Where a law, regulation, contract, or insurance policy sets a stricter requirement, the stricter requirement applies.

People. This policy applies to all employees, officers, temporary workers, interns, contractors, consultants, outside IT providers, and anyone else who has an account on [Company Name] systems or signs in to any service on behalf of the company ("personnel").

Accounts and systems. It covers every credential used for company business, on any device and from any location, including:

• User accounts on company systems, whether on premises, in the cloud, or provided as a service.
• Administrator, service, shared, and emergency access accounts.
• Passwords, PINs, passkeys, security keys, authenticator apps, API keys, and access tokens.
• Built-in and default credentials on network equipment, servers, printers, cameras, building systems, and machine controllers.
• Accounts the company holds with third parties, such as banks, payroll and benefits providers, suppliers, customer portals, domain registrars, and social media.
• Personal devices used to sign in to company accounts or to approve MFA prompts for them.

Customer-facing accounts. Accounts that customers or the public use on company websites and portals are governed by the security requirements for those systems. IT should apply the same length, blocklist, and MFA principles to them wherever practical.

Password

A secret that a person memorizes or stores to prove who they are when signing in. In this policy, "password" includes passphrases.

Passphrase

A password made of several words, such as four unrelated words, which is long and hard to guess but easy to remember and type.

Password manager

An application that generates, stores, and fills in passwords and passkeys in an encrypted vault protected by one master password and MFA.

Multi-factor authentication (MFA)

Sign-in that requires at least two different kinds of proof: something you know (a password or PIN), something you have (a phone, security key, or smart card), or something you are (a fingerprint or face).

Authenticator

Anything used to prove identity at sign-in, such as a password, an authenticator app, a security key, or a passkey.

Phishing-resistant MFA

MFA that cannot be relayed through a fake sign-in page because the authenticator checks which website is asking, such as FIDO2 security keys, passkeys, and certificate-based smart cards.

Passkey

A FIDO2 credential stored on a device, security key, or password manager that replaces a password with a cryptographic key unlocked by a PIN, fingerprint, or face.

Number matching

An authenticator app setting that requires the user to type a number shown on the sign-in screen before a push prompt can be approved.

MFA fatigue (push bombing)

An attack in which someone who already has a password sends repeated MFA prompts until the user approves one by mistake or to make them stop.

Privileged account

An account that can change systems, security settings, or other accounts, such as a domain, cloud, firewall, backup, or application administrator.

Service account

An account used by software, a scheduled task, or an integration rather than by a person.

Shared account

An account whose credentials are known to or used by more than one person.

Blocklist

A list of passwords that must not be used because they are common, predictable, or known to have been exposed in a breach.

Credential stuffing

An attack that tries user names and passwords stolen from one website against many other services, succeeding wherever a password has been reused.

Emergency access account

A highly protected administrator account kept for use only when normal administrator sign-in is unavailable. Also called a break-glass account.

Accountability. Each person is responsible for activity performed with their credentials. Sharing a password or approving someone else's sign-in does not transfer that responsibility.

These rules apply to every password a person chooses for a company account. IT enforces them technically wherever the system allows. Where a system cannot enforce them, personnel must still follow them, and IT configures the strongest settings the system supports.

Choosing a good password. Use a passphrase of four or more random, unrelated words, ideally generated by the password manager. Avoid song lyrics, famous quotes, sports teams, keyboard patterns, seasons and years, and anything someone could learn from social media. Passwords that nobody needs to type, such as website logins stored in the password manager, should be random and at least 20 characters long.

When passwords change. Passwords are not changed on a fixed schedule, because forced periodic changes lead to weaker, predictable passwords. A password must be changed immediately when:

• There is any sign that it has been stolen, guessed, or seen by someone else.
• It appears in a breach notice or a credential exposure alert.
• It was typed into a suspicious website or shared by mistake.
• It was a temporary password issued by IT.
• IT or the policy owner requires a change, for example after a security incident.

Default passwords. Every device and application must have its default or vendor-supplied password changed before it is connected to the company network or put into service. This includes routers, firewalls, switches, wireless access points, printers, cameras, and building systems. Replacement passwords follow this policy and are stored in the password manager.

Required use. All personnel must store company passwords in the company-approved password manager, using a company-managed account. The password manager should generate a unique, random password for every account that does not need to be typed by hand, so the only password a person needs to remember is the master password.

Protecting the vault. The master password must be a unique passphrase of at least 15 characters that is used nowhere else. The vault must be protected with MFA, and administrators must use phishing-resistant MFA for it. The vault must lock automatically after a period of inactivity set by IT, and lost master passwords are recovered only through the account recovery process that IT has set up for the company account, never by writing the master password down.

Sharing credentials. Passwords must never be shared by email, text message, chat, phone call, or on paper. When a credential legitimately must be available to more than one person, it is shared through a shared folder in the password manager, limited to the people who need it, so that access can be tracked and removed. Never share your own personal sign-in with anyone, including a manager or IT staff. IT will never ask for your password.

Where passwords must never be stored. Company passwords and other secrets must not be stored in:

• Plain-text files, spreadsheets, documents, notes apps, or email drafts.
• Sticky notes, notebooks, whiteboards, or anywhere else on paper.
• Web browser password storage, including browser sync, because saved browser passwords are a primary target of infostealer malware.
• Personal password managers or any personal account.
• Scripts, source code, configuration files, or shared drives. Credentials used by software belong in the password manager or an approved secrets manager.
• Chat messages, email, text messages, or tickets, even temporarily.

Company and personal vaults. Items in the company vault belong to the company and stay with it when a person leaves. Keep personal passwords out of the company vault, and keep company passwords out of personal vaults.

MFA is required for every company account on the following systems:

• Email and collaboration tools, including webmail and mobile mail apps.
• Remote access, including VPN, remote desktop gateways, and remote support and remote management tools.
• Every administrator and other privileged account, on premises and in the cloud.
• Cloud and software-as-a-service applications that hold company, customer, or employee information.
• Online banking, payment platforms, payroll, accounting, and any other system that can move money or change payment details.
• Business systems such as ERP, CRM, human resources, and file sharing, including when they are reached from inside the office.
• Backup systems, backup consoles, and backup storage accounts.
• Domain registrar, DNS, website hosting, and company social media accounts.
• Every other company system and third-party service that supports MFA.

Legacy sign-in and conditional access. IT must turn off legacy sign-in methods that cannot enforce MFA, such as basic authentication for email, and should use conditional access to require MFA again for risky sign-ins, new devices, unusual locations, and sensitive actions such as changing MFA methods or payment details.

Registering MFA. Personnel register MFA when their account is created and should register a backup method, such as a second security key or a second approved device, so that a lost phone does not lock them out. MFA methods may be added or removed only by the account holder after signing in with MFA, or by IT after verifying identity as described in this policy.

Personal phones. Personnel may install the company-approved authenticator app on a personal phone. Installing the app alone does not give the company control of the phone or access to personal data on it. Anyone who does not want to use a personal phone will be given a hardware security key or another company-provided method instead, at no cost to them.

Phishing-resistant MFA. Phishing-resistant MFA, such as a FIDO2 security key or a passkey, is required for administrator and other privileged accounts and people who can move money, approve payments, or change banking and payment details. It is encouraged for everyone else.

Passkeys. Synced passkeys stored in the company-approved password manager or a company-managed platform account are acceptable for standard accounts. Administrator accounts should use device-bound passkeys or hardware security keys that cannot be copied to another device.

MFA fatigue and push bombing. Push-based authenticator apps must have number matching turned on. Personnel must never approve an MFA prompt, enter a code, or touch a security key for a sign-in they did not start themselves, and must report any unexpected prompt immediately, because it means someone else has their password. Never read an MFA code or approval number to anyone, including a caller who claims to be from IT. IT will never ask for it.

Gaps. Where a group that requires phishing-resistant MFA uses a system that cannot yet support it, IT records the gap, applies number matching or the strongest method available, and revisits the gap at each policy review.

Administrator accounts. Administrators use a separate privileged account for administrative work and a standard account for email, web browsing, and everyday work. Privileged accounts must never be used to read email or browse the web, must not have a mailbox where the system allows, and are granted only the rights the role needs.

Local administrator passwords. Standard users do not have administrator rights on their own computers. The built-in local administrator password on every computer and server must be unique and randomly generated, managed by a tool such as Windows LAPS, so that one stolen password cannot unlock every machine.

Service accounts and secrets. Service accounts, API keys, and tokens used by software and integrations must have a named owner and only the access they need, must be blocked from interactive sign-in where the system allows, and should use managed identities or certificates instead of passwords where possible. Where a password is needed, it must be random and at least 30 characters long and stored in the password manager or an approved secrets manager. Service credentials must be changed when someone who knew them leaves, when they may have been exposed, and at least once a year where the system cannot use a managed identity. The no-scheduled-change rule for personal passwords does not apply to service credentials.

Shared accounts. Shared accounts are not allowed except where a system cannot support individual accounts, or where a third-party service issues only one login to the company. Each shared account must be approved by IT, recorded with a named owner, stored in the password manager with access limited to the people who need it, protected with MFA where the system supports it, and changed whenever someone with access leaves or no longer needs it. Shared accounts must never be used for administration.

Emergency access accounts. IT keeps two emergency access accounts for the company identity system for use only when normal administrator sign-in is unavailable. They use long random passwords and phishing-resistant MFA, such as hardware security keys, stored in a sealed or dual-control location known to IT and the Chief Executive Officer. They are not tied to any one person or phone, every use triggers an alert and is reviewed, and they are tested at least once a year.

Outside IT providers and vendors. Outside IT providers, software vendors, and contractors with access to company systems must use individual named accounts protected by MFA, never shared or generic vendor logins. Those with administrative access follow the same rules as company administrators. Access is limited to what the work needs and is removed when the work ends, and remote support tools must require MFA and be approved by IT.

Failed sign-ins. Systems must lock the account, or block further attempts, after no more than 10 consecutive failed sign-in attempts, for at least 30 minutes or until IT verifies the person's identity. Identity platforms may instead use adaptive lockout that blocks the attacker without locking out the real user, provided it is at least as effective. Internet-facing sign-in pages should also slow down or challenge repeated attempts and block known malicious sources.

Monitoring. IT monitors sign-in activity and is alerted to at least the following:

• Sign-ins from unusual locations, impossible travel, or anonymizing services.
• Bursts of failed sign-ins or MFA prompts.
• New MFA methods registered, or MFA removed, on any account.
• New privileged role assignments and changes to security settings.
• Sign-ins by disabled accounts or by former personnel.
• Any use of an emergency access account.

Sign-in and audit logs are kept long enough to investigate an incident, and for at least 12 months where the system allows. When an account shows signs of compromise, IT resets the password, revokes all active sessions and tokens, reviews the MFA methods registered, and checks mailbox rules and recent activity for misuse.

Credential exposure. IT monitors for company email addresses and credentials that appear in public data breaches and in infostealer logs, using a breach monitoring service. When a company credential is found, IT forces a password change, revokes active sessions, and checks for misuse.

New accounts. Accounts are created only after a documented request from human resources or the person's manager, with only the access the role needs. Initial and temporary passwords must be random, delivered separately from the user name through a secure channel, expire if unused within 72 hours, and be changed at first sign-in. MFA is registered during the first sign-in, in person or on a verified video call with IT wherever possible.

Password and MFA resets. Before resetting a password, adding or removing an MFA method, or unlocking an account, IT and any outside help desk must verify the person's identity with a method an attacker cannot easily fake, such as calling back on the phone number already on file, confirming with the person's manager through a known contact method, a verified video call, or an in-person check. Knowing personal details, such as a birth date, employee ID, or the last digits of a Social Security number, is not enough. Resets of administrator and financial system accounts should be approved by a second person, and the account holder is notified whenever a password or MFA method changes.

Role changes. When a person changes roles, access and shared password manager folders that the new role does not need are removed, and shared credentials the person no longer needs are changed.

Departures. When a person leaves, IT must disable all of their accounts no later than 4 hours after separation, and at or before the time of notice for an involuntary separation. IT also revokes active sessions, removes MFA methods and security keys, removes access to shared vault folders, transfers company items in their password manager vault, and collects company devices and security keys. Every shared, service, or vendor credential the person knew or could access must be changed promptly.

Access reviews. IT reviews privileged, shared, service, and vendor accounts at least every three months and all other accounts at least once a year, and disables accounts that have not been used for 45 days unless their owner documents a reason to keep them.

Stricter requirements win. Where a law, regulation, contract, customer security requirement, or insurance policy sets a stricter password or MFA requirement than this policy, the stricter requirement applies to the systems and data it covers.

Cyber insurance and customer questionnaires. Cyber insurance applications and customer security questionnaires commonly ask whether MFA is enforced for email, remote access, and administrator accounts, and whether privileged accounts are separated. An inaccurate answer can put coverage or a contract at risk. Before anyone answers such a question, IT confirms the actual configuration, and the IT Manager reviews the answer.

Personal information. Accounts that can reach personal information about employees, customers, or others are protected under this policy as part of the reasonable security that privacy and data breach notification laws expect, including those of North Carolina and of every state where the affected individuals live. A compromised account with access to personal information is treated as a possible data breach.

Standards. This policy is designed to align with:

• NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management (July 2025).
• CISA fact sheets, Implementing Phishing-Resistant MFA and Implementing Number Matching in MFA Applications.

Related company policies. This policy works together with the [Company Name] information security, acceptable use, remote work, and incident response policies, where adopted. If they conflict, the stricter requirement applies.

Report immediately. Personnel must report any of the following to the IT Manager immediately. Report even if you are unsure, and even if you made a mistake. Good-faith reports are welcome and no one will face retaliation for making one.

• An MFA prompt, code, or security key request you did not start.
• You typed a password or approved a sign-in on a page or in response to a message that now looks suspicious.
• You shared a password or MFA code with anyone, or someone asked you to.
• A lost or stolen phone, computer, or security key used for company sign-in.
• A breach notice, exposure alert, or password reset email you did not request.
• Sign-in alerts, unfamiliar activity, or changed settings on your account.

What to do right away. If you can do so safely from a device you trust:

1. Deny any unexpected MFA prompt. Do not approve it to make it stop.
2. Change the affected password in the password manager, and change it anywhere else it was used.
3. Report it using the contact above, and say what happened and when.
4. Do not delete the suspicious message, and do not turn off or wipe a device unless IT tells you to.

Response. IT treats a suspected credential compromise as a security incident under the company incident response procedures: it resets credentials, revokes sessions, reviews activity, and involves legal counsel where information covered by a breach notification law or contract may have been accessed.

All personnel complete password and MFA training before or when they receive their company account, and again at least once a year. Training covers:

• This policy, and how to set up and use the company password manager and MFA.
• How to build a strong passphrase, and why password reuse is dangerous.
• Recognizing phishing pages, fake sign-in prompts, and MFA fatigue attacks.
• Social engineering by phone, text, and video, including callers who claim to be IT.
• How and when to report a suspected compromise.

Role-based training. Administrators, help desk staff, and people with access to financial systems receive additional training on privileged account rules, identity verification before resets, and payment fraud. Training completion is recorded, and realistic phishing simulations should be run during the year.

Compliance checks. IT enforces this policy through technical settings wherever possible. At least once a year, IT reports to the IT Manager and the Chief Executive Officer on MFA coverage, accounts without MFA, privileged and shared accounts, stale accounts, and open exceptions. The IT Manager may review any account or setting to confirm compliance.

Exceptions. A system or account that cannot meet this policy needs a written exception requested through the IT Manager, explaining the business need, the risk, and the compensating controls, such as a longer password, network restrictions, or added monitoring. The IT Manager may approve exceptions. Exceptions for administrator accounts, financial systems, or regulated data also require approval by the Chief Executive Officer. Every exception is recorded, lasts no more than 12 months, and is reviewed before renewal. No exception can permit a practice that breaks a law, regulation, or contract.

Enforcement. Violations of this policy may result in loss of access and disciplinary action, up to and including termination of employment or of a contractor agreement, consistent with applicable law. Prompt self-reporting of a mistake is taken into account.

Policy review. The IT Manager reviews this policy no later than September 27, 2027, and sooner after a significant account compromise, a change to NIST guidance or to a law, contract, or insurance requirement that applies to the company, or the adoption of a new identity system or MFA method.

I have read and understand the [Company Name] Password and Multi-Factor Authentication Policy. I agree to use long, unique passwords, to store company credentials only where the policy allows, never to share my password or MFA codes or approve a sign-in I did not start, and to report a suspected compromise immediately. I understand that violations may result in disciplinary action.

Revision history. Record every change to this policy below. Increase the document version and obtain approval again each time the policy is revised.

This document was generated from a starter template provided by Preferred Data Corporation. It is general information only. It is not legal advice and it is not a substitute for advice from a licensed attorney.

Preferred Data Corporation is not a law firm. It makes no representation that this document is complete, current, or suitable for any particular organization, industry, jurisdiction, or regulatory requirement, and it is not responsible or liable for any use of this template or of any policy created from it. You are solely responsible for how you adapt, adopt, and enforce it.

Laws, regulations, insurance requirements, and contracts that apply to your organization may require different or additional terms. Before you adopt, publish, or rely on this policy, and in every case where you have a legal, regulatory, or contractual obligation, have it reviewed by qualified legal counsel.