How app developers can go beyond the Minimum Viable Secure Product (MVSP) controls framework to implement better identity protections and prevent identity-based attacks.
How app developers can go beyond the Minimum Viable Secure Product (MVSP) controls framework to implement better identity protections and prevent identity-based attacks.
A lot happened last year in the world of identity security — particularly in terms of the attacks we’ve experienced targeting internet applications and services. With this trend certain to continue in 2025, it’s more important than ever that product vendors build products with a secure baseline of fundamental controls and safeguards.
The vast majority of the identity vulnerabilities we observe in the wild are the result of multiple auth mechanisms being attached to a single account. The more methods that are configured (or are configurable), the greater the risk that insecure identities will be created — and exploited by attackers.
The good news is that with a coordinated response from app vendors, this surface can be significantly reduced. The bad news is that right now, we’re very far from a universal standard when it comes to how apps handle authentication and identities.
Where to start?
The Minimum Viable Secure Product (MVSP) initiative is a great resource for product and engineering teams that sets out essential controls that should be implemented in enterprise-ready products and services. MVSP does a fantastic job of getting to the heart of what’s important for vendor products, as compared to more general frameworks and standards like ISO and NIST that cover wider controls that should be implemented across the enterprise.
We don’t want to reinvent the wheel, so we won’t be redoing the fundamentals already covered in MVSP. But MVSP inspired us to think – what are the vendor controls that would make a meaningful difference against the identity attacks we’re seeing in the wild?
With better, consistent security standards, SaaS developers can close off a number of ATO techniques and generally make life much more difficult for attackers.
We’ve identified two key areas of potential improvement which would make a material difference to ATO resilience:
Many of the emerging TTPs could be seriously impaired (or prevented entirely) with improved authentication and identity management controls.
Detecting attacks and responding to identity breaches on third-party apps is a nightmare due to the availability of log data (or lack thereof).
Let’s look at the changes that app vendors can make to improve the situation.
Provide the visibility and control to manage and harden identities
In the context of SaaS, identity security controls are your best (and in many cases, your last) defense against cyber attacks.
Pretty much every SaaS attack involves ATO through identity-based techniques, such as phishing, credential stuffing, or session hijacking using stolen cookies. In contrast, very few involve classic vulnerability exploitation (e.g. injection vulns, cross-site scripting, etc.).
When all an attacker needs to do is log into an app and dump the data to succeed, there isn’t much in the way of post-ATO activity to detect and respond to (even if you had the logs you need, more on this later) — which is why robust authentication controls to prevent unauthorized access are so important.
If post-ATO activity does occur, it is often to compromise additional accounts with in-app administrative privileges as opposed to pivoting to other environments.
As you’d expect, many apps prioritize a frictionless user experience over security. This is one of the main drivers of insecure authentication implementation. Consistent implementation of identity and authentication controls would go a long way to reducing the susceptibility of apps to the majority of identity attack techniques.
In terms of authentication and identity management, MVSP focuses on:
Providing an SSO mechanism,
Implementing a robust password policy, and
Logically separating data/functions based on the needs of a user type/group.
We can go beyond these basic auth controls to prevent identity attacks by providing better default security configurations, and giving admins more visibility and control over identities.
1. Allow one active login method (and require external re-verification to change to another).
If you don’t take anything else away from this piece, this control alone will get rid of 80% of the complexity and room for vulnerabilities to creep in.
There is very rarely a need for multiple authentication methods to be active for the same account at the same time. Perhaps you upgrade from a local password to OIDC or SAML — but there’s no need to have multiple SSO logins from different providers at once, and there’s no need to continue using a local password after adding an SSO method. One exception is Administrators retaining local password access to access the tenant in case SAML configuration breaks (commonly because certificates expire) but in all other cases it’s an anti-pattern to allow any user more than one auth method.
We call these alternative login methods (especially when they are in addition to SAML — so e.g. local password or OIDC logins using Google or Microsoft) ghost logins because they provide attackers with a way around a company’s chosen enterprise SSO option.
This situation most commonly arises because apps automatically merge login methods. So for example, if a user normally logs in with a password, but then attempts to login using an OIDC of social login — many apps automatically merge that new login method with the existing account. This is particularly problematic when it’s done without further verification steps — leading to cross-IdP attacks. Ideally, apps should disable the old log method when a new one is enabled, but at the very least, external verification of the change should be required (e.g. via email).
2. Require external verification of changes to IdP configuration settings.
Attackers that are able to compromise one account with the level of privilege required to change the SAML settings in-app (typically an app admin), even on an app that is otherwise uninteresting or low risk – can perform an attack technique known as SAMLjacking. This can be used to direct users to authenticate to the app via an attacker-controlled IdP tenant (so e.g. an attacker’s own Okta instance or phishing page that looks like Okta/MS/Google) to capture additional credentials and facilitate further compromise of accounts.
Using SAMLjacking, an attacker can turn the compromise of a low risk app/identity into a much more serious one by using it to capture SSO credentials for other users of the app.
To mitigate this, any SAML changes should require external verification, ideally through an out-of-band method like DNS Verification. If this can’t be achieved and you need to rely on email, the request should be sent to all app admins (to increase awareness of the risky change) and come with a cooldown period before the change takes effect. This improves the chance that an attacker’s SAMLjacking attack can be intercepted before half of the victim’s workforce gets keylogged — not after!
3. Provide admins with visibility of account authentication (login methods, MFA methods, IdPs used) and allow them to be restricted or removed.
Many apps provide very limited information to admins about the configuration of identities within their tenant, and fewer still provide any mechanism for admins to take action if gaps or potential weak points are discovered. Some don’t even provide information about which accounts have access to the tenant at all. As a security team member this is maddening.
One of the leading causes of identity breaches is when ghost logins (usually a weak, breached or reused password) exist alongside a more secure login method (e.g. SAML SSO). These ghost logins can be exploitable either as a single factor, or with a weak/phishable MFA method. It doesn’t matter if your employees typically log in with SAML, if insecure local logins exist alongside it — because attackers can take advantage of this.
It’s vital that, at the bare minimum, admins can access information (ideally in a dashboard) with the accounts, all login methods configured, MFA factors set, and the SSO methods used (specifying the IdP and protocol). All login methods should be visible to security admins, including secondary email addresses, social login connections, and so on.
It should then also be possible to set a preferred method (e.g. only SAML from Microsoft, or OIDC from Google) and delete or disable ones that pose a risk.
For security teams to be able to clean up insecure identities, they need to be able to make changes inside the app without requiring an action from the user. This means removing phishable MFA factors to prevent MFA fatigue and MFA downgrade attacks.
4. Support the use of domain-bound credentials (whether in the form of a passkey or MFA method) that are phishing resistant (FIDO key).
It’s no longer the case that simply having MFA is enough to stop identity attacks. The vast majority of phishing campaigns now make use of AitM toolkits designed to bypass MFA. The only MFA methods considered to be phishing resistant are those using device-bound authentication methods such as passkeys/WebAuthn. However, only a handful of apps actually support these authentication methods. While the majority of SSO apps do support them, apps should provide support locally as well, particularly for B2C use-cases where enterprise SSO isn’t being used.
5. Allow active sessions to be viewed and remotely terminated by administrators.
Most apps have no way of viewing valid sessions and session activity, even as an administrator. With session hijacking attacks using stolen session cookies on the rise, being able to (at the very least) terminate sessions that are suspected to have been compromised is key to effective incident response. In an ideal world, you would be able to view the properties of the session (such as the browser, IP, location that the session is being accessed from) to identify unusual or suspicious activity, which could in turn be leveraged by SecOps teams for their detection workflows.
6. Allow admins to prevent users with a matching domain from auto-joining a company tenant without being invited or approved by an admin, and notify when they do.
Many apps do not provide the level of granular permissions that we’ve come to associate with enterprise cloud platforms — often because it simply isn’t necessary. This means that a lot of the time, the average user can access most, if not all of the data stored within an app. This is problematic if any user with a matching domain can join a company’s app tenant. This creates insider risk, as well as increasing the blast radius of ATO of an IdP account in terms of affected apps — it’s not just the apps they’re actively using, but any they can sign up to as well.
You might assume that a user with access to an IdP account also has access to the email connected to that account, but as we’ve seen with cross-IdP impersonation, this isn’t necessarily the case.
To address this, apps should allow admins to lock down their app tenant to be invite-only should they desire (and enable it by default), and at least issue email notifications to admins whenever a new user joins the company’s app tenant — prompting the admin to check that the event is expected.
Enable security teams to detect and respond to identity attacks
Security teams required to respond to incidents affecting SaaS apps are united in how painful it is:
Many SaaS providers don’t offer audit logs at all (or charge extra for the privilege).
Even when logs are available, they might be incomplete, like missing login events, or critical pieces of information in the event needed to decide whether it’s malicious or not.
The lack of standardization across tools creates ingestion challenges, with each app requiring custom development work.
The logs you really need can’t always be accessed programmatically. The provider might have them, but you’ll need to put in a request – that could take hours or days to respond to.
All of this makes it very challenging to ingest meaningful security log data from SaaS and harness it for detection and response. Hours or days is an eternity when you’re in the midst of a live incident, and is inevitably going to result in a worse outcome for the business.
MVSP specifies that authentication events should be logged (and for how long they should be stored), but practically there is little consistency in the types of event and the fields captured. App vendors should make sure that the data points they provide (and the format that logs are provided in) can be practically used by security teams.
7. Log detailed authentication/login information.
Authentication information is arguably the most important log source in the context of SaaS services which lack granular permissions management, because:
If you know a malicious user accessed the app, you can infer/assume the likely impact, and respond accordingly.
Attacker behavior in-app is often indistinguishable from typical user behavior.
This means it’s vital to understand who accessed the app, at what time, and from where.
The SaaS Event Maturity Matrix provides a great starting point when looking at the availability of authentication logs across different platforms.
We recommend that all providers include the following Authentication and MFA Verification log fields:
With this level of granular information it will be much easier for security teams to reliably differentiate malicious from legitimate access, independently or when combined with other data points:
Identify suspicious logins due to location/impossible travel
Identify failed login attempts due to either credential or MFA failures, indicating possible credential stuffing attacks
Identify the IdP used to login to detect unapproved or unusual IdP logins (a possible indicator of cross-IdP impersonation)
Identify where an unexpected (less secure) MFA method is used, indicating a potential MFA downgrade attack
Differentiate active session location from the device/client/location of the original session (to detect session hijacking attacks)
8. Make audit logs available in a format and using a mechanism that is easy to ingest into common security tools.
Even where logs are available, security teams often have to wrestle with the format they are provided in to be able to make use of them. While JSON is pretty much the de facto standard nowadays, the absence of a common schema and field names is often the tricky part — complicated by the fact that there are multiple competing standards. At the very least, complying with at least one of the more established schemas (e.g. the Elastic Common Schema) will provide a level of standardisation to make things easier for security teams.
Arguably an even bigger challenge is pulling the events you actually need from the data — so making it possible to stream logs or access them programmatically to minimize collection delays is a key change that app developers can implement regardless of the schema used, that will make life easier for SecOps teams. With that in mind:
Login events indicating a potential identity attack should emit preconfigured webhook events to enable security teams to better detect and respond, (such as in the context of the use cases above).
API access should also be provided to ensure that logs can be extracted to inform point-in-time investigations in the event of a suspected incident. (It’s no good if you have to request that certain logs be sent to you during a time-sensitive security incident.)
Final thoughts
The key takeaway here is that the scope for identity attacks and abuse could be significantly mitigated with a better standard of app-level controls. If you’re familiar with Push, you’ll recognize that many of our features compensate for these gaps in visibility and control — made necessary by the fact that so many apps don’t provide basic information about the accounts within your tenant, or give you any controls to manage authentication in accordance with your risk profile.
This is certainly not intended as a definitive standard or exhaustive list of identity controls — but hopefully provides any app developers or standards authors with food for thought! We speak for other potential customers when we say that including these controls would make your app much more attractive to the security and compliance teams of prospective buyers.
If you agree with us and think that stronger identity controls around authentication and security logging are needed, then consider adding these suggestions to your procurement requirements when on-boarding new apps and services.
Book a demo to find out how Push can mitigate widespread application security gaps and secure your identity attack surface.
