Ask most teams where their multi-factor authentication is actually enforced, and the honest answer is: on the accounts that felt important. The administrator. The billing owner. Maybe the engineer with production access. The read-only viewer — the person who can only look, and who is usually the largest group of accounts on the whole platform — gets a password and nothing else. That is the account an attacker actually wants, precisely because it is the one nobody thought was worth protecting.
We took the opposite position from the start. Every role carries multi-factor authentication (MFA), and we went looking for the places a low-trust account could still reach too far by paying to be attacked on purpose. This post covers both halves: how MFA is enforced across every role, and the more interesting lesson an adversarial penetration test taught us about least privilege.
MFA for every role, not just the corner office
The Australian Signals Directorate (ASD) Essential Eight lists multi-factor authentication as one of its baseline mitigation strategies, and it does not carve out an exception for accounts that “only read.” Neither do we. MFA is enforced for every role on the platform — from platform administrators down to read-only viewers — not just the privileged few.
That read-only viewer matters more than it looks. It is frequently the largest role by headcount and the least scrutinised, which makes it the softest target in the building. An attacker who compromises a viewer account does not get to change anything, but they do get inside: a foothold, a legitimate session, and time to look around for the next step. Leaving that role on a password alone is leaving the front door on the latch and putting the deadbolt on the safe.
To be precise about what “enforced” means here: MFA is required on the protected areas of the platform after sign-in. It is not a claim that every network request carries a second factor. The distinction matters, because a system that overreached on that promise would be one that could not let a brand-new user through the door in the first place.
What enrolment actually issues
When a user enrols, they receive two things. The first is a time-based one-time password (TOTP) authenticator — the rolling one-time code from an app on their phone, the standard second factor that does not depend on SMS or a phone number. The second is a set of single-use recovery codes, for the day the phone is lost, wiped, or left in a car at the depot.
Those recovery codes are stored only as hashes. We never keep them in plaintext. A recovery code is a password-equivalent secret — anyone holding one can complete a second factor — so it is treated like a password: put through a one-way hash, compared on use, and never legible in the database. If someone ever read the store, they would find no usable codes there, only their hashes.
The enrolment flow has to stay reachable for this to work at all. Sign-in, the enrolment path itself, and basic health checks remain open, so a first-time user can actually get their authenticator set up and the system can still report that it is alive. Everything behind those doors — the protected areas where real data lives — is what MFA gates. You can get to the desk to sign in; you cannot get past it without the second factor.
The read-only viewer is the real threat model
Bolting MFA onto administrators alone quietly assumes the danger only lives in the powerful accounts. It does not. The danger lives in whichever account an attacker can reach and then extend from. Least privilege is the discipline of making sure that a compromised low-trust account stays low-trust — that “read-only” is a wall, not a starting line.
That principle is only as strong as the code that enforces it, which is exactly the part you cannot verify by reasoning about your own system. So we stopped reasoning about it and had someone try to break it.
What an adversarial penetration test surfaced
We commissioned and ran an adversarial penetration test — an engagement where a skilled tester attacks the platform the way a real adversary would, with intent, not a checklist. This was not a certification or an accreditation, and I want to be careful not to dress it up as one. It was work we chose to pay for so that our assumptions would be tested by someone whose job was to prove them wrong.
It drove eighteen concrete fixes, spanning three areas:
- Server-side request forgery (SSRF). Closing off cases where the server could be coaxed into making requests it should never make on an attacker’s behalf — a class that the Open Web Application Security Project (OWASP) has tracked into its Top Ten precisely because it is so easy to overlook.
- Authorisation and least privilege. Tightening the paths where a low-trust role could reach further than its role should allow. This was, honestly, the category we found most instructive.
- Authentication hardening. Measures such as rate-limiting on sensitive flows, so that the authentication surface itself resists automated abuse rather than politely answering every guess.
Alongside those, we added input-allowlisting to harden queries against injection — constraining inputs to a known-good set rather than trying to enumerate every bad one. I am describing these by category deliberately. The value of a penetration test is in the fixes, not in publishing a map of which specific corners were soft before we closed them.
Least privilege was the more interesting half
The SSRF and injection work was important, but the authorisation findings were the ones that changed how we think. A path where a low-trust role reaches slightly further than intended is not a dramatic breach; it is a quiet one, and it is exactly the kind of gap that admin-only MFA does nothing to defend, because the account holding it is a legitimate, authenticated user doing something it technically could do but shouldn’t.
The rule those fixes serve is straightforward. Organisation-scoped users are isolated to their own organisation’s data — a viewer in one organisation cannot read another’s, and that boundary is enforced, not merely promised in a contract. The deliberate exception is a small number of privileged platform and auditor roles that are designed to see across organisations, because someone has to be able to operate and audit the system as a whole. The work was making sure that everyone outside that narrow, intentional exception stays firmly inside their own lane, no matter which door they try.
Rigor, not reassurance
Strong authentication and least privilege are two halves of the same posture: prove who is there, then make sure that whoever is there can only reach what they should. MFA across every role handles the first half. An adversary paid to find the gaps in the second half handles the part we could never have found by trusting our own reasoning.
This is the same instinct that runs through the rest of the platform. It is why compliance data sits on Australian-only infrastructure with encryption at rest, why the contractor right-to-work gate returns a reason with every decision rather than a silent yes or no, and why disposal and change are written to an append-only trail you can actually defend. None of it is bulletproof, and I would not trust anyone who told you their auth was. What it is, is tested — by us, on purpose, by people trying to get past it — and closed where it needed closing.