What happens when an organisation discovers accounts on a third-party app without MFA?

What Missing MFA on Third-Party Accounts Really Means

When an organisation finds accounts on a third-party app without MFA, the issue is not just policy drift. Those accounts are often the easiest path into SaaS data, shared workflows, and downstream integrations because a password alone is all that stands between an attacker and a valid session. If the app stores customer records, internal documents, or connected secrets, the exposure can extend well beyond the app itself.

That is why third-party access should be treated as an identity and trust problem, not only an application setting. The security significance is greatest where the account is tied to an employee, service process, or delegated workflow that was assumed to be protected by the provider. OWASP’s OWASP Non-Human Identity Top 10 is useful here because many of the same control failures show up once an account is allowed to authenticate without strong assurance.

In practice, many teams discover the absence of MFA only after access reviews, incident response, or a vendor audit has already exposed how many accounts were operating with weaker-than-expected protection.

How It Works in Practice

The practical response is to separate the question of who can log in from the question of what the app is connected to. First confirm which identities are active, whether they belong to individuals or shared functions, and whether the third-party service supports MFA for each account type. Then determine whether passwords are reused, whether any sessions were recently authenticated from unusual locations, and whether the app issues tokens or API keys that could preserve access even after a password change.

Enforcing MFA is the visible fix, but the real control point is assurance. If the app supports only optional MFA, an organisation should raise that setting centrally and require enrollment before normal use resumes. Where the app cannot support MFA for certain legacy or partner flows, the access path needs compensating controls such as tighter scope, shorter session lifetime, stronger monitoring, or removal of privileged functions from that account.

A useful way to think about this is:

• Human accounts without MFA create direct password-guessing and credential-stuffing exposure.
• Shared or delegated accounts without MFA create attribution and revocation problems.
• Accounts linked to integrations can keep working after a user changes a password unless tokens are also reviewed.

NHI Management Group guidance on lifecycle control is relevant because missing MFA is often only one symptom of a broader ownership gap, where no one has a complete inventory of who should have access, how that access is protected, or when it should be removed. The Ultimate Guide to NHIs — Key Challenges and Risks is a useful companion reference for that lifecycle view. These controls tend to break down when third-party apps sit outside central identity governance and teams assume the provider’s default settings are already strong enough.

Common Variations and Edge Cases

Tighter access enforcement often increases friction for users and support teams, so organisations have to balance recovery speed against the risk of leaving weak accounts untouched. The right response depends on whether the account is a standard user login, a shared departmental account, or a connected integration with broader privileges.

Some third-party apps support MFA only for interactive sign-in, not for API access or delegated tokens. In those cases, enabling MFA on the visible login does not fully eliminate exposure, because existing sessions, refresh tokens, or connected app grants may still permit access. Best practice is evolving here, and there is no universal standard for every SaaS product; organisations need to validate what the MFA control actually covers before they treat the account as remediated.

This is also where role matters. A low-risk collaboration account without sensitive data is not the same as an admin account connected to source code, finance workflows, or customer records. The more privilege the account has, the less acceptable it is to leave MFA as optional or inconsistent. That is why the issue should be resolved as an access governance problem, not only a user-enrollment task.

For teams that need a broader control lens, the OWASP NHI guidance and the NHI lifecycle materials help distinguish between fixing the symptom and correcting the underlying ownership and offboarding gap. The key judgement is whether the account can still be used to reach anything valuable before the remediation is complete.

Practitioner Guidance

What to prioritise: Treat any unmfaed third-party account with access to sensitive data, admin functions, or connected tokens as a high-priority exposure. If the account can authenticate to production systems or shared content, address credential risk before debating whether abuse has already occurred.

What to verify: Confirm what MFA actually covers in that app: interactive login, session renewal, API tokens, delegated access, and recovery flows may each behave differently. The common mistake is assuming that one successful enrollment closes every access path.

Decision rule: If the app cannot enforce MFA uniformly, reduce privilege or remove the account from the workflow until the gap is closed. If the account is shared, treat attribution and revocation as part of the fix, not as a separate problem.

Practitioner takeaway: Missing MFA on a third-party app is rarely just a configuration defect; it is evidence that access governance, token visibility, and account ownership are not aligned tightly enough to trust the app at its current privilege level.

Related resources from NHI Mgmt Group

• What happens when service accounts are left without ownership or access reviews?
• What happens when a third-party vendor suffers a breach and the manufacturer has no incident notification policy?
• What breaks when an app relies on refreshable third-party tokens without lifecycle controls?
• What breaks when a mobile app trusts third-party SDKs without runtime monitoring?