Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
Hope everyone had a good RSA week and is mostly recovered! I went into RSA with little to no expectations, but I actually had some great conversations with friends. It felt a bit like old RSA, and it was refreshing. Anyway, out of these conversations, I have a new set of ideas for my newsletters, which is always a plus! Talking about SSPM is one of them.

This newsletter continues a long series of my thoughts on various security companies and categories where I talk about their potential failure modes. Here are just some examples:
This newsletter is inspired by a conversation with Abhishek Agrawal, CEO and founder of Material Security. We were talking about changes that allowed for a new wave of email security vendors. A key part of it was the movement of email away from self-hosting and to the cloud. This was true not just of email but also of many traditional applications, such as payroll, CRM, etc. Moving from on-prem applications to SaaS applications was an important part of the “cloud movement.” This changed the way companies managed software, and naturally, this led to a new security category, SSPM. However, with all new security categories, the question is if it’s actually a category that should exist.
It’s a topic that I haven’t thought much about, but as more data flows into SaaS applications, it’s worth understanding what does SaaS security even mean.
What is SaaS security posture management (SSPM)?
It’s what it sounds like. SSPM tools are automated tools used to monitor security risks, such as misconfiguration, compliance risks, etc., in SaaS applications. It is the SaaS equivalent of cloud security posture management (CSPM), which focuses just on cloud infrastructure.
Most of the companies in this area are relatively new. Some examples are AppOmni, DoControl, and Adaptive Shield.
How did this start?
Many companies move to the cloud with SaaS applications before moving toward cloud infrastructure. This was an easy way to reduce operational costs because IT teams no longer needed to maintain this software. This shift has fundamentally changed the way we develop and operate software. Customers no longer have to store data and configurations on their own servers. (This has also changed the way development and software deployment work as it is easier and faster to deploy software changes. That’s a focus of my newsletter in general, but not a focus of this particular one.)
This movement has created visibility and control issues for IT and security teams. Naturally, security software to help with this problem has emerged, so enter SSPM. Specifically, SSPM provides three key features:
Configuration management: Ensuring there are proper configuration to prevent data leakage
User permission management: Ensuring users have the appropriate level of access to the application. It also detects any inactive users.
Compliance: Ensuring the application settings are compliant with the necessary regulations.
These are just the main features, but these companies have added more features over time, such as anomaly detection and threat intelligence.
The original goal was to monitor all SaaS applications like how IT and security teams used to manage on-prem software. However, SaaS has created too much fragmentation and decentralization.
Needing some focus
Initially, SSPM seems like a great idea, but as companies move more toward SaaS applications, the number of SaaS applications rapidly increases. According to a report by BetterCloud, companies with less than 50 employees use on average around 20 SaaS apps, but as the company grows to over 10,000 employees, it will use around 200 SaaS apps, which is a 10x increase. I expect with more focus on organizational efficiency, this number will likely go up.
Even with a tool, the sheer number of SaaS becomes unwieldy for a security team, especially teams trying to focus on operational efficiency. It makes sense for security teams to focus on high-value applications. This is a good strategy because certain applications might not contain sensitive information, so it doesn’t make sense from a risk perspective to spend security resources on it, especially if resources are limited.
As a result, security teams will likely focus on high-value applications that contain sensitive information, such as Salesforce, Okta, etc. However, there’s been a trend to have the buying organization have more accountability for the security of the application since it has more context on how the application is used and what permissions should be granted. Theoretically, this might seem like a good model, but in practice, it isn’t because buying organizations usually don’t have enough security context to determine the proper configurations for security and compliance.
What does this mean for the SSPM companies? This is good and bad news. The good news is that SSPMs don’t have to cover a large range of applications, and doing all these integrations would be expensive from both a data storage and development perspective. Doing large amounts of integrations continues to be a cost burden to these types of products that do a large amount of orchestration.
The bad news is that for high-value applications, customers will want more in-depth detection and remediation. We saw this with CSPM where posture management was insufficient to deliver continued value and wasn’t as defensive, so that’s why companies like Wiz are acquiring companies like Gem Security that focus on detection and response. That’s why we are seeing SSPM rebrand more broadly as SaaS security because it’s no longer about just posture management.
Bumping up against MDR
The problem is that SSPM companies will face pressure from two sides. First, for very high-value applications, such as Google Workspace or Office 365, customers will likely buy dedicated products like Material Security and Abnormal Security that focus just on the security of that one platform because the information in those is so important. Similarly, for infrastructure software, there are already existing products like Wiz and Lacework.
This leaves other products like Salesforce, Workday, Okta, Auth0, etc. However, this is the other side SSPMs will feel pressure — pre-existing products, like managed detection and response (MDR) players like Expel, already exist to monitor and respond to issues there. As a result, SSPM companies are bumping up against these existing players that have a market and customer base. In my opinion, it’s unlikely that someone will own both Expel and AppOmni. If they do, it’s for the long tail of support that AppOmni offers, but that advantage will likely not be sustained.
This brings up an interesting point. Is SaaS security just part of MDR? It’s starting to seem like it. What’s surprising is that MDR seemed to have all these capabilities, but it was more focused on solving the problem of SOCs and SIEMs. The marketing focus of MDRs didn’t advertise them as doing SaaS security whereas SSPMs locked in on SaaS. In their defense, it wasn’t until recently we had cloud/SaaS-focused MDRs. The market is a bit strange since the SaaS-focused MDRs focused on detection and response and didn’t start with posture management, unlike the current cloud security products.
Either way, if we look at it from a problem perspective, does SSPM merit its own market? I think the answer is no. What I see here is that either teams will buy SSPMs and shift over to MDRs, or teams with MDRs will use that for their SaaS security needs.
It’s possible these companies stay around and will likely be bought up by MSPs and MSSPs. It’s also possible that MDRs acquire these companies to boost their technology. These SaaS security companies inevitably have to get MDR features, and since MDR came “first,” it’s likely we will see the SaaS security market go away. Similar to ransomware protection, which is no longer its own category but briefly emerged, it will be deemed a problem to solve with other security solutions and categories.
I believe SaaS security will be short-lived, and these companies will likely cease to exist or become part of other managed services.