Questions are ordered from the purpose of a password and authentication policy through credential strength, password managers, MFA, reset and rotation rules, reuse, privileged and non-human credentials, secure storage and recovery, and the gaps most likely to leave a New Zealand SME exposed.
What is a password and authentication policy, and why does a New Zealand business need one?
A password and authentication policy sets the organisation's rules for creating, storing, using, changing and recovering credentials and for applying multi-factor authentication and verification to important systems and processes. It should cover employees, directors, contractors, customers where relevant, administrators, shared business accounts, service accounts, API keys, tokens, recovery codes and default credentials. New Zealand law does not prescribe one universal document with this exact title for every private business. The legal outcome is nevertheless relevant: Privacy Act 2020 IPP 5 requires safeguards reasonable in the circumstances against unauthorised access, use, modification, disclosure and other misuse of personal information. NCSC's current Critical Controls identify enforced MFA and verification as the most critical control for preventing unauthorised access and require organisations to provide a usable password manager. Own Your Online also recommends a business-wide password policy that is shared with users who access organisational systems. The policy should be practical, technically enforceable where possible and connected to access control, incident response, offboarding and supplier management.
- all authorised users — Use individually attributable credentials, approved password-management tools, MFA and prompt incident reporting.
- administrators and privileged users — Apply separate accounts, stronger MFA, protected recovery, enhanced logging and stricter credential handling.
- service accounts and applications — Treat passwords, API keys, tokens and certificates as managed organisational secrets with named owners and limited access.
- policy outcome — Credentials remain long, unique, protected and difficult to misuse, and a stolen password alone is not enough to access critical systems.
All organisational accounts and systems must use authentication controls proportionate to their sensitivity, exposure and privilege. Passwords and passphrases must be long and unique, stored only in approved systems and never shared informally. The organisation provides an approved password manager and enforces multi-factor authentication for in-scope accounts. Credential creation, reset, recovery, compromise, privileged use, service accounts and offboarding must follow the controls in this policy.
What makes a strong credential: length, passphrases or complexity?
Length and uniqueness matter more than forcing people to satisfy complicated composition rules. NCSC guidance recommends long, strong and unique credentials and gives at least 15 characters as a practical benchmark. Own Your Online recommends a passphrase of four or more words and says this can be stronger and easier to remember than a shorter password built around letters, numbers and symbols. For credentials people must remember, use a long passphrase made from unrelated words and avoid names, dates, quotations, keyboard patterns and other personal or predictable material. For credentials generated and stored by a password manager, use a long random value. Systems should permit spaces and a broad character set, support long maximum lengths and avoid rules that encourage predictable substitutions such as replacing an 'a' with '@'. Complexity may still be required by a particular legacy system, contract or government control, but it should not be treated as a substitute for sufficient length, uniqueness and MFA.
- memorable human credential — Use a long passphrase of at least four unrelated words and avoid personal or predictable content.
- generated credential — Use a long random password generated and stored by the approved password manager.
- system configuration — Permit long credentials and passphrases rather than forcing short, difficult-to-remember composition patterns.
- legacy or contract-constrained system — Meet the binding requirement while documenting limitations and adding MFA or other compensating controls where possible.
Passwords must be long and unique. User-created credentials must contain at least 15 characters or use a passphrase of four or more unrelated words, unless a system imposes a stronger minimum. Personal information, common phrases, keyboard patterns and predictable variations must not be used. Password-manager-generated credentials should be random and as long as the service supports. Complexity rules must not be used as a substitute for length, uniqueness and multi-factor authentication.
How should the business provide and govern password managers?
The organisation should provide an approved password manager rather than expecting staff to remember many unique credentials or keep informal lists. NCSC says password managers encrypt, store and protect passwords, generate random unique credentials and can securely hold items such as PINs and MFA recovery codes. Select a product through a security and privacy assessment covering provider reputation, encryption design, independent assurance, administrator controls, export and recovery, supported devices, business continuity and the handling of organisational data. Require a long, unique master passphrase and MFA for the vault, especially where it is cloud based or stores sensitive credentials. NCSC also warns that reset functions can be abused to bypass authentication and recommends avoiding master-password reset without MFA. Shared business credentials should be shared through controlled vault permissions rather than copied into email, chat or documents. Trial the chosen tool with users, provide training and maintain an emergency-access and offboarding process.
- individual vault — Store each user's unique work credentials and approved secure notes under a strong master passphrase and MFA.
- shared organisational vault — Grant role-based access to shared credentials without revealing or distributing them through insecure channels.
- administration and recovery — Control enrolment, recovery, emergency access, audit logs, export, termination and provider continuity.
- password-manager user — Use the approved tool, protect the master credential, report unexpected prompts and never export vault data without approval.
The organisation provides and requires an approved password manager for work credentials. The vault must be protected by a long, unique master passphrase and multi-factor authentication. Passwords, recovery codes and shared credentials must be stored and shared through approved vault functions, not email, chat, spreadsheets, tickets or unprotected documents. Password-manager access, recovery, emergency access, export and offboarding must be centrally governed and logged where the product supports it.
Where should MFA and independent verification be mandatory?
MFA should be enforced rather than merely offered on critical and high-risk systems. NCSC prioritises administrative and internet-facing accounts and systems holding sensitive data, financial information or critical business functions. This normally includes email, remote access, cloud administration, finance and payroll, password managers, source-code repositories, infrastructure platforms, social media, domain and DNS administration and systems holding customer or employee information. Administrators should not be exempt. Prefer phishing-resistant methods such as hardware security keys, passkeys or device-bound authenticators where supported, especially for privileged and remote access. Authentication is not the only issue: NCSC also requires independent verification of sensitive process requests, including password resets, MFA-method changes, payment-detail changes and important data changes. Verification should use a second trusted channel and contact details already held, not details supplied in the request.
- mandatory MFA — Administrator, internet-facing, remote-access, email, password-manager, financial and sensitive-data accounts.
- preferred MFA method — Use phishing-resistant hardware, passkey or device-bound methods where supported; retain weaker methods only where necessary.
- sensitive process verification — Independently verify credential resets, recovery changes, payments, bank details and high-risk data changes.
- administrator and support personnel — Do not exempt privileged users from MFA and apply enhanced recovery and logging controls.
Multi-factor authentication is mandatory for administrator and privileged accounts, internet-facing and remote-access services, email, the password manager, finance and payroll, cloud administration, source-code and infrastructure platforms, social-media and domain administration, and systems holding sensitive or personal information. Phishing-resistant MFA must be used where supported for privileged and remote access. Password resets, MFA changes, recovery changes, payment-detail changes and other sensitive requests require independent verification through a separate trusted channel.
Should passwords expire or be rotated on a fixed schedule?
Do not force routine periodic password changes merely because a fixed number of days has passed where modern MFA and other controls are operating. NCSC's current response guidance recommends removing mandatory periodic password changes unless there is evidence of compromise and favouring longer passphrases over complexity rules. Forced expiry often encourages predictable changes, weaker credentials and password reuse. Require an immediate credential change when compromise is known or reasonably suspected, a password appears in a breach, an account has been accessed without authority, a shared credential holder leaves, a default or temporary credential remains in use, or a system or contract specifically requires a change. Reset associated sessions, tokens, recovery methods and connected secrets where exposure may extend beyond the password. For legacy systems without MFA or environments subject to binding government, sector or contractual controls, a periodic-change rule may still apply and should be documented as an exception to the general policy.
- normal user password — No routine expiry where the credential remains unique, uncompromised and protected by appropriate MFA.
- breach-driven reset — Change immediately after known or suspected exposure and revoke active sessions, tokens and recovery paths as needed.
- shared or temporary credential — Change when a holder leaves, access changes, a temporary credential is issued or secrecy can no longer be assured.
- regulated or legacy environment — Apply any binding periodic requirement while documenting why it differs from the organisation's normal rule.
Passwords must not be changed solely because a routine calendar interval has elapsed, unless a binding system, government, sector or contractual requirement applies. A credential must be changed immediately when compromise is known or suspected, it appears in a breach, unauthorised access occurs, a shared user no longer requires access, a temporary or default credential remains active, or the credential's secrecy cannot be assured. Related sessions, tokens, recovery methods and dependent secrets must also be reviewed and revoked or replaced where necessary.
How should the policy prevent password reuse, sharing and weak or breached credentials?
Every account should have a different credential. Reuse allows one breach to compromise multiple business and personal services and makes credential-stuffing attacks effective. The organisation should configure systems to reject weak and common passwords and, where the platform supports it, known-compromised passwords. Own Your Online explicitly recommends rules that stop systems accepting weak or common passwords. Users must not share personal credentials, send passwords through email or chat, or store them in notebooks, spreadsheets, browser notes, tickets or documents. Where several people need to manage a business account, provide individual delegated access or share the credential through the approved password manager with audit and revocation controls. If a shared or generic account is technically unavoidable, document its owner and users, protect it with MFA where supported, monitor its use and change the credential whenever a holder leaves or no longer needs access.
- unique credential — Use one password or passphrase for one account only, with no variations derived from another account's credential.
- password screening — Reject weak, common and, where supported, known-compromised credentials at creation and reset.
- shared business access — Prefer individual delegated access; otherwise use controlled password-manager sharing, MFA, logging and prompt revocation.
- user responsibility — Never disclose a personal credential or approve an unexpected MFA prompt, and report suspected exposure immediately.
A password or passphrase must be unique to one account and must not be reused or adapted across work or personal services. Systems must reject weak and common passwords and should block known-compromised credentials where the capability exists. Personal credentials must never be shared. Business accounts requiring multiple users must use individual delegated access or approved password-manager sharing. Any technically unavoidable shared account requires a named owner, approved users, MFA where supported, logging and an immediate credential change when access membership changes.
How should administrator, privileged, service-account and API credentials be controlled?
Privileged credentials require stronger controls because their compromise can affect entire systems or datasets. Administrators should use separate named accounts for elevated and routine activity, enforce phishing-resistant MFA where supported and avoid using privileged accounts for email or ordinary web browsing. Service accounts, application passwords, API keys, access tokens, certificates and automation secrets should be inventoried, assigned business and technical owners, limited to the minimum permissions and systems required and disabled when no longer needed. Use a managed secrets vault or platform-native secret store rather than source code, scripts, documents, tickets or ordinary chat. Generate long random secrets, prohibit reuse between services and rotate them when compromise is suspected, an authorised holder leaves, a supplier relationship changes or the underlying platform requires it. NCSC incident guidance specifically calls for resetting service-account and administrative credentials associated with compromised hosts and restricting service-account movement across the network.
- named administrator — Use a separate privileged identity with strong MFA, enhanced logging and no routine browsing or email.
- service or machine account — Assign named owners, a defined purpose, non-interactive use where practical, least privilege and lifecycle review.
- API key, token or certificate — Treat as a credential, store in an approved secrets system, restrict scope and replace after exposure or ownership change.
- emergency credential — Protect in a controlled vault, restrict access, monitor use and review immediately after activation.
Privileged users must use separate named administrative and routine accounts. Privileged accounts require multi-factor authentication and enhanced logging and must not be used for routine email or web browsing. Service accounts, API keys, tokens, certificates and automation credentials must be inventoried, have named business and technical owners, use least privilege and be stored only in an approved secrets vault or platform secret store. Secrets must not be embedded in source code, scripts, tickets, email, chat or unprotected documents and must be replaced after suspected exposure or material ownership and access changes.
How should passwords be stored, transmitted and securely reset or recovered?
Passwords should not be recoverable by staff from ordinary business records or transmitted in plain text. Users should store credentials only in the approved password manager, while application owners should use a reputable managed identity service or an appropriate one-way password-verification design rather than storing plaintext or reversibly encrypted user passwords. Reset and recovery are high-risk authentication processes and must not become an easier bypass than the normal login. Verify the person's identity using approved information and, for privileged or sensitive accounts, a separate trusted channel. Do not rely solely on knowledge-based questions built from personal information. Temporary credentials should be unique, short-lived, communicated through a protected channel and replaced on first use. MFA recovery codes must be protected like passwords. Following suspected compromise, revoke active sessions and tokens as well as changing the password. Log reset requests, verification, administrator action, MFA-method changes and recovery events without recording the secret itself.
- user credential storage — Use the approved encrypted password manager and never store passwords in email, tickets, documents or informal lists.
- application password storage — Use managed identity or appropriate one-way verification; never retain plaintext or expose passwords to support staff.
- reset and recovery — Verify identity independently, protect temporary credentials, log the process and review active sessions and MFA methods.
- recovery material — Protect backup codes, recovery keys and emergency access with controls equivalent to the primary credential.
Passwords and authentication secrets must not be stored or transmitted in plain text or placed in email, chat, tickets, spreadsheets, source code or unprotected documents. Users must use the approved password manager. Systems must use an approved identity service or secure one-way password-verification method and must not expose a user's password to administrators or support staff. Reset and recovery require proportionate identity verification, with a separate trusted channel for privileged or sensitive accounts. Temporary credentials must be unique, short-lived and changed on first use. Recovery codes, sessions and tokens must be protected and revoked when compromise is suspected.
What are the common gaps in New Zealand SME password and authentication practice?
Common gaps include short passwords hidden behind complicated composition rules; reusing one password or small variations across services; forcing frequent changes that lead to predictable patterns; offering MFA but not enforcing it; exempting administrators; relying on SMS when stronger methods are readily available; using personal or unmanaged password managers; sharing passwords through email, chat or spreadsheets; leaving default credentials active; allowing weak or common passwords; using personal information in passwords or recovery questions; resets performed without independent verification; active sessions left open after a reset; administrator accounts used for normal work; service accounts and API keys with no owner, expiry or review; secrets embedded in source code; and no response to known credential exposure. Another gap is copying Australian Essential Eight, SMB1001 or ASD ISM requirements into a New Zealand policy as though they were New Zealand law. New Zealand businesses should base the policy on IPP 5, NCSC Critical Controls and Own Your Online, with NZISM used only where government scope, adoption or contract makes it relevant.
- credential-quality gap — Short, reused, predictable or common credentials remain accepted despite stronger length and screening options.
- MFA and recovery gap — MFA is optional, administrators are exempt or reset and recovery processes bypass the stronger login control.
- secret-management gap — Shared, privileged, service and API credentials are unowned, copied into ordinary tools or not replaced after exposure.
- governance gap — The organisation has no enforceable standard, coverage register, logs, training, breach response or exception process.
The organisation must not rely on short complex passwords, routine forced expiry, optional MFA or informal credential sharing as its authentication strategy. Long unique credentials, an approved password manager, enforced MFA, secure recovery, common-password screening, breach-driven resets and controlled privileged and service credentials are mandatory within the scope defined by this policy. Default and exposed credentials must be replaced promptly. Australian cyber frameworks must not be described as New Zealand law or official New Zealand baselines.
What's my next step?
Common misconceptions
- A short password becomes strong if it includes enough capitals, numbers and symbols. Current NCSC guidance favours sufficient length, uniqueness and longer passphrases over complexity rules. VERIFIED
- Every password should expire every 30, 60 or 90 days. NCSC recommends removing mandatory periodic changes unless there is evidence of compromise, subject to any binding exception. VERIFIED
- MFA makes password quality irrelevant. NCSC says a long, strong and unique password or passphrase remains important even when MFA is in place. VERIFIED
- SMS-based 2FA is worthless. Own Your Online says other methods are preferable where available, but SMS is still safer than having no 2FA. VERIFIED
- A password manager creates more risk than it removes. NCSC identifies providing a password manager as one of its ten Critical Controls and says it enables strong, unique credentials. VERIFIED
- Shared passwords are acceptable in a small team. NCSC recommends individual access, controlled sharing and changing unavoidable shared credentials when authorised users change. VERIFIED
- Administrators can be exempted from MFA because they are trusted. NCSC specifically says not to exclude administrators from MFA requirements. VERIFIED
- Changing a compromised password completes the response. Active sessions, tokens, recovery methods, connected credentials and evidence of further access may also need review and revocation. INFERRED
- Security questions based on names, dates or personal history are reliable recovery factors. Own Your Online warns that personal information is often easy for attackers to find and should not be used in passwords. INFERRED
- Service accounts and API keys do not need the same governance as human credentials. NCSC incident guidance treats service-account credentials as important compromise and recovery targets. VERIFIED
- IPP 5 prescribes a fixed password length, rotation interval or MFA product. It requires safeguards reasonable in the circumstances rather than one universal technical configuration. VERIFIED
- Australia's Essential Eight, SMB1001 and ASD ISM are New Zealand password-policy authorities. They are not and should not be presented as New Zealand law or official New Zealand frameworks. INFERRED
Obligations at a glance
The obligations most relevant to this guide, with the regulator, the trigger and the timeframe. Follow the source links in the appendix for the authoritative wording.
| OBLIGATION | REGULATOR | TRIGGER | TIMEFRAME | PENALTY |
|---|---|---|---|---|
| Privacy Act 2020 IPP 5 reasonable authentication safeguards | Office of the Privacy Commissioner | The organisation holds personal information and uses passwords, authentication factors or recovery processes to control access. | Ongoing while the information is held and whenever systems, threats, users, suppliers or authentication capabilities change. | |
| IPP 5 safeguards for service-provider authentication | Office of the Privacy Commissioner | A service provider receives or can access personal information in connection with providing a service to the organisation. | Before access is granted and throughout the service relationship, using everything reasonably within the organisation's power to prevent unauthorised use or disclosure. | |
| Notifiable privacy breach following credential compromise | Office of the Privacy Commissioner | Compromised credentials lead to a privacy breach that has caused or is likely to cause serious harm to an affected individual. | Notify OPC and affected people as soon as practicable; OPC says notification should ideally occur within 72 hours after awareness of a notifiable breach. | Failure without reasonable excuse to notify the Commissioner is an offence punishable by a fine up to NZD 10,000. |
| Government or contract-specific authentication requirements | Relevant government agency, customer or contracting authority | A government mandate, procurement condition, system classification, tender, contract or security schedule makes specified password, MFA, privileged-access or credential-management controls binding. | As stated in the applicable mandate, contract, security schedule or system-authorisation process. | Contractual, procurement or government-assurance consequences may apply, depending on the instrument. |
| Contractual supplier password and MFA controls | Customer or contracting party entitled to enforce the agreement | A supplier, contractor or managed service provider is given access to organisational systems or information under a contract containing authentication requirements. | Before access is granted and throughout the engagement, including required changes following personnel changes, incidents or termination. | Contractual remedies, access suspension or termination may apply according to the agreement. |
Sources
- Privacy Act 2020 Principle 5 — Storage and security of information primary
- NotifyUs of a serious privacy breach primary
- NCSC Critical Controls: Summary primary
- NCSC Password managers primary
- NCSC Multi-factor authentication and verification primary
- NCSC Responding to third-party data breaches primary
- NCSC Cyber security guidance for high-profile individuals primary
- NCSC Principle of least privilege primary
- NCSC Lurking danger — lessons from an APT intrusion primary
- NCSC Cyber Threat Report 2025 — Judgement 5 primary
- NCSC Protect your organisation primary
- New Zealand Information Security Manual primary
- Own Your Online — Create a password policy for your business primary
- Own Your Online — Create good passwords primary
- Own Your Online — Keep your data safe with a password manager primary
- Own Your Online — Top tips for online security primary
- Own Your Online — Protect your business from insider threat primary
- Own Your Online — Top online security tips for your business primary
- Own Your Online — Protect yourself from unauthorised access primary
- Own Your Online — Choosing an IT service provider primary
This guide and its templates are a professionally drafted starting point, not legal advice. Your obligations depend on your industry, your contracts and your data. Have a qualified adviser review anything high stakes before you rely on it.