Your users' passwords and the Privacy Act: what APP 11 expects

Every app with a login form holds a small database of secrets that many of its customers also use elsewhere. Under Australian privacy law that store is personal information, and the security principle that covers it, APP 11, was sharpened by amendments that took effect on 11 December 2024. This post covers what the law says, what changed, and the technical steps a current standard treats as the baseline.

This is general information, not legal advice. It reflects the Privacy Act 1988 as compiled on 4 June 2026. Whether a step is "reasonable" for your business depends on your circumstances, so check with a lawyer.

Are passwords personal information?

Section 6(1) of the Privacy Act 1988 defines personal information as "information or an opinion about an identified individual, or an individual who is reasonably identifiable", whether or not it is true and whether or not it is recorded. A password on its own may not identify anyone, but a hash stored next to an email address or customer number is information about that account holder, and it unlocks everything else the account shows. Our view is that you should treat the whole credential store, including hashes, reset tokens, MFA secrets and session records, as personal information protected by APP 11.

What APP 11 requires

APP 11.1 says that an APP entity holding personal information "must take such steps as are reasonable in the circumstances to protect the information" from misuse, interference and loss, and from unauthorised access, modification or disclosure (Privacy Act, Schedule 1).

The law does not list controls. The OAIC's APP guidelines, chapter 11 say what is reasonable depends on factors including the entity's size and resources, the amount and sensitivity of the information, the possible harm from a breach, and the practical cost of a measure. The same chapter gives "strong passwords" as an example of a technical measure.

What changed with the 2024 amendments

The Privacy and Other Legislation Amendment Act 2024 received Royal Assent on 10 December 2024. Its section 2 sets the commencement dates, and most of Schedule 1 commenced on 11 December 2024. The OAIC gives the same date for most amendments within its remit. Four changes matter for credentials.

• APP 11.3. Schedule 1, Part 5 added: "For the purposes of subclauses 11.1 and 11.2, without limiting those subclauses or any other provision of this Act, such steps include technical and organisational measures." It applies to information held after commencement, whenever it was collected.
• Three penalty tiers. Schedule 1, Part 8 amended section 13G (serious interference with privacy), adding a list of factors a court may consider, including whether the entity "failed to take steps to implement practices, procedures and systems" to comply. It added section 13H, a civil penalty for an interference with privacy that need not be serious, and section 13K, a lower tier for breaches of specified principles. These apply to acts and practices after they commenced on 11 December 2024.
• Infringement notices. Section 80UB makes section 13K contraventions subject to infringement notices. Section 13K(1) lists principles such as APP 1.3, 1.4, 2.1, 6.5, parts of APP 7 and APP 13.5. APP 11 is not on that list, although regulations can add others. Section 13K(2) also covers a data breach statement that leaves out required content.
• A statutory tort. Schedule 2 of the amending Act created a cause of action for serious invasions of privacy, which commenced on 10 June 2025 (OAIC). It is now Schedule 2 of the Privacy Act.

The penalty figures

Under section 13G(3) of the Privacy Act, the maximum for a body corporate is the greatest of $50 million, three times the benefit obtained from the contravention, or, if the benefit cannot be determined, 30% of adjusted turnover in the breach turnover period. For a person other than a body corporate it is $2.5 million. Section 13H sets the mid tier at 2,000 penalty units and section 13K the lowest at 200. Under section 82(5) of the Regulatory Powers Act a court can order up to five times those amounts against a body corporate, so 10,000 and 1,000 penalty units. A Commonwealth penalty unit is $364 from 1 July 2026 under the Crimes (Amount of a Penalty Unit) Instrument 2026; it was $330 before that under section 4AA of the Crimes Act 1914. The instrument says the new amount applies to offences committed on or after 1 July 2026, so ask your lawyer which value applies to a civil penalty for your conduct. These are maximums a court can order, not typical outcomes.

Where the law is unsettled

The tort needs an invasion of privacy, by intrusion upon seclusion or misuse of information, that was "intentional or reckless" and serious (Schedule 2, clause 7). On its face, carelessness alone is not enough. Whether a security failure could ever be found reckless, and so fall within the tort, is a question the courts have yet to settle, so treat it as open rather than ruled out.

Reasonable steps for credentials

The OAIC does not adopt a particular technical standard. A practical yardstick is NIST SP 800-63B-4, Digital Identity Guidelines: Authentication and Authenticator Management, published in July 2025 and superseding the previous revision. It is a US federal guideline, not Australian law, but it is specific and current. Section numbers are from the online version.

• Slow, salted hashing. Passwords "SHALL be salted and hashed using a suitable password hashing scheme", with a salt of at least 32 bits (a SHALL), and a cost factor that SHOULD be "as high as practical" and raised over time (Sec. 3.1.1.2). NIST points to its SP 800-132 for approved schemes. The OWASP Password Storage Cheat Sheet recommends Argon2id first, then scrypt, with bcrypt for legacy systems (note its 72-byte input limit) and PBKDF2 where FIPS-140 compliance is needed.
• Length over complexity. At least 15 characters for a password used on its own and at least 8 when it is part of MFA. No composition rules, no forced periodic changes, but a forced change on evidence of compromise. Allow password managers (Sec. 3.1.1.2). The OAIC's 2018 Guide to securing personal information still asks about complexity rules and lockouts, so be ready to explain why you follow the newer NIST position.
• Breached-password screening. Check new passwords against a blocklist of "commonly used, expected, or compromised" values, which may include passwords from previous breach corpuses (Sec. 3.1.1.2).
• Rate limiting. Limit consecutive failed attempts on one account to no more than 100 (Sec. 3.2.2). You can set a lower threshold, and add limits per IP address or network.
• MFA. NIST's AAL2 requires two distinct authentication factors, and verifiers must offer at least one phishing-resistant option at that level (Sec. 2.2).
• No account enumeration. NIST does not address this directly. The OWASP Authentication Cheat Sheet recommends the same response for an unknown user and a wrong password, a reset message that does not confirm the address exists, and consistent response times.
• Session handling. At AAL2, set an overall reauthentication timeout that should be no more than 24 hours and an inactivity timeout that should be no more than 1 hour (Sec. 2.2). Session cookies must be HTTPS-only, should be HttpOnly and SameSite Lax or Strict, and must not contain cleartext personal information (Sec. 5).

Credential stuffing and the NDB scheme

The OAIC describes credential stuffing as "attackers trying out usernames and passwords obtained from other data breaches on an entity's digital services" (NDB scheme 12-month insights report).

Under section 26WE of the Privacy Act, unauthorised access to personal information is an eligible data breach if "a reasonable person would conclude that the access or disclosure would be likely to result in serious harm" to any affected individual. If you only suspect an eligible breach, section 26WH requires "a reasonable and expeditious assessment" and all reasonable steps to complete it within 30 days. Once you have reasonable grounds to believe one has occurred, sections 26WK and 26WL require a statement to the Commissioner and notification of individuals as soon as practicable. Whether a stuffing attack crosses the line depends on what the accounts expose, so log logins well enough to tell which accounts were entered.

APP 8 when your auth provider is offshore

APP 8.1 requires reasonable steps to ensure an overseas recipient does not breach the APPs before you disclose personal information to it, and section 16C can make you accountable for what that recipient does (Privacy Act). The OAIC's APP guidelines, chapter 8 (paragraph 8.14) say giving information to an overseas cloud provider can be a "use" rather than a disclosure if the contract limits the provider to storing the information and ensuring you can access it, binds subcontractors, and leaves you with effective control. A hosted identity service that verifies passwords and runs its own checks may not fit that description, so read the contract and take advice.

A checklist for your login system

• Hash passwords with Argon2id (or scrypt, bcrypt or PBKDF2 where required), unique salts, and a cost factor you review each year.
• Minimum 15 characters for password-only accounts, no composition rules, no scheduled expiry, paste allowed.
• Screen new and changed passwords against a breached-password list.
• Rate limit per account and per source, and alert on spikes in failed logins.
• Offer MFA, including a phishing-resistant option, and require it for staff and administrator accounts.
• Return identical login, reset and sign-up responses whether or not the account exists.
• Set session timeouts, use Secure, HttpOnly, SameSite cookies, and revoke sessions on password change.
• Write a breach response plan naming who runs the 30-day assessment, and record where every auth component is hosted.

Where WattleDB fits

WattleDB is managed PostgreSQL from RR Sols Pty Ltd, an Australian-owned company, with the primary in Sydney and backups held cross-state in Melbourne. If you run your own login system, your users table, sessions and reset tokens can live in a WattleDB database, where connections use TLS and the database volume is encrypted at rest, as our FAQ describes. A hosted sign-up and sign-in service is in development and not available yet. Opt-in client-side encryption is coming soon and is not available yet either.