A version of the following deep dive into the identity security landscape originally appeared on Contrary Research’s website as the final part of its Cybersecurity Series. Rak teamed up with Kyle Harrison, general partner at Contrary, and Justin Li, research fellow at Contrary Research, for the piece.

Contents

• Actionable Summary
• The Cybersecurity Series
• Why Identity?
• Chapter 1: Novell (1980s)
• Chapter 2: Microsoft (1990s)
• Chapter 3: Enron and SOX (Early 2000s)
• Chapter 4: Active Directory Dominance
• Chapter 5: Federation in the Cloud
• Chapter 6: Identity Today
• Chapter 7: Where Do We Go From Here?
• Appendix

Actionable Summary

• Perimeter erosion created serious trust issues within the security community. If you can’t trust the messages you’re getting, you have to trust the person sending them. That means you have to figure out who the person is, why they’re trying to interact with you and whether or not you should open that message.
• As of 2023, 75% of security breaches are caused by mismanaged identity, access or privileges. One 2020 report found that 79% of organizations had an identity-related breach within the previous two years. If issues related to identity could be solved once and for all, there would be no need for most other security products. But getting there is incredibly hard.
• Nearly half of organizations use more than 25 systems to manage identity and access rights. As companies grow and acquire and get acquired and middle managers empire-build and reorg for the third time in a quarter and bottom-up adoption chips away at centralized purchasing, identity complexity only gets worse.
• Novell, founded in 1979, became the early pioneer in managing identity and access with a file-sharing system that let admins and users control access at the file level instead of at the entire disk volume level. This meaningfully changed the way the industry thought about access control.
• Novell grew to over $2 billion in annual revenue and 10,000 employees at its peak in 1994. But, ultimately, Microsoft would prove to be Novell’s downfall. In 1999, Microsoft previewed its Active Directory (AD) which is essentially a database with business logic to service directory requests. This product would underpin Microsoft’s future in the enterprise and proved to be a fatal blow to Novell’s business.
• Towards the end of 2001, the Enron scandal broke, which led to Congress passing the Sarbanes-Oxley Act (SOX) in 2002. This new regulation required enterprises to monitor and audit logins, user activity and information access rights. Nearly every publicly-traded company in the U.S. started buying identity access management (IAM) solutions as a result.
• Increasingly, Microsoft’s Active Directory became more and more painful to use. Despite all of that, it was hard to get rid of it and switch to another product. Migrations were long and fractious, and the directory is so baked into business processes that dependency management is migraine-inducing.
• Todd McKinnon and Frederic Kerrest were Salesforce veterans who had a few very specific insights: (1) On-prem identity tools were becoming bottlenecks for teams, (2) cloud applications were being held back by brittle identity systems and (3) Microsoft was going to have a tough time migrating customers to a cloud version of Active Directory. As a result, Okta was founded in 2009.
• As more and more of companies’ assets continued to move outside the firewall, policies like Bring Your Own Device (BYOD) emerged. The need for multimodal security across mobile, cloud and more led to a broadening of the security landscape. This accelerated new categories like mobile device management (MDM), customer identity and access management (CIAM), machine and workload identity and more.
• The identity market is in a weird spot today. There are more vendors than ever, each tackling important parts of the identity lifecycle, yet over 60% of security leaders believed the space was consolidating as of August 2022.
• Identity has become the new perimeter, and this has led to some disastrous consequences (according to a 2023 report, four out of five breaches started with an identity issue). To fix this will require a lot of innovation, both at the platform hyperscaler level and the individual product startup level.

The Cybersecurity Series

The cybersecurity ecosystem has become increasingly fragmented over the past few years. This report is part of a series on cybersecurity from Contrary Research to unpack that complex ecosystem.

In its previous deep dives on the topic, Contrary started with a big picture look at cybersecurity examining the broader landscape to give readers a framework for understanding the sector. Its second report covered endpoint security and its adjacent industries like security operations and SIEM platforms. It also covered emerging startups to monitor within the ecosystem. In Contrary’s third report, it unpacked the world of cloud security, which is relatively new and very much in flux. In this final entry of the series, Contrary and Rak break down the role of identity in a rapidly changing digital playing field.

Identity is a complex beast in part because of how many different aspects of an organization it touches. Each functional area has its own idea of identity tracking, whether it’s sales, HR or finance. On top of that, identity has long been thought of as primarily an IT issue. But, increasingly, identity lies at the very center of the cybersecurity landscape.

In November 2023, Okta alerted customers that it had suffered a breach. While that’s a scary announcement for any potentially impacted customer, most simply hope they weren’t one of the ones affected. Unfortunately, in this instance, 100% of customers were impacted. A month before, Okta had estimated the impact would only be felt by ~1% of customers. Missed it by a mile.

But Okta isn’t alone. A staggering 80% of breaches occur as a result of identity issues, such as compromised credentials. Firms like MGM, Caesar’s, Atlassian and New Relic joined Okta among the identity-impacted breaches just over the last half of 2023 alone. Losses from these breaches can amount to hundreds of millions of dollars.

The purpose of this deep dive is to unpack exactly how identity became such a critical threat surface, and how the landscape is evolving to address those threats.

Why Identity?

In March 2023, Rak published a piece about Palo Alto Networks. In it, he observed that the network has dissolved as a useful enterprise perimeter:

“When [PANW] started [in 2005], networks defined the enterprise perimeter. Securing the network was consequently the highest-value place to be. Over the ensuing decades, the network perimeter dissolved with remote work and cloud-distributed applications. Palo Alto’s firewall products, once 90%+ of revenue, comprise 60% of the business today. We expect revenue share to decrease as the company scales its Prisma offering, delivering security over the cloud, and invests in new products.”

Perimeter erosion created serious trust issues within the security community. If you can’t trust the messages you’re getting, you have to trust the person sending them. That means you have to figure out who the person is, why they’re trying to interact with you and whether or not you should open that message.

The identity landscape consists of public companies, like Okta and CyberArk, take-privates, like Centrify, ForgeRock, Sailpoint and Ping Identity, and dozens of startups. Those startups are fueled in part with billions of venture capital invested each year. It’s obvious to just about everyone that, as a company, you want to exercise control over who has access to which of your files and applications. It’s noncontroversial that employees should have to verify that they are employees before mucking around your systems. And it’s well understood that you set up a few policies, do an audit of who uses what and why, and issue a couple of proclamations to your organization every couple months (”Folks, stop inviting your friends and family to our Jira instance”) and you’re secure! Just kidding.

As of July 2023, 75% of breaches were being caused by mismanaged identity, access or privileges. In 2020, 79% of organizations reported having had an identity-related breach. Identity has produced several large companies given the leverage identity security can provide. If identity could truly be “solved” once and for all, you wouldn’t need a lot of other security products! Who cares if an S3 bucket is misconfigured if only trusted workloads, trusted APIs and trusted users can access the data within?

But it’s incredibly hard to get there. This is partly because enterprise footprints continuously get more complicated, and partly because attackers are constantly shifting methods. The companies addressing identity security are typically addressing two questions: (1) authentication (e.g., who are you?), and (2) authorization (e.g., are you allowed to do what you’re doing?). But there are a few key areas where this typically breaks down.

The crisis

After meeting hundreds of IT and security leaders, identity product chiefs and entrepreneurs, we observed three core problems in the identity space:

1. Most identity products are governed by static, group-based policies. Users constantly move around, both in terms of their physical location and in terms of their positions within an organization. The software they need to use can therefore change on a daily basis, and what they should be allowed to do within that software likewise fluctuates with time. Policies govern who can do what under which circumstances, but creating policies is tedious, and updating them in response to a continuously changing environment is close to impossible.
2. Infrastructure acts like users do. There’s not much difference from a security perspective for a user to manipulate an application vs. a third party API token vs. an ephemeral function in a Lambda environment vs. an LLM agent. But there isn’t a functional abstraction layer to control the behavior of these infrastructure actors that won’t hinder developer agility.
3. The IT department (the one most empowered to own identity) isn’t a decision-maker. That incentivizes product teams working on administration to hit parity with competing products and call it a day. In other words, if nobody’s picking your product because you built better SSO, you might as well ship it and then go work on more interesting things. SaaS founders know this; when we asked how they planned to monetize their existing products, many shrugged and said, “SSO, probably.”

The incumbent identity companies that exist today are not built for the reality they are contending with, and users like admins, CISOs and founders are left to reckon with an increasing set of issues.

Identity is a gerontocracy

Currently, some of the most valuable standalone identity companies are Okta (founded in 2009), CyberArk (f. 1999), TPG-owned Delinea (Thycotic, f. 1996 and Centrify, f. 2004), Thoma Bravo-owned Ping Identity (f. 2002) and ForgeRock (f. 2010). Of all of these companies, only Okta was born in the cloud and has made progress towards converting the world to cloud directories, but didn’t meaningfully expand beyond that.

Nearly half of organizations use 25 or more systems to manage identity and access rights. As companies grow and acquire and get acquired and middle managers empire-build and reorg for the third time in a quarter and bottom-up adoption chips away at centralized purchasing, identity complexity only gets worse. Where there is complexity, there is opportunity for bad actors to exploit the system. More people using software means a wider attack surface for credential stuffing and password spraying. One employee of Rockstar Games had their Slack account taken over this way in August 2022.

The rise of remote work means there are no blanket IP address protections, making vendors insecure as they try to enable work from everywhere. And the more infrastructure vendors a company uses, the more exposed the company becomes to cross-platform risks, like session hijacking, which is exactly what happened to Office 365 users in July 2022. Not to mention the emergence of newer threats, like foundation models being used to carry out wide-scale social engineering attacks by perfectly mimicking voices, phishing emails gaining sophistication and more.

So let’s go back to the very beginning. How did the identity space end up where it is today?

Chapter 1: Novell (1980s)

Launching Novell

In 1979, George Canova and Jack Davis, two veterans of the minicomputer industry, founded Novell Data Systems in snowy Orem, Utah, with $2 million in seed funding. The company was originally in the business of designing and selling minicomputers and printers, but it didn’t go well. The business was incredibly capital-intensive and sales were paltry. The company had to find a different, higher-margin business, and fast. A group of BYU students, who called themselves SuperSet, were hired as consultants to implement a system that could link together these printers and minicomputers to exchange files. In another 10 years, their system would underpin LAN and lead to the widespread adoption of directories, user authentication and encryption-in-transit.

Unfortunately, at the time, it had little effect. The company was about to go under when a veteran from General Electric named Ray Noorda came across the company, then called Novell Data Systems, at a trade show in 1982. He joined the struggling company as CEO, shortened the name to Novell and made the file-sharing product the center of the company’s new strategy. Today, this would be like if Satya Nadella met a seed-stage, pre-product-market-fit startup at KubeCon and said, “Yep I’ll come fix this for you.”

It worked. Novell grew to over $2 billion in annual revenue and a staff of 10,000 employees by the time it peaked in 1994. NetWare 4.0, the file-sharing system that SuperSet had previously developed for Novell, let admins and users control access at the file level instead of at the entire disk volume level. This meaningfully changed the way the industry thought about access control.

Around the same time, Apple, IBM, DEC and others were racing to commercialize personal computers, which created a huge latent demand for Novell NetWare. The company wisely marketed the product as an agnostic enabler of secure collaboration across a diverse set of printers, computers and other networked machines in a company. NetWare was one of the first to support user and group-based access controls, which made it attractive to admins who were increasingly facing a decentralized computing infrastructure as the PC eroded multiplexed central computers.

Forty years later, two dynamics of the identity industry still endure:

1. Core applications and governance systems have both trended towards increasingly fine-grained permissions to give admins more control. Access governance has descended lower in the stack with every generation, from disk volumes to files to apps to permissions within apps to the microservices underneath it all.
2. Identity tools win on their ability to play nicely with every app, service, container and other entity in the known corporate universe. This was termed “co-opetition,” by Noorda in the 80s.

Competition loves complacency

Netware 4.0, which was launched in 1993, included Novell Directory Services (NDS), a distributed, replicated database that stored directories at the network level. Users would log into a network and see the files they had access to, instead of having to try accessing specific resources at specific locations. At this point, authentication and access were still largely resource-centric rather than actor-centric.

That same year, Tim Howes, Gordon Good and Mark Smith from the University of Michigan published the first LDAP (lightweight directory access protocol) specification, which was groundbreaking for its openness, vendor neutrality, performance and reliability. At its core, the protocol created a standardized way for a directory server to find, retrieve and serve the appropriate resource or information requested by a user. The work was largely academic until 1996, when the trio was hired to come work at Netscape, sparking an LDAP arms race.

In January 1998, Netscape shipped the first commercial implementation of LDAPv3, which included SASL (simple authentication and security layer) and would become the basis for MFA and other challenge-and-response auth paradigms. Sun Microsystems shipped a similar directory server just six months later. Novell’s stronghold on the directory services market seemed to loosen with each passing product announcement, but none were as disruptive as Microsoft’s new product, Active Directory, would prove to be.

Chapter 2: Microsoft (1990s)

Some assembly required

Novell’s previously unassailable position started looking much more vulnerable around 1995, when a spry Bill Gates realized identity didn’t need to live outside of core business applications (e.g. in NetWare) if everyone had a personal computer. Microsoft attempted to take on Novell in networking twice in the 80s, with MS-NET and LAN Manager, but failed both times. Networking was, at the time, one of the fastest growing markets in all of technology, giving rise to companies like Cisco, Juniper, and more. Gates, instead of trying to fight for the network, decides to make Novell fight for the admin.

During this time, the CEO of Novell was none other than Eric Schmidt, who served from 1997-2001. He had left his role as CTO of Sun Microsystems to join the struggling networking giant, and had a tough turnaround mission ahead of him. Microsoft’s Windows NT shipped TCP/IP stacks for free as part of the operation system, eating into Novell’s margins. Still, Novell persevered for the first couple years of Schmidt’s tenure. He refocused Novell around the directory services products and shed everything else. The thinking was that it was not the time to diversify, it was the time to triple down on what was working. Schmidt said at the time that:

“You have to stop the bleeding and stabilize the patient. We reduced seven layers of management to four. We launched an aggressive PR campaign, announcing new products or product upgrades every month. We refocused on our core strengths. The biggest challenge was retaining our key talent–the “smart people”–and keeping them motivated. A company can survive losing a lot of people, but if it loses its smart people, it’s done for.”

Meanwhile, in 1999, Microsoft previewed Active Directory, the product that would underpin Microsoft’s future in the enterprise and hammer the nail in the coffin for Novell. Active Directory (AD) was (and remains) essentially a database with business logic to service directory requests. AD structures can be objects (printers, servers, etc.), principals (users, accounts, groups) or various permutations of objects and principals. Schemas are editable by admins, but every change is propagated throughout the system, leading to massive disruptions and changes when done improperly.

The king of distribution

Microsoft AD was, as is the Microsoft way, bundled with Windows Server 2000. As the server operating system began its domineering run, Microsoft AD quickly became the standard way for enterprises to authenticate and store information about their users and assets. Novell’s early product lead, as our friends at Slack know all too well, lost ground to Microsoft’s imposing distribution advantage, beginning an irreversible nose-dive that lasted until 2014, when Novell was finally acquired by MicroFocus. Eric Schmidt fared better, leaving Novell in 2001 to join a post-Series A Google.

IT departments initially rejoiced at the arrival of Active Directory; they could, for the first time, centrally and easily enforce policies, like password reset and length requirements, on all of their users, even as the types of devices and applications in use grew more and more complex. As the ecosystem evolved, frustrations began to percolate: Integrations were brittle, managing AD became a full-time job for teams of IT admins, non-Microsoft apps and devices were hard to bring into the fold, and interfacing with objects beyond the firewall and outside of the network was tough. Getting a new user access to an app would take days, if not weeks, and business users started resenting IT for getting in the way of their productivity.

Still, Microsoft became the undisputed leader in enterprise administration. When you’re the only game in town, even your bugs become features! Microsoft launched certifications and deployed legions of system integrators, partners and more to get customers operational. But things in the world of identity and access management were about to change. Right as Eric Schmidt was leaving Novell towards the end of 2001, the Enron scandal broke.

Chapter 3: Enron and SOX

The fraud heard round the world

There are whole books written about the Enron scandal, so we won’t go into it here. Just know that Enron was an energy company that started trading in energy derivatives, and wound up using fraudulent accounting practices to artificially inflate and obfuscate its financial health from investors. When the fraud unraveled, Congress passed the Sarbanes-Oxley Act (SOX) in 2002 to protect investors by enforcing a set of business and IT controls, including requirements to monitor and audit logins, user activity and information access rights.

The birth of access management

As a result of this new legislation, nearly every publicly-traded company in the U.S. started buying identity access management (IAM) solutions. It was no longer possible to get away with just an Active Directory instance and a dozen admins in front of it moving users and groups around. A constant stream of login and access events was now necessary, and these needed to be audited regularly to make sure nothing bad was happening. Aside from access management, this was a tailwind for the SIEM and security analytics market, which we’ve written about here and here.

Three new identity categories emerged during this time: single sign-on (SSO), privileged access management (PAM), and identity governance and administration (IGA).

Single sign-on

Remember, in the early 2000s applications were just getting started. Organizations were building applications both for internal users and external customers, and employees were getting more and more annoyed at having to log in and re-authenticate with each one. At the same time, companies like Atlassian and Salesforce emerged with per-seat pricing, making IT teams really want to understand who had access to the expensive software they were buying. SSO was technically not a new idea, but Microsoft brought it to the masses when it launched Active Directory Federated Services (ADFS) in 2005 and bundled it with Windows Server 2003 R2.

The way ADFS works is simple: Instead of authenticating with each app, it allows users to authenticate with a central authority that downstream apps trust. It’s like having a famous friend walk you into an exclusive nightclub. If you tried walking up to Club Workday by yourself, Workday would want to know who you were and why they should let you in. But if you were to walk in with your wingman, ADFS, it would give Workday and every other application a set of assertions about you: “This is Bob (authenticated), Bob’s with us (verified domain), Bob should get to look at expense reports (authorized), etc.” This is also why SSO is called “federated access,” because your single identity is federated across multiple different applications.

All of this information – who you are, which organization you’re a member of, and the apps you have access to – used to live in an on-prem box running Windows Server and Active Directory until Azure AD launched in 2008. Granted, it wasn’t really useful until 2015, when AD Connect was launched to connect on-prem AD to cloud AD. As the number of users grew, more people needed to use more apps and services, some that worked well with Microsoft and some that didn’t. What was once a symphony of IT policy became a cacophony distorted by vendor lock-in, management and scaling issues.

ForgeRock (f. 2010) and Ping (f. 2002) started as open-source competitors to Active Directory to challenge the Microsoft lock-in. Both have since added cloud capabilities and diversified. Addressing management and scaling across the entire ecosystem of software was basically the Okta thesis, which will be discussed in greater detail later. On the consumer side, this is how Login with Facebook, Login with Google, etc. would work.

Owning SSO became incredibly strategic. For one, it gave you a window into which apps were taking off, which Okta has capitalized on for several years with its annual Businesses at Work report. Second, the directory became to identity what Salesforce is to sales, or Workday to HR or Anaplan to finance — in other words, it became the core system of record. To own the directory and authentication was to have the option to expand into several other adjacent identity markets, which Microsoft has done a tremendous job of. Today, companies like Cerby, Jumpcloud and Ory present more lightweight ways to do IAM and SSO.

Funnily enough, if you look at the pricing and packaging of your favorite SaaS apps today, you’ll notice SSO and audit trails to be the basis of upgrading from standard to enterprise and charging a 4-5x markup. SSO.tax does a wonderful job cataloging these companies.

Privileged access management (PAM)

In 2002, Thycotic and CyberArk were six and three years old, respectively. Admins were newly empowered (and required) to keep track of relevant security events happening within their organizations and decide when people gained and lost access to critical systems. But who would audit what the admins did? What would happen if an admin went rogue, or got tricked or compromised or had their account taken over?

The solution was, in a way, to get an admin for the admin. Privileged access management emerged to (1) control the activities of IT admins, and (2) protect administrative accounts from being compromised. Companies like Thycotic would vault the credentials of protected accounts and monitor active sessions for those credentials. CyberArk would help with discovering what should be protected, whether it was accounts, tokens, keys or something else, and was one of the first to couple credential vaulting with infrastructure entitlements management (i.e., who has access to manipulate which workloads on which machines).

Beyond IT, every account can become a privileged account depending on the circumstances. An engineer trying to spin up new instances in AWS needs special privileges to do so. A design leader might need to control the number of seats on their Figma license. An FP&A person might need to pull a list of salaries. No IT person ever got sent a vicious email for over-provisioning access, which is why the majority of companies grant users too many permissions. As a result, PAM has evolved to cover more types of roles than just admins, and secures more than just credentials and secrets (see IDC survey below). This scope expansion has forced PAM vendors to compete on identity governance, data security and infrastructure entitlements. According to a 2023 report, 99% of users, roles and services are granted excessive permissions.

Today, most dominant identity platforms (except for PAM-focused players like Delinea) look to HashiCorp to vault secrets and partner with their Vault product instead of building secret vaults themselves.

Identity governance and administration (IGA)

With these pieces in place, companies had a directory system (probably Active Directory but maybe Ping) and a way to track what their admins were doing, but they also had a whole company of people in various roles that would be asking for various bits of software every day to get their jobs done. Managing all of these complex access requests is hard for humans to do and requires the use of workflow software that at least helps maintain a source of truth for what ought to happen (policies) and track compliance with those policies.

From there, IGA products go further by collecting, triaging and automating access requests. The dominant company in this space is Sailpoint, which Thoma Bravo acquired for $6.9 billion in 2022. Mark McClain started Sailpoint in 2005 after selling his prior IAM company Waveset to Sun Microsystems.

Microsoft’s access controls were (and largely still are) limited by role-based definitions. The problem is that the average organization has 7,700 groups, and any individual engineer may already be part of hundreds or even thousands of groups, each with overlapping definitions of access. Mapping all of this out and then drawing up workflows manually is a daunting task. SailPoint offers a solution to this. The company markets itself as the product to bring in when a directory is difficult to untangle. The product claims to provide a lead in automating as much as possible with analytics and machine learning (ML).

IGA tools must handle the lifecycle of access rights, orchestrate workflows like provisioning users as they join the company and assign rightful owners for specific tasks. Anyone familiar with enterprise software is probably thinking, “Wait, isn’t this basically what ServiceNow or Jira does?”

The answer is yes – IGA is largely a workflow orchestration product. It’s just as essential as SSO, in that every company has to have a solution for it, but as underlying workflow systems have grown more flexible and less opinionated, an IGA solution can be built on top of a company’s enterprise system of record of choice given enough resourcing to build out the right integrations. Multiplier is one example of an IGA product built atop Jira.

Because IGA deals with when and how to grant and revoke user access, it has become the vanguard of the war for authorization. Many contemporary identity startups are building next-gen IGA, with competitive edge coming from automating more workflows, creating workflows more easily or specializing in a domain. The dream is to automatically infer the correct workflows based on historical interactions with various services, and make just-in-time decisions on whether someone should have access granted or revoked based on present conditions.

There are several companies vying for the lead in next-gen IGA, including Opal, ConductorOne, Noq, AccessOS, Zilla Security, ClearSkye, Pomerium and PlainID.

Collision course

The directory, and its subsequent expansion into SSO/federated access, possesses the most gravity of any object in the identity solar system. It is the most strategic piece of real estate, and therefore it’s a planet that many invaders have looked to conquer.

As new solutions like PAM and IGA emerge and enter the vicinity, they’re immediately set on a collision course with Directory. Indeed, every major directory product (Microsoft, Ping, etc.) has expanded — first into federated access, then to privileged access or identity governance. Federated access (SSO) has become so synonymous with directories that you basically never see a commercial product without having both, which is why these products are now called identity providers (IdPs). They keep track of the identity (directory) and then let apps and systems verify those identities (federated access/SSO).

A similar melding is happening with PAM and IGA, which have each overlapped with the other for several years and are converging. IdPs are still largely an IT tool, while PAM and IGA are more security-focused, which makes it hard to build a unified suite covering all three areas. The exception would be Microsoft, which is selling gigantic software deals into both IT and security.

Chapter 4: Active Directory Dominance

Microsoft evolved its core AD offerings from 1999-2005, sensing the expansion opportunities in identity. AD started as a domain controller and directory that stored critical information about users and their credentials. By the time Windows Server 2003 launched, Microsoft had added SSO (federated services), LDAP support (easier admin of apps at the expense of infra), Certificates (public key certificates that developers use to encrypt data at-rest, in-transit and sign documents/messages) and Rights (basic DLP on Office and email messages).

Despite the additional products, the AD experience wasn’t great. Reddit users on /r/sysadmin still lament the downfall of Netware to AD today, a testament to the crufty experience of using AD. For one, manual workflows for provisioning and deprovisioning were becoming untenable. Changes were and are hard to make because there’s no easy way to predict, account for and test the various requests a user might make before pushing it out to the whole system.

Secondly, AD wasn’t built with third parties in mind. Windows had a lock on the enterprise operating system market for end-users, but not servers (where Linux dominated), or Web (where Java-based web apps abounded) or mobile (where work was done on Blackberry and Nokia/Symbian). The walled garden was opening its gates, and the modern world was being rebuilt on integrations (MuleSoft started in 2006). Stitching together different protocols, data formats and auth mechanisms was cumbersome and costly in AD, calling for more software, servers and storage. Companies threw more people at taming Frankenstein’s Active Directory, but there weren’t that many who were skilled in managing AD.

Despite all of that, you couldn’t just get rid of AD. Migrations were long and fractious, and the directory is so baked into business processes that dependency management is migraine-inducing. Imagine pushing a change to the marketing group and the printers stop working in the office. That’s what admins deal with. The same year as MuleSoft was founded, AWS launched its first cloud service, EC2, and identity began marching towards federating in the cloud.

Chapter 5: Federation in the Cloud

Talk to most enterprise product managers and they’ll tell you that migrating existing customers from an older on-prem product to a new cloud product, even when both are supposedly at parity, is one of the hardest jobs you can have at a SaaS company. Atlassian went through it with Jira, Adobe went through it with Creative Cloud and Microsoft went through it with AD.

Todd McKinnon and Frederic Kerrest were Salesforce veterans. Each had been at the company for five years before leaving in 2009 to start Okta. They had three unique insights:

1. On-prem identity tools were becoming bottlenecks for teams, creating tons of manual work and slowing the pace of business as employees brought in newer, better software.
2. Cloud apps were held back by brittle identity systems. A cloud-native approach could help these apps realize their full potential as the world began embracing the cloud.
3. Microsoft, when it realized this, would have a tough time getting its customers to migrate to a cloud version of Active Directory.

And so Okta started in 2009. Technically, Microsoft already had a cloud directory product in Azure AD, which launched in 2008. But users basically had to start their directories over to use it, since it wouldn’t work with on-prem AD until AD Connect (which followed AD Sync) was launched in 2015. That meant from 2008 to 2015, AD was really only useful for smaller tenants since they didn’t already have a complicated directory. Best-of-breed cloud apps also emerged in the early 2010s, so contemporary startups had a lot of cloud SaaS they wanted to bring in, and didn’t have a lot of ways of securing user access to those apps. These two dynamics created a prime opening.

Okta brought together insight, timing and a wide-enough opportunity. It started converting the world away from on-prem directories towards cloud directories. When Okta went public in 2016, the company had 2,900 customers with “millions of users”, 5,000 integrations, and $111.5 million in ARR, growing 90% YoY.

If you come for the king…

Microsoft was coming out of a long period of stagnation in 2014 when Satya Nadella became CEO, renewing excitement among Microsoft shareholders. He was on a mission to shed the company’s Windows-centric image and instead embrace the cloud. Client operating systems wouldn’t matter in a future where every app and experience is delivered via a cluster somewhere else. The Azure AD team released AD Connect in 2015, finally providing an easy way for admins to get their on-prem directories to talk to Azure AD in the cloud.

Just two years later, in 2017, Azure AD was being used by 90% of the Fortune 500, with 56,000 paying organizations (+74% YoY), over 150 million monthly active users and over 300,000 third party app integrations. In other words, within two years, Azure AD added ~10x more users (give or take), and had 20x as many paying organizations as Okta had won in seven years. To be fair, many of these orgs were likely inaccessible to Okta to begin with, but it highlights the power of distribution. Microsoft had four times as many on-prem users it hadn’t even converted yet, and could migrate anytime (easier said than done, but still, it’s basically future revenue if the migration is handled well).

In reality, the migrations were hard and messy. Companies moving from AD towards Azure AD might have a transitory state where they manage both, as they slowly move users from one to the other. Many legacy companies are actually here right now in 2023. Managing both introduces new complexity. Another challenge for migration is that most modern tech companies started on Google for access to the Google Suite (Calendar, Email, Storage, Docs, etc.), which made Google Cloud a powerful IdP in its own right.

Redmond’s cloud conquest

Microsoft expanded its identity product portfolio rapidly as its own Azure Cloud business grew. Just as Okta had a finger on the pulse of which SaaS apps were growing fastest, Microsoft Security likely learned a lot about customers’ challenges with scaling on the cloud.

Entra was a new name given to Azure AD and Microsoft’s broader suite of identity products in 2023. Judging by pricing, the most expensive features of Entra are entitlements management (CIEM), privileged identity management and governance. Notice the free tier, which offers:

• SSO
• Role-based access control (RBAC)
• Synchronized user provisioning (SCIM)
• Delegated administration
• Multi-factor authentication
• Passwordless auth
• Basic logs with SIEM connectors

This is generally great for the software industry; SSO, role-based access and basic security are not features that ought to be gate-kept behind an “enterprise” tier. Those building products that compete with any of Microsoft’s, though, are unlikely to win based on budget friendliness for security or IT.

Microsoft’s identity portfolio expanded along five new vectors, each of which faces an onslaught of startup and scaled competition.

Mobile device management (MDM)

Bring Your Own Device (BYOD) policies of the 2010s ingrained personal and corporate mobile devices into the fabric of enterprise work. Windows Phone missed the boat on this one and was a well-documented disaster, but Microsoft Security was on top of the shift to mobile with the launch of Microsoft Intune in 2010.

Since its launch, Intune has grown as a joint endpoint security and identity solution for devices being used for work. MobileIron and AirWatch were two other startups that grew to scale and were subsequently acquired by Ivanti and VMWare, respectively. MDM solutions empower admins to set policies for how authorized users could use their devices – from the apps that are installed on them, to the data they exchange, to the networks they communicate on.

In 2023, classic MDM isn’t really a growth market. Most people have one or two phones and a singular corporate identity that they use on them. The emergence of powerful ML models that can be run on edge devices (like phones) is an interesting thought experiment for the future of endpoint protection. As more signals are collected on-device, we expect to see adjudication and risk-flagging happening closer to real-time on managed devices.

Innovation at that intersection has been focused on fraud prevention and continuous monitoring with companies like Infinipoint, BioCatch and Kandji.

Customer identity and access management (CIAM)

CIAM is identity management for external customers with fraud prevention baked in. Users can extend IAM primitives (directory system, password management, policies for authorization) to a customer account and treat a customer like any other external account (contractor, consultant, partner). Many of the enterprise IdPs have expanded beyond enterprise identity management to customer identity management. Examples include:

• Okta (Auth0 acquisition for $6.5 billion in 2021)
• Microsoft (Entra ID for Customers)
• ForgeRock (Customer Access Management, now part of Ping Identity as of August 2023)
• Ping Identity (with an existing offering predating the ForgeRock merger)

There are three key differences that make CIAM unique:

1. Customers usually create and manage their accounts themselves. They might forget passwords more often and issue reset requests from anywhere in the world. They will churn if an authentication flow has too much friction.
2. The way someone creates an account isn’t always the same. They might need to be landed somewhere else in-product based on how they signed up, they might be shown a different signup flow based on any known attributes, they might be prompted to link to consumer identity via a Facebook or Twitter account, etc.
3. Developers generally are the users of CIAM tools, not IT or security. Developers own the user-facing authentication flows in-product.

Auth0’s approach was to be the most developer-friendly. Others have embraced security, promising lower account takeover or fraud rates. Still, others have embraced compliance teams since these products also collect and manage consent to store cookies in response to regulations such as CCPA. The category has embraced “continuous adaptive access,” where a range of signals are collected off the device, browser and network and used to make a judgment on trustworthiness. The authentication flow changes in response. These differences make CIAM easy to understand, but hard to implement.

If a user is on an uncommonly seen network, they might have to answer pre-selected security questions. If they are logged in from Cupertino one minute, but Shenzhen the next, their account might be frozen for a day. Building out the logic for these flows and other edge cases, is complex work whether you do it in code or via drag-and-drop workflow builders.

CIAM is a fairly large opportunity for at least one simple reason: There are many more consumer accounts than there are enterprise ones. Goldman Sachs estimates that over half of Okta’s revenue in 2026 will come from CIAM instead of enterprise, a more than $1.5 billion ARR opportunity.

Because of the numerous angles of competition (better fraud prevention, more developer-friendly, more automated workflows, customer-friendliness) there have been several companies innovating in CIAM. Notable ones include Stytch (Contrary is an investor in Stytch through one or more affiliates), Transmit Security, Descope (ex Demisto team), Clerk.dev, and FusionAuth.

Machine and workload identity

So far, we’ve just talked about managing human identities, but there are 45x more machine identities than human ones!

Historically, IP addresses were used as the basis of machine identity. If a host is communicating on a trusted IP, great, it could be given access to what it’s asking for. But this doesn’t really work anymore for a variety of reasons, like remote work, network address translation, VPNs, etc. So instead of the indexing on an IP address, we have to identify the specific workloads (e.g., processes) that are running on various machines and keep track of those identities.

The SPIFFE framework creates an ID for each service/workload, signs that ID with an x509 certificate and then provides an API for callers to verify the workload. This is important for secrets management — instead of injecting secrets into the process at runtime, or keeping track of secrets across workloads, or passing secrets back and forth, it’s possible to just request and retrieve the right data from the right services.

These certificates are long-lived; they don’t change or go away over time, which creates risk of certificate hijacking (someone impersonating your safe workload with their bad workload). It’s ideal to issue short-lived tokens or certificates and rotate them often. It’s relatively hard to make this work across all of the microservices and processes that might run in a company’s service fabric, and there have been costly certificate-related outages and breaches at companies such as LinkedIn, O2, Microsoft Azure and Equifax. We’ve seen various companies build out their own public key infrastructure, like Airbnb’s Ottr, or use companies like Spirl or Smallstep to help developers and security teams manage workload identities more automatically.

Once a company knows who (which workload) wants access to what (the data requested), they also may want to control the circumstances surrounding their access. It’s fine for a microservice to make a write request to a bank API, but not if that microservice has been compromised. The hyperscalers (GCP, Azure, AWS) have robust workload identity products that handle attestation and authorization on a conditional basis for apps within their clouds and outside, with workload identity federation. Think of it like SSO for workloads – the cloud provider will authenticate the workload with whichever identity provider is already being used to verify its integrity.

One example is Venafi, which partners with Hashicorp to offer x509 issuance and automation. Microsoft charges $3 per machine identity/month, which could be a massive incremental revenue opportunity for the company.

There are several companies building modern ways to handle machine identity management, including Aembit, Astrix, Valence, DoControl, Teleport Spirl, Andromeda Security and Smallstep. Some of these companies focus on integrations between apps by extending identity threat detection and governance to API keys, OAuth tokens and more, while others maintain secure gateways that infrastructure services use to communicate with protected applications and services.

Cloud infrastructure entitlements management (CIEM)

As mentioned in the previous discussion about privileged access management, any user who needs access to cloud infrastructure is technically a privileged user. This includes every engineer, from the wizard architects to the interns that ring up wild querying costs because they never learned LIMIT 10 in SQL. As the cloud providers have added functionality, there are over 5,000 unique entitlements (e.g., permissions) that an engineer can have across these cloud providers, but over 95% of accounts use less than 3% of the entitlements they are granted. CSPM tools like Wiz can flag IAM policy gaps but don’t go deep enough to handle cloud entitlement lifecycle governance.

CIEM tools are emerging to fill the gap with automatic permission right-sizing (revoke unused permissions from privileged accounts), anomaly detection and analytics. These products also help admins with policy refinement without interrupting the developer workflow (can’t miss what you should’ve never had!). Resource graphs are a popular construct in the CIEM category, where all access paths are traced and connected via a graph to answer the questions, “What can this identity do within my cloud?” and, “Who can access this cloud resource?”. CloudKnox was a dominant company in the space and would allow users to request entitlements back once removed, enriching historical analytics with behavioral information to prevent revocation as easily in the future. CloudKnox was acquired by Microsoft in 2021, after which it was rolled into the Entra suite.

CIEM tools, like CSPM tools, identify policy drift across an entire IAM apparatus and, unlike CSPM, dynamically reconstruct and edit group memberships to better reflect usage patterns within the organization. CIEM and workload identity are converging with PAM and IGA, so it’s rare to find a vendor only doing one without plans to expand into the other areas. Microsoft ostensibly views CIEM as a non-commodity, since CIEM features comprise much of the advanced security functionality customers get when upgrading to the highest-end Entra plan.

Many of the CNAPP (end-to-end cloud-native app protection platform) vendors see CIEM as a feature of their existing suites. Zscaler, Wiz, Palo Alto Prisma and several other cloud suites have CIEM offerings. Ultimately, whether a user has visibility into the container runtime (e.g., Sysdig, Upwind, etc.) or the cloud’s overall posture, they’re collecting a ton of container and cloud logs that can help answer the question of who is accessing which resources, and whether or not they should be. Doing something about it still seems to be in an identity product’s wheelhouse.

CIEM is effectively an evolution of PAM, and some of the companies building in CIEM include Abbey Labs, CloudKnox (acquired by Microsoft), Obsidian, Sonrai and Ermetic (acquired by Tenable).

ReBAC, not RBAC

RBAC, or role-based access control, is when an employee’s role (determined by the groups they’re part of and various templated roles provided by their identity provider) determines the apps and services they have access to. This is how the world has controlled access since Novell, and continues to be the Microsoft view. Increasingly, as infrastructure sprawls and the web of apps and services users want access to increases, a new authorization framework is being adopted: relationship-based access control, or ReBAC.

Graham Neray, and the team at Oso, have written a great explainer on ReBAC. This was the example they outlined:

“Suppose we want to evaluate: is Alice allowed to edit the Anvil repository? We first find all relationships Alice has with the repository. We can now do this by walking over the graph, and finding all paths.

The data we have represented in the above graph is:

(Alice, admin, Acme)

(Acme, parent, Anvil)

(Anvil, parent, issue #412)

(Bob, guest, Anvil)

(Alice, owner, issue #412)

We start with any relationship starting with Alice, and traverse from source to target:

Alice -> admin of Acme

Acme -> parent of Anvil

Therefore, Alice is a maintainer of Anvil”

Google presented its approach to managing relationship-based authorization for massively online apps like Google Maps or YouTube in a 2019 paper entitled “Zanzibar: Google’s Consistent, Global Authorization System.”

The paper also presents a fairly generalizable framework that companies like Carta, Airbnb and Segment have replicated. The idea is to use data that already exists within an application. Think of Github: If a user opens an issue, that relationship is likely stored in an issues table with an owner field and is accessible somewhere in Github. If this kind of data can be fetched between various selected apps and services, and this can be done performantly with gRPC or fRPC, then the whole operation can be scaled up to more apps, more users, and more concurrent access requests.

Storing each relationship requires tons of relationship tuples. Google stores trillions to power Zanzibar. Each of these databases are cached and replicated globally in Google’s case. Zanzibar does not do any enforcement (this is instead up to the caller), but does provide a check function that can be used to prosecute a relationship.

Ultimately, ReBAC is a more actionable way of building permissions into an application. Identity is, among other things, a data problem, and it’s hard to pseudo-ETL permissions out of applications unless it is possible to easily model the relationships between the entities in those apps. Once app permissions are modeled this way, solving authorization challenges becomes a distributed graph traversal problem.

Oso, ConductorOne’s Baton project, Permify, AuthZed, Warrant, Cerbos, Permit, Styra and AuthDynamic all have frameworks for implementing and modeling Zanzibar-like permissions into an application.

Chapter 6: Identity Today

Microsoft has widened the gap

The identity market is in a weird spot today. There are more vendors than ever, each tackling important parts of the identity lifecycle. Nevertheless, over 60% of security leaders believed the space is consolidating as of August 2022. New, relatively underserved categories are emerging with CIEM and workload identity, yet many of the public companies in the space have been taken private, and the only cloud-native public company has been struggling with a wave of executive turnover. It seems the only constant is Microsoft, which began its reign in identity some 30 years ago and never stopped – Microsoft Entra now has 610 million monthly active users, making it bigger than LinkedIn, Twitter/X and Snapchat.

Identity is a fairly small drop in the security bucket for Microsoft, whose security revenue surpassed $20 billion in revenue in early 2023. AI (OpenAI), endpoint security (Defender) and cloud security (Sentinel) are undoubtedly bigger businesses, but Microsoft’s ability to cross-sell identity management to customers of these products (and vice versa) kneecaps competitor growth in the identity management category. Importantly, identity management is a core system of record that all other security businesses stem from. If you can identify a user, workload or device, then you can better profile their activities on the endpoint, on the network, in the SIEM or even in the developer supply chain. Logically, Microsoft’s other security businesses should perform better if users buy them after already being an Azure AD customer.

Machine identity management as today’s growth vector

The identity market has experienced four unscientifically demarcated phases:

• Phase 1: Access administration at the network layer (Novell) vs. the operating system/application layer (Microsoft), which Microsoft won.
• Phase 2: Identity governance, automated workflows and privileged access management, which produced winners like Sailpoint, CyberArk, Ping and ForgeRock, but Microsoft quickly adapted and released its own products.
• Phase 3: Shift the directory and identity workflows to the cloud, which Okta won until Microsoft started focusing on Azure AD migrations.
• Phase 4: Focus on securing machine identities and use ML to make just-in-time judgements on access requests to abstract away complexity. Several startups are vying for this prize and Microsoft is best positioned to have robust functionality here.

Phases 1 and 2 are ancient history. Phase 3 is coming to a close. The companies that were going to migrate their directories to the cloud have already done so, and the ones that haven’t have the most complicated or regulated directory footprints with vendors like RSA and Oracle. They are likely using the Office Suite instead of Notion and Teams instead of Slack, making them natural targets for Microsoft to go after.

Can Phase 4 sustain a big outcome, or will these products just become features of broader identity suites? Machine identities seem to be quite valuable, judging by their opacity compared to traditional identity directories, the growing complexity of cloud architecture and Microsoft’s per-identity pricing. It’s possible to see machine and workload identity generating an order of magnitude more revenue than traditional human IT-focused identity products have, but it’s also likely that the majority of that revenue goes to the cloud hyperscalers that are on both sides of the complexity (they build the complicated services, and they sell the identity products to help you tame the complexity).

Authorization historically has seen a fraction of authentication spend since authN precludes authZ. It’s unclear what would shift the pendulum, unless the way computer interaction works changes dramatically.

Chapter 7: Where Do We Go From Here?

Six blind men

There’s an old parable about six blind men happening upon an elephant in the forest. It goes something like this:

The first blind man, whose hand landed on the trunk, said, “This being is like a thick snake.” For another one whose hand reached its ear, it seemed like a kind of fan. For another blind man, whose hand was upon its leg, the elephant was a pillar like a tree trunk. The blind man who placed his hand upon its side said the elephant was like a wall. The one who felt its tail described it as a rope. The last felt its tusk, stating the elephant was hard, smooth and like a spear.

The elephant in the room is identity, and the blind men represent every company attempting to secure the symptoms instead of the holistic problem. A well-functioning, unified identity security solution is cataract surgery for the modern enterprise. This need arises from two key drivers.

First, whoever owns the directory owns the company. Full stop. If an attacker gains access to the identity provider, they can lie in wait and slowly create new roles, new accounts and new domains that will look totally normal to anyone reading an audit log. All the while, the attacker can exfiltrate data, edit permissions to view more data and wreak havoc.

Second, every other security attack surface would be better protected with a robust understanding of identity. For example:

• Endpoint Security: Endpoint protection evolved as it did (first with antivirus, then with threat detection and response) because it was never easy to reconcile who was doing what activity. Mobile device management, fraud-prevention and bio-authentication have fixed this from the IT team’s point of view, but this data is still hard to unify with endpoint data. So, instead, a large number of monitoring agents have been deployed on endpoint devices, with the average device now having nearly 12 agents installed, each with overlapping and conflicting datasets.
• Cloud Security: Every stage of the code to run-time pipeline would be enriched with identity information when tackling cloud security. Which developer wants access to which resources, pushed which lines of code, integrated which GitHub actions, etc. But it’s still not easy to manage privileged developer access across cloud infrastructure sprawl. The fastest growing products in cloud security, then, are catch-all CSPMs that bring visibility into hundreds of alerts happening in other places, with no context into who can access those vulnerabilities, and how to easily fix that.

Identity data needs to be part of a tight feedback loop, where it’s combined with the data streaming in from endpoints, APIs, cloud services, containers, etc., and then sent to some universal authorization layer to make judgements on the fly for whether something should be allowed to happen or not.

However, this is where physics becomes an obstacle: There’s not currently an easy way to do real-time enforcement without introducing unbearable latencies. Trending towards this future incrementally would mean handling enforcement for protected actions/resources, even slower than real-time (e.g., developers waiting 30 seconds when trying to spin up a cluster is better than waiting two business days for IT to grant an access request), while maintaining a far more enriched historical interactions graph to power future judgements.

The current generation of identity threat detection and response (ITDR) companies is seemingly building this future. Crosswire, as an example, uses proprietary IdentityGPT AI models to crunch data from a variety of sources (HRIS, UCaaS, IdP, etc.) before deciding whether an account is likely to have been compromised. A full suite that includes account protection, detection and response and also incremental authorization could be a very meaningful company.

Oort (acquired by Cisco) and Attivo Networks (acquired by SentinelOne) innovated in ITDR. Other startups doing great work in this area include Permiso, SilverFort, Spera Security and Authomize.

A long line of challengers

The problem for most startups is that it’s probably going to be Microsoft that builds this universal authorization layer, or even Google Cloud if it can successfully productize its security investments. If its not the hyperscalers, then Crowdstrike or SentinelOne have both signaled their interest in identity threat detection and response and have the data exhaust to power it. If not endpoint, then it’ll be Wiz and Palo Alto Networks, which have both built out leading cloud security posture management businesses with well-configured access policy that can solve many posture issues. If not CSPMs, then it’ll be the SASE vendors like Zscaler and Netskope, which already have robust private access businesses that are bleeding traditional VPN companies. See the Appendix below to see a feature comparison of the leading identity players.

Nevertheless, there are two advantages that startups enjoy versus all of these players. First, they’re not beholden to their part of the elephant and can zoom out to view the scene holistically to exploit gaps in the incumbents’ perception. Second, they can adapt to and build for the threat vectors of the future.

The future-proof identity stack

Based on our experience architecting security platforms and working with security leaders and entrepreneurs, here are a few beliefs about the future of the identity stack:

• Coverage will improve. The majority of apps people use, especially consumer and internal apps, are not SSO-friendly. Social logins are more widespread, but employees are either explicitly advised against using them or are hesitant to link a social ID to an enterprise tool for account recovery reasons. Companies like Cerby can RPA login and permissions information in and out of the app, giving users an SSO-like experience. What else can we do with these flows as vision models get better?
• Never build permissions. Security practitioners are increasingly going to stop building permissions into new applications. It’s a headache to maintain later on, and error-prone and risky to get wrong. Use tools like Oso, Warrant or Permit instead. Make the admins staring at your enterprise panels like you more.
• Let AI write IAM policies. Whether policies are expressed in Rego, OPA, Polar or something else, LLMs are particularly adept at learning new grammar and can express original authorization policies. We expect that IAM consoles will just integrate with LLMs to understand the context and intent of an enterprise identity fabric and generate IAM policies in concert with an administrator that makes sense for the company. For example, here’s ChatGPT creating a set of S3 access policies in Polar:

• ITOps will go next-gen. BigPanda has built a sizable business using AI to resolve outages and IT issues. We expect that more expressive models and AI data stack technologies (like Unstructured) will power an autonomous ITOps platform that can administer debug and monitor IT/security issues with minimal intervention.
• Verified credentials are preferable to centralized identities: In late 2023, Okta revealed that nearly all of its users were impacted by a data breach, outlining the problems with centralized identity. All major platforms – Google, Microsoft, Meta – present similar risk characteristics. A decentralized approach is needed where users govern their own identities, also known as self-sovereign identity. Microsoft Entra verified credentials are a good place to start, but not very approachable for the non-enterprise user.
• Retrieval augmentation is here to stay, but RBAC and access control on embeddings and vector stores is still quite hard, if not functionally impossible. LLM gateway approaches are quickly getting commoditized as underlying models work with enterprises directly or hosting and inference providers roll this functionality into their platforms, so there may be opportunity for a StrongDM kind of access player that works with vector stores and adjacent technologies needed in AI deployments.
• Agent identities will proliferate. Over the next decade, we expect human identities to begin dwindling in the enterprise fabric as people rely on AI agents to access and manipulate core systems of record for them. A lot could potentially change in response. CIAM would need to evolve considerably, as an example, to allow an agent to sign up for a new service or auth into an app, grab the relevant information and act on it. It’s likely that the leading consumer IdPs – Meta (Login With Facebook), Google (Login With Google) and Microsoft (Login With Microsoft/Github) – will launch their own personal agents that already know our access patterns and permissions. We will still need to empower them with access to new external information that lives outside these platforms.

Identity has become the new perimeter, and this has led to some disastrous consequences (according to a 2023 report, four out of five breaches started with an identity issue). To fix this will require a lot of innovation, both at the platform hyperscaler level and the individual product startup level.

Appendix

Feature comparison of identity vendors