Password and passphrase policy: a practical guide for Australian businesses

Routine password expiry, complicated composition rules and password-manager choice generate the strongest operator concern. Shared credentials, service accounts and insecure storage receive less public attention but create some of the most consequential control failures.

• business with employees, contractors or outsourced IT — Cover every human and non-human credential, including vendor, service, integration, local administrator and emergency accounts.
• APP entity covered by the Privacy Act — Credential controls form part of the reasonable technical and organisational measures used to protect personal information under APP 11.
• Essential Eight or ISM-aligned organisation — Map the policy to the applicable ISM credential controls and the organisation's target Essential Eight maturity level.

Every credential used to access the organisation’s systems, applications, devices, networks, information or data must be unique, appropriately strong, protected from unauthorised disclosure and used only by the person or service to which it was assigned. Credentials must be created, issued, stored, reset, transmitted and retired through approved processes and must be changed immediately when a defined compromise event occurs.

• cloud and SaaS-heavy business — Include cloud administrators, API secrets, integration credentials, recovery codes and vendor portals, not only corporate network passwords.
• business with legacy systems — Document systems that cannot support the standard, apply compensating controls and assign each exception an owner and expiry date.
• business using a managed password vault — Define vault ownership, administrator roles, sharing controls, recovery, MFA, audit logs, offboarding and emergency access.

This policy governs password and passphrase length, prohibited and compromised credentials, uniqueness and reuse, multi-factor authentication, approved password managers, credential generation and reset, identity verification, secure delivery and storage, privileged and service accounts, shared and emergency accounts, recovery methods, monitoring, exceptions and credential changes following compromise. Technical settings must enforce these requirements wherever the system supports them.

• single-factor authentication — For non-classified, OFFICIAL: Sensitive and PROTECTED systems, the current ISM minimum is 15 characters.
• password used as part of MFA — The current ISM permits a lower formal minimum for specified classifications because the password is only one authentication factor, although organisations may adopt a stronger uniform minimum.
• system supporting generated passwords and a password manager — Use a long random generated credential rather than requiring the user to memorise four words.

A memorised passphrase must be at least 15 characters long and consist of four or more unrelated random words. It must be unique to the account and must not contain a known or compromised password, personal information, a predictable sentence, song lyric, quotation, keyboard pattern or obvious substitution. Systems must not impose arbitrary uppercase, lowercase, number and symbol composition rules unless a legacy system requires them and an approved exception records the reason.

• ordinary user credentials under the current ISM — Use compromise and exposure events rather than an arbitrary 90-day reset schedule.
• contract, regulator or legacy platform requires expiry — Comply with the binding requirement while documenting its source, scope and any usability or security risks.
• computer, service, token-signing or other machine credentials — Apply the credential-specific automated rotation or maximum-age rule rather than the user-password rule.

Ordinary user credentials will not be changed on an arbitrary 90-day schedule unless a documented law, contract, system limitation or approved risk requirement applies. A credential must be changed immediately if it is compromised, suspected of compromise, found in a breach or compromised-password source, stored or transmitted in clear text, disclosed to an unauthorised person, or affected by a change in membership of a shared account. Relevant sessions, tokens and recovery methods must also be revoked or reset.

• small business without a current password manager — Select one approved product, migrate high-value accounts first and remove passwords from browsers, documents and informal shared lists.
• team sharing supplier or platform credentials — Use named vault access, audit logs and revocation rather than revealing the underlying password where the product supports it.
• high-value or privileged vault — Require phishing-resistant MFA, separate recovery material, restricted administrators and tested emergency access.

Credentials must not be reused across different systems or accounts. Business credentials must be stored in the organisation’s approved password manager or another approved protected credential store and must not be kept in email, chat, tickets, documents, spreadsheets, browser notes or unprotected device applications. The password-manager vault must be protected by a unique strong passphrase and multi-factor authentication. Shared access must use named vault permissions wherever technically possible.

• Essential Eight Maturity Level One — Apply MFA to the online and customer services specified by the maturity model, particularly those processing sensitive data.
• Essential Eight Maturity Level Two or Three — Extend MFA to the specified privileged and unprivileged system users and meet the applicable phishing-resistance requirements.
• service supports passkeys or passwordless authentication — Use the stronger passwordless or phishing-resistant method and retain recovery controls rather than forcing a password where it is unnecessary.

Multi-factor authentication must be enabled for every system and service designated by the Access Control Policy or the organisation’s Essential Eight target. Phishing-resistant MFA must be used where supported and required by risk or framework obligations. MFA does not permit password sharing, reuse or insecure storage. Where a service supports an approved passkey or passwordless method, that method may replace a password subject to approved recovery and device-security controls.

• small business using a shared supplier or platform login — Record the owner, authorised users and business need, store it in a controlled vault and change it whenever membership changes.
• Windows service account — Use a group Managed Service Account where supported instead of a manually maintained password.
• privileged or break-glass account — Use a long random vaulted credential, strong MFA where supported, restricted access, monitoring and a tested emergency-use process.

Shared human credentials are prohibited unless technically unavoidable and expressly approved. Every approved shared account must have an owner, authorised-user register, purpose, review date and protected vault record, and its credential must change whenever authorised membership changes. Built-in administrator, break-glass, local administrator and service-account credentials must be unique, unpredictable, randomly generated, managed and at least 30 characters long. Managed service identities must be used where supported.

• organisation implementing the Essential Eight — Map password and vault controls to MFA and privileged-access implementation, while assessing all eight strategies at the selected maturity level.
• business with a formal access-control policy — Use the same account types, approvers, privileged-account definitions, offboarding events and exception process in both policies.
• business without formal framework adoption — Use ACSC and ISM guidance as a risk-based Australian baseline without representing that the business is certified or formally compliant.

This policy implements the credential requirements of the Access Control Policy and supports the organisation’s Essential Eight multi-factor authentication and restriction of administrative privileges strategies. The Access Control Policy determines who receives access and at what level; this policy determines how password-based credentials are created, protected, reset and retired. The organisation must not claim an Essential Eight maturity level based on password controls or partial MFA deployment alone.

• business migrating from informal password sharing — Inventory credentials, move them into an approved vault, identify owners and replace shared human logins with named accounts where possible.
• legacy system with short maximum passwords — Record the system as an exception, add MFA or isolation where possible and plan replacement rather than presenting the weak setting as compliant.
• software developer or system operator — Scan repositories, scripts, configuration files, tickets, documents and file shares for embedded or clear-text secrets.

Credentials must not be stored or transmitted in clear text, embedded in source code or scripts, placed in tickets, email, chat, documents or spreadsheets, or written where they are exposed. Systems must block commonly used and known compromised passwords and must support long credentials. Password resets must verify the requester’s identity. Every credential must have an identifiable owner, and exceptions must record the risk, compensating controls, approver and expiry date.

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.