Two standards, one blind spot

If you run Microsoft 365 for a business of any decent size these days, I’d give solid odds that you have at least one critical business process that relies on a third‑party system logging in to send or read email. Maybe even to take other actions like run workflows or access documents. Think of the likes of payroll, CRM, ticketing, marketing, printers that link to your OneDrive or, heaven forbid, an AI assistant. This probably sounds grand from a security point of view; you’ve got MFA turned on, your vendors are trustworthy (complete with shiny ISO 27001 logo on their website), the integration works well and in many cases has done for years.

Look a bit closer though and you’ll find the same pattern everywhere: a third‑party app with broad, long‑lived access acting as a real user and not only sitting outside of security controls but outside of the way many standards evaluate those controls. It’s contributing to a supply chain risk that businesses either aren’t aware of or don’t have the power to fix.

In this post I’ll share my take on why this keeps happening and look at how this is viewed by two standards I know well; Cyber Essentials in the UK and the ACSC Essential Eight in Australia. Why those two? They’re accessible to organisations of any size, they have huge scale and if they were to recognise the issue they’d have the potential to introduce a lever to bring about change that I don’t think will happen soon any other way.

How we got here: Bob’s story

It’s 1999. Bob is a junior Finance Admin for a small company that sells rugs. He uses a clunky desktop app on his Windows 98 machine to run invoicing; his boss makes excuses about being too old for technology but Bob thinks he’s just got slippery shoulders; he’s not that much older after all! The routine batch print runs are always a drag and his envelope filler machine often gets stuck so he’s very excited that the app just got an update with email integration. He opens an email settings option and types his SMTP server, username and password, hits save, dials up his modem and spends a few minutes listening to the soothing beeps and whistles, then sends a test invoice to himself. ‘WOW!’ he thinks, ‘this is the future!’.

Can you believe that’s how we used to roll? Just a password in a config screen, saved in an app as plain text and never changed. It was a simpler time; generally if technology did something for us it was doing it within arm’s reach. This is what we now call ‘legacy’ authentication because it’s not safe anymore. MFA wasn’t invented back then; all we had was a password that could be guessed or brute-forced and anyone or anything that had the password was treated as the user. There’s no difference between Bob himself and his finance app when they use the same account; anything Bob can do, that app can do and any actions the app takes are logged against Bob.

It’s 2019. Bob is no longer junior anything; he’s been the Finance Manager for fifteen years. The rug business does most of their sales online, the invoicing app is a cloud platform with a monthly bill more than his first car, they’ve added a payroll app into the mix and his entire working life is within Office365. The IT guy (they have their own now, fancy that!) is on a roll after setting up MFA for everyone and has recently sent around emails about ‘modern authentication’. Bob has been ignoring them but today his invoicing platform pops up something new when he signs in. A Microsoft page with his company logo at the top; that looks reassuring. A list of things the app wants permission to do: send mail as you and access your contacts. A button that says “Accept”. Bob clicks Accept. A little message tells him it worked and he goes back to his invoicing.

What Bob doesn’t appreciate is that everything has just changed. His invoicing system is no longer storing his credentials; instead it now has a token it can use to act as him. This is OAuth, an open standard for access delegation that allows users to grant third-party applications access to their information without sharing their passwords. This is a big step forward; the app doesn’t get to have Bob’s password and it can’t do everything Bob can since he needs to grant it the ability to do specific things on his behalf (like send email) and anything that’s not on that list it doesn’t have the right to do. This is really important because Bob’s credentials don’t just unlock his email anymore; they grant access to his company’s entire information estate across multiple cloud applications.

Even with this new delegated model though, there’s still the risk that if anything ever went wrong at the invoicing company (a breach, a rogue employee, a poorly secured server) and an attacker were to grab that token they’d have access to everything the app has within the scope of the delegated access. That could still open the door to Bob’s inbox, his sent items, his ability to send a very convincing email to the accounts payable team about a change of bank details.

It’s 2026. Bob is packing up his desk. Twenty-seven years with the same company, which now sells rugs in fourteen countries and has a cybersecurity posture review every quarter. In response to one of the recent review findings, the IT team have been working with his replacement Alice to make a major change. Bob smiles at the thought that he’s now the old boss foisting the technical work he doesn’t have the mental capacity for on his underling. They’ve just finished moving the invoicing platform to a service principal. Instead of it logging in as Bob, it now has its own identity. Not a person; a dedicated machine account, created specifically for this integration, with only one job: send invoices from the invoices mailbox. It can’t read Bob’s email, or Alice’s, or access the company SharePoint, calendars, or anything else. It uses machine credentials (a digital certificate rather than a password that could be guessed or leaked). When Bob’s account is deactivated on his last day, nothing breaks. The invoices keep going out. Alice won’t get a panicked call at 7am the next payday about the payroll run. Nobody will have to hurriedly create a shared mailbox and hand a password to the vendor. Bob is satisfied. The process will outlast him, running cleanly and without his name attached to it. He picks up his leaving card and walks out the door.

Another seismic shift for third-party access has just happened. OAuth is still the engine but the gears have changed; now the integration is working autonomously, authenticating entirely independently of a user with a mechanism that is equivalent in strength to MFA but works for an always-on, internet-connected machine.

Think about what that means in comparison to where we started. In 1999, the invoicing app was Bob; same account, same password, same access to everything Bob could touch. In 2019, the app could act as Bob; a real improvement, but still borrowing his identity, his permissions and his risk profile. In 2026, the app finally gets its own identity, its own narrow set of permissions and its own credentials. Bob is no longer in the picture at all and that’s really the goal, applying the concept of least privilege to third party access.

This model also solves something that neither legacy auth nor user-based OAuth ever really helped with: accountability. When the 1999 app sent an email, the logs said Bob sent it. When the 2019 app sent an email, the logs still said Bob sent it. Now though, when the integration sends an invoice, the logs say the integration’s machine account sent it; the audit trail makes sense and that counts for a huge amount when managing an incident or dealing with an auditor. Bob is happy too by the way; nobody can ever come to him in retirement to ask why his account sent 1,800 emails to suppliers at 3am.

It’s 2026 and we’re still doing… this?

Sadly the real world is not like Bob’s neat little story arc. Most businesses have a spread of third-party integrations that vary in modernity and all too many are still partying like it’s 1999.

Microsoft hasn’t published any official stats of the usage of legacy auth today but it’s likely considerable since every time they announce its retirement, moments later they postpone it. The stats show that it’s wildly risky though; 99% of all identity attacks use passwords and 97% of password attacks use legacy auth. Trust me, you really don’t want to be using it, but the can has been kicked down the road to 2027 at the earliest and I know for a fact that every time that deadline moves, vendors breathe a sigh of relief and punt it back down to the bottom of their development priority list.

Even where vendors have moved to OAuth, it’s not all roses. User-delegated access (Bob clicking accept in 2019) remains by far the most common implementation. The vendor requests permissions, the user consents and the vendor gets a token they can continue refreshing for indefinite access. In many cases the scopes requested are broader than necessary, for example Bob’s invoice app might have asked for ‘read and send all mail’ rather than just ‘send mail’. It’s also very common to see this integration enabled for senior and privileged users within an organisation since they’re more likely to be process owners (e.g. Bob the Finance Manager being in charge of the payroll email). While we’ve now got some solid admin controls around limiting delegation to prevent users from being tricked into authorising malicious apps, they can’t force a legitimate app to ask for narrower permissions.

Support for service principals is inconsistent at best and most implementations use secrets rather than certificates. We call them ‘secrets’ so it sounds a bit more sophisticated than a password but that’s what they are: a string of characters that proves identity. And if you’re thinking ‘wait, why would you run a clean modern auth engine on the dirty fuel of insecure old passwords?’, you’re on the money! Just as with passwords, we lazy humans have a tendency of storing secrets somewhere convenient; config files, environment variables, GitHub repos, where with depressing / hilarious regularity they get found by automated scanners and lifted by attackers with nobody the wiser until long after the data has walked out the door. Certificates are a world of difference; the private key never leaves the machine or key vault it lives in so there’s no secret to type into a phishing page or leave lying around in a config file. This is the direction that good security practice has been heading towards for years, but very few of us have even started the journey.

The standards answer

So in a nutshell: businesses unquestionably need to delegate access to third-parties to fulfil vital business functions, but very often they’re not doing it using modern, secure methods. In some cases, vendors actively request that security controls be weakened to accommodate their integration. The result is supply chain risk and increased attack surface. Businesses are constrained by vendors, who don’t see the need for investment in refactoring code to include modern authentication since even the least secure methods remain fully supported. So how do we push back on this stance and what do our prevalent standards have to say?

Cyber Essentials

The UK’s Cyber Essentials scheme has some encouraging requirements but when it comes to this problem it has two gaps on opposite sides.

It makes a seemingly sensible divide between human accounts (that do need MFA) and machine accounts (that don’t need MFA) but doesn’t address what happens in that murky in-between state when a vendor uses an interactive (human) login because their integration needs a delegated access token but then they hold that token indefinitely to avoid further MFA challenges. You’ve got a human account, subject to CE’s MFA requirement, doing MFA once at the moment of consent and never again. The standard doesn’t mention token lifetime, scope breadth or more importantly whether the account should be a user at all. That’s our first gap.

The second gap is the mirror image: by placing machine accounts outside its scope entirely, CE leaves the door open for service principals to authenticate with a password and remain fully compliant. There is no requirement to use certificates or store credentials in a key vault; not even any guidance to advertise that secrets are a dumb credential. A vendor could offer a service principal integration secured with a short secret with an indefinite expiry stored in a config file and satisfy the letter of the standard without issue. The demonstrably more secure outcome of certificate-based, non-extractable credentials isn’t mandated or even mentioned.

The upshot: on paper you have scenarios where CE is passed with flying colours, but in spirit you’ve created exactly the kind of privileged access channel the scheme is supposed to push you into avoiding, or at least considering.

Essential Eight

I must say I’m a fan of the E8; it has a similar aim to CE but goes about it in a different way, charting maturity levels as signposts along the route of an evolving journey rather than a one-and-done operation. It’s more explicit about the MFA strategy even at lower maturity levels and higher ones push that to phishing-resistant methods which is far beyond what CE requires.

When it comes to this issue though, it tells much the same story, with nothing to say about what happens after a user authenticates to grant a third-party app delegated access, how long the resulting tokens should be held for or how broadly they should be scoped. Its admin privilege focus is on users, not machines. A vendor holding indefinite delegated access to a Finance Manager’s mailbox doesn’t register as a privilege problem, even though in practice it certainly is one. It also shares the credentials gap; there’s no guidance at any maturity level that distinguishes between a service principal secured with a certificate and one secured with a client secret. Neither is better or worse, which means organisations chasing maturity level three have no standards-based reason to push vendors for the stronger option.

So at the end of the day, both standards are strong on ‘every user must have MFA’ but less specific on what happens when a user delegates access to a third party or where it has standing access through a machine account.

The side door nobody’s watching

Honestly, this really surprises me at a time of growing awareness of supply chain risks. Something that has stuck with me recently was a talk Richard Horne (CEO of NCSC) gave at Cyber UK in which he pointed to the massive economic impact of the JLR attack and basically said that supply chain risk is systemic and inseparable from economic resilience at a national level. That kind of talk makes it difficult to downplay the importance of this, yet the mechanism that makes that supply-chain compromise possible (for example, a vendor holding long-lived delegated access to a Finance Manager’s mailbox) isn’t on the checklist of either major standard.

And to be clear, it is a supply chain problem and not just a technical configuration problem. A compromise at one vendor could cascade into every customer tenant that has granted permissions and that’s exactly the kind of side channel attackers go for because it bypasses the strong controls on the front door. Why bother to bypass that troublesome MFA if you can just hijack a token or steal a secret?

As it stands both CE and E8 touch on supply‑chain risk indirectly but neither forces the kind of specific, uncomfortable conversations about third‑party app access and OAuth design that would move the whole ecosystem forward.

Time to make this someone’s problem

Ok, let’s bring it home. So this is what good looks like: a service principal (machine account) with least-privilege permissions, authenticating via a certificate that’s regularly rotated (or a managed identity which automates that) and underneath it’s all logged with an accessible audit trail.

Adoption under CE would have this included as just one more account to manage, albeit with some additional specifics, rather than a hidden extension of a human identity.

Adoption under E8 would align nicely with the ‘restrict admin privileges’ pillar where lower maturities could mandate the basics like disabling user consent and switching to service principals while higher maturities could require shorter certificate lifetimes, resource-specific scoping and gating privileged permissions behind Conditional Access policies.

Imagine that actually happened; it would throw a spotlight on this issue, give organisations a language for dealing with the risk and put vendors on notice that they need to up their game. The latter is almost the most important to me. If I had a dime for every time I’ve heard ‘we don’t support service principals’ or ‘app-only integration is on the roadmap for 2035’ or ‘nobody else has asked us for this before’! And even when a business fully grasps the reality of their exposure and demands change, vendors see no reason to acquiesce. No major standard is telling them they must invest in app‑only, certificate‑based, least‑privilege integrations to stay competitive.

Have you seen the website sso.tax? It’s a brilliant wall-of-shame charting the companies that charge extra for SSO integration, essentially making their customers pay extra for basic security. We need that, but for this. A wall-of-shame for all of the companies putting their customers at risk by requiring insecure integrations. Perhaps we’ll yet see that happen, but not before standards start treating those integrations as first-class citizens.