Going passwordless for Xero, MYOB, and the rest of your cloud apps

Last week we wrote about going passwordless on Microsoft 365 itself: the laptop sign-in, the Outlook sign-in, the SharePoint sign-in. The web apps that aren’t Microsoft are a separate problem. The dozen or more your staff also log into every day. Xero. MYOB. The supplier portal. The freight tracker. The cyber insurance broker’s site. The shared Woolworths account someone set up four years ago for office grocery deliveries. Every one of those has its own password.

Most cybersecurity advice tells staff how to handle those passwords properly. Pick a strong one. Don’t share it. Don’t reuse it. Don’t write it down. Humans don’t follow that advice. They never have. They never will.

The fix is the same shape as the Microsoft one: take the password out of the user’s hands. Microsoft 365 Business Premium includes the tool to do it, called password-based single sign-on. It works on almost any web app you sign into with a username and a password.

How it works

We set up a tile for each web app inside a portal called My Apps, at https://myapps.microsoft.com. For each app, we enter the username and the password. The user never sees either.

The user signs in to Windows with their fingerprint, opens the My Apps portal in their browser, and clicks the Xero tile. A Microsoft browser extension fills in the username and password automatically. Xero opens. The user has never seen the password and couldn’t tell you what it is.

What looks like single sign-on is really managed password injection: a credential we set, stored encrypted by Microsoft, retrieved by the browser extension only when the user clicks. Microsoft’s password-based SSO architecture overview and configuration guide cover it in technical depth.

What this changes

• Staff can’t share what they don’t know. A bookkeeper handing over to a colleague can’t pass on the Xero password. The colleague gets their own access, granted by us and revoked the same way.
• Staff can’t reuse the password across apps. They never had it.
• Staff can’t be phished into typing it. A fake Xero login page is harmless to a user who has never typed the real one.
• Sticky notes and “Password1!” stop appearing.
• Offboarding is one click. Disable the user’s Microsoft account, and every web app they had access to closes with it. No more “I think they had a Xero login, did anyone tell Sarah to remove it?” three weeks after someone left.
• The audit trail improves. Microsoft logs every sign-in via My Apps, paired with the app’s own log. We can see who opened which app, when, and from where, against a real person.

What it doesn’t do

Password-based single sign-on is a managed password vault. It is not phishing-resistant authentication.

• It doesn’t bypass the app’s own MFA. If Xero asks the user for a six-digit code from an authenticator app, the user still has to enter it. The second factor stays in place.
• It only works in a web browser. Mobile apps, desktop apps, and anything that talks to the app via an API don’t go through it.
• It doesn’t protect a compromised laptop. The 2024-25 ASD report flagged info-stealer malware as a growing threat. Malware that can read a browser session can read the password as the extension injects it. Endpoint protection and a managed, patched device remain the baseline.
• Login pages can change shape. If Xero changes the HTML on its login form, the auto-fill might break and need re-tuning. We watch for it.
• A malicious browser extension can also snoop on credentials. We control which extensions are installable on managed devices to keep that surface small.

But compare this to how your bookkeeper is possibly doing this today. The Xero password in their head, on a sticky note next to the monitor, in a shared spreadsheet called passwords.xlsx on the file server, and probably reused at their bank. Removing those failure modes is a much larger win than the residual malware risk, which can be mitigated using other controls.

When this fits, and when it doesn’t

The pattern we use across managed clients:

• Real Microsoft sign-in if the app supports it. Look for “Sign in with Microsoft” on the login page. The password disappears on both sides.
• Password-based single sign-on via My Apps for the long tail. The supplier portal, the timesheet system, the niche industry tool, the legacy app the business has been using since 2014.
• Independent authentication for the high-stakes apps. Banking. The major financial platforms (Xero, MYOB, the like) where the app’s own MFA is the actual fraud control. Anywhere you specifically want a second human moment of “yes, I am authorising this transaction.” For these, the user has their own password and their own MFA on the app.

If losing access to the account would directly move money or breach a regulator, keep the user in the loop. For everything else, take the password out of their hands.

What Microsoft Defender for Cloud Apps adds

Microsoft Defender for Cloud Apps is a separate Microsoft product, not included in Business Premium, that adds visibility across the whole cloud-app landscape. It flags staff signing in to apps the business doesn’t sanction, detects anomalous behaviour like a sign-in from two countries an hour apart, and applies session-level controls on the apps it supports.

It doesn’t make password-based single sign-on any safer. It makes the rest of the cloud-app landscape visible. Worth considering once a business is on Business Premium, the Microsoft passwordless rollout is done, and the next question is “what apps are staff using that we don’t know about?”

How it pairs with the Microsoft 365 passwordless rollout

Together, the two changes mean a staff member’s working day looks like this:

• Sign in to the laptop with a fingerprint. No password.
• Open Microsoft 365 without typing anything.
• Open the My Apps portal to reach every other web app the business uses. Click any tile, no password typed.
• Pick up the phone. The same identity is available there via the passkey, no SMS code.
• Day one for a new starter: receive the laptop, scan a QR code, fingerprint the laptop, work. Every app the role needs is already in the portal.
• Day last for a leaver: disable the account in one place. Every Microsoft and cloud-app login closes at the same instant.

Across a normal working day, a staff member might never type a password.

The phishing surface for the business shrinks to “the laptop itself” and “the user falling for a fake Microsoft prompt.” Both are much harder for an attacker than sending a fake Xero login email to the bookkeeper. The credential-theft economy described in the 2024-25 ASD report, where stolen usernames and passwords are sold by the million on the dark web, has nothing left to buy that works against your business.

What we’re advising every managed client

• Inventory the cloud apps your staff sign into. Most businesses underestimate this list by half. The list is the prerequisite for everything below.
• For each app, decide one of three. Real Microsoft sign-in if the app supports it. Password-based single sign-on via My Apps for the long tail. Independent authentication with the user’s own MFA for the small number of high-stakes apps where you want a second human moment.
• Move the long tail through My Apps. A few weeks of admin work for the apps, a few minutes per user to register the browser extension.
• Lock down browser extensions on managed devices. Only the Microsoft sign-in extension installed by default; new ones require admin approval.
• Tell staff that typing a password into a work app means something has bypassed the system, and they should let IT know.

If you’re a managed client, your account lead will bring this up at the next review. If you’d rather move sooner, get in touch.

After both rollouts, no one in the business is carrying work passwords in their head, on sticky notes, in shared spreadsheets, or in browser auto-fill. The credential-theft attack surface stops at the managed laptop. The licence to do it is already in your Microsoft 365 Business Premium subscription. What’s missing is the decision to actually use it.