I have been working in the identity industry for 25 years. My identity origin story starts, at least in a professional sense, in October of 2000 at a user provisioning company called Access360. We later went on to get our butts kinda kicked by WaveSet and got acquired by IBM to become IBM Tivoli Identity Manager.
25 years is generally accepted to be the “age” of a generation.
And I think we are experiencing generational change in the identity industry. Now to be clear, I am not so arrogant as to use my own time in the industry as the measuring stick for that generation. Instead, I believe the current generation started in 2001, specifically with the Enron scandal and subsequent Sarbannes-Oxley Act in 2002. Almost 25 years ago… and that combination of events has defined the current generation of identity. But assuredly as Gen X became the Millenials, this current generation of identity is giving way to a new one and it is this generational change that I would like to explore with you today.
Waking up
So in some regards we can think of our current generation of identity as a 24 year long hangover from which we are just awakening with a pounding headache and a fundamental question of “What the heck did we do last weekend?!”
There is a growing realization that we cannot do what we have been doing and expect different outcomes in a world that is remarkably different than it was 25-ish years ago. We cannot IGA any more vigorously. We cannot just expand our NASCAR CIAM login screen and expect better customer satisfaction. We just can’t.
Ok…. so if we can’t then, what does the coming generation look like? What areas will it expand into? What are its characteristics?
I believe there are 3 things that characterize the difference between the current and the emergent generation of identity:
- Pace
- On-behalf-of
- Proof and Portability
Pace
Identity’s piano only has 5 keys and one of them is broken. What do I mean? Well, let’s imagine that the opportunities identity has to apply one of its controls, be it create an account, or add an entitlement, or challenge for higher assurance, maps to a key on the keyboard. Whereas a full-sized piano has 88 keys, identity’s piano has 5 keys and, as I mentioned, one of them is broken. Now if you are a pianist who can only play 4 keys… you are probably not going to be the most sought after performer in town. You are definitely not getting coveted solo concertos written for you.
So what are the 4 keys. Well as I mentioned they are the opportunities for us to apply an identity control, which means they are:
- Join (and here I am including register in CIAM use cases)
- Move (and here we can think of this as changes in services consumed in CIAM cases)
- Leave (close account)
- Login/Verify (which also includes session creation, token issuance and, potentially token refresh)
That’s it. In the grand scheme of things, that affords us incredibly few moments when we can press the key, apply our control. In some cases, such as Leave, how often do you really get to press that key.
But I did say that we have 5 keys and one is broken, so what is the broken key? Any guesses? Logout. When was the last time you actually pressed a logout button? Actually, when was the last time you actually even looked for one? In browser tab-bound session tokens we trust, right? Yes maybe, just maybe you could rig a control in your session cleanup routines but that is far, far away from your IDP and your IGA is absolutely unaware of it.
So that leaves us with 4 opportunities to apply identity controls.
But it gets worse. Often those opportunities to apply identity controls are workflow-centric. They are mother-may-I human-in-the-loop identity controls. Consider what that human does… they validate that the request conforms to some sort of policy, whether that policy is formalized or not.
So what? It leaves identity both comedically slow to enforce crucial data protection and productivity enabling controls and when we do so, we still often rope in a human to figure out what is actually supposed to happen.
And if you think that pace is only relevant in workforce situations, you are mistaken. How quickly you are to meet the customer where they are in terms of experience and personalization will determine, in many cases, how likely they are to churn… or not. And I think we can agree that on the whole the time it takes to be recognized across all channels, in a unified manner, is far too slow…
The pace has to increase. Why? Well there’s a lot of reasons. On its surface, having a batch-oriented, infrequently-enforced set of controls is simply not acceptable today. But there’s another reason… AI. Adversaries are using it to orchestrate attacks. Enterprises are using it to reduce headcount optimize performance. Consumers are looking to delegate tasks to it.
In order to meet these needs and rise to these challenges, identity has to become faster. It needs to respond rapidly… in fact identity needs to be able to apply the right controls, enable the right personalization, and enable the right access in near real-time.
Ok so how do we do this? I believe the answer is deploying Continuous Identity. Continuous Identity (CI) is a generational shift that transforms how access is enforced, moving from static processes to dynamic evaluation of real-time signals and data such as business context, device health, and user behavior. CI is the evolutionary response to the fact that constraining identity controls to only join, move, leave, and login events is too slow and too infrequent for both the pace of today’s business and adversarial threats.
Continuous Identity is recognizable by its three major characteristics: Contextual, Consistent and Continuous.
- Contextual: Decisions and orchestrations are informed by business, security, and environmental contexts. Context isn’t an overly fancy name for attribute-based access control but instead describes meaningful information that has been out of reach of traditional identity systems but crucial to policies they affect. Knowing whether a person is on duty, whether they are working on a corporately managed device, whether a user’s behavioral risk score has changed, whether there is an open ITSM ticket assigned to them for a specific change request to a critical system - knowing these kinds of things turns inert “who has access to what” policies into rich, dynamic controls for today’s businesses.
- Consistent: Enterprise identity infrastructure is replete with policy silos and fragmented pieces of identity controls. What is needed are consistently applied policies that enforce the same control no matter where they are invoked, be it in a single sign-on flow, an access request workflow, an application’s custom authorization logic, or even an AI bot attempting to access a resource. The pathway to decision shouldn’t matter ideally - the policy and the context that informs it are consistently applied
- Continuous: As previously mentioned, identity is out of pace with today’s business; we need our identity controls to be continually enforced. When relevant context changes, when a risk signal is received, when an application raises a red flag, identity systems and the rest of the application stack those systems influence need to be aware and to act… orchestrating a series of actions from terminating sessions to instructing an IGA to deprovision privileged entitlements to messaging the incident response team. Why do all these things? For the same reason we do defense in depth. Security is fully comfortable for deploying multiple controls to mitigate a risk; identity must do the same. It is not sufficient to terminate a session and think the adversary is done for the day. These reactive controls are married to preventative ones that are consistently applied throughout the identity fabric.
The ultimate goal is to achieve zero standing privilege combined with just-in-time access, experience, and remediation. It makes good on our zero trust promises in which we never trust and always verify. Verify doesn’t mean re-authenticate; it means validate that access is appropriate given the current context. Continuous Identity moves us beyond using things like access certification as an audit and access safety nets by leveraging real-time signals to adapt access and experience.
How then do we address our problem with pace? How then do we achieve Continuous Identity? Where should we start? I’ll propose three places.
First, leaning into opportunities to deploy just-in-time access (as opposed to just-in-time provisioning) as a means of achieving zero standing privilege. If you only do one thing I recommend in this talk, do this. Zero standing privilege is identity’s key contribution to an overarching zero trust architecture. And modern infrastructure is increasingly amenable to supporting ZSP… we must take advantage of it!
ZSP turns some of our tried and true practices on their heads. In a workforce setting it means going from an access request and review-driven process to a world where there is no more user access review. Instead we focus on the conditions of eligibility to an entitlement and governance of the policies that express those conditions of eligibility.
In a ZSP-centric world, birthright access should be kept to an absolute minimum. Great news is that platforms like AWS support full ephemerality of both users and their access. Platforms like Salesforce support session-elevated and session-bound privileges. Furthermore, we have the opportunity to build the same kinds of behaviors into our customer-facing apps and platforms.
The biggest challenge as we lean into ZSP is getting Audit to come along for the ride. This is painfully true with workforce and I suspect it is similar in our customer-facing identity deployments as well. The auditor’s response to SOX is part of the reason that the current generations approach has been so deeply ingrained… the auditors reinforced practices like RBAC and user access certification. But they can and will change… with our help.
Second, look to infuse context-aware policies into your existing identity architecture. Whether it is risk scores or duty rosters or the presence of an ITSM ticket or endpoint security posture information or the awareness of new product bundles… that contextual information can dramatically enhance the efficacy of your existing investments and the experience of the individual.
Context can take many forms. The current generation of identity policy typically looks at three things: subject, resource, action. For example, taking a workforce example, DevOps users (subject), can access (action), this AWS instance with this IAM role (resource.) Your IDP can enforce this policy. The IGA system can enable this policy. But the reality is that that isn’t actually the policy we want to or need to enforce. The real policy is as above so long as PagerDuty shows they are on duty, there’s a Jira ticket assigned to the user and specifies the AWS instance, and the user’s risk level is low in Crowdstrike. That’s the actual policy we really want to enforce. And notice it uses both security and business information.
But what about CIAM and consumer-facing use cases? Well as I mentioned context is the key to recognition. Now I fully understand that we are not going to see recognition engines replace our authentication services any time soon, but the same kinds of contextual information that would feed a recognition engine can go a long way to improving session management. Threat intel signals, device identification, IP intelligence all are amazing sources of context, are rarely aware of one another, and are too often only used on login. Furthermore insights gleaned from customer data platforms such as customer sentiment and total lifetime value should influence the customer journey and often it is the CIAM system’s job to relay that information to the customer experience engine.
Lastly, put in place continuous safety net policies before tackling preventative ones. One of the easiest ways to move an existing identity fabric towards a more modern one is by leaning on that 3rd C of Continuous Identity and orchestrating what happens when certain events occur. For example, when you see your endpoint protection system raise a high severity incident, then automatically tell the IGA system to remove highly privileged entitlements, add the user to a remediation group, and open a case in the ticketing system with the relevant information to get the user back to good. Similarly on the CIAM-side of the house, when you receive a fraud signal spike implying an account take-over for a specific user, set their account to require two separate authentication factors and block credential changes for 24 hours.
These controls are reactive ones. They can be thought of as air bags in your car. You don’t use them to stop at stop signs; they prevent the horrible from happening. An identity in depth strategy and a modern approach ought to have these sort of air bag controls of last resort.
However they do not need to be so dramatic. Detecting that an individual has achieved a new certification in an internal learning management system, might drive provisioning of new entitlements without having to wait for a weekly batch reconciliation from the LMS into the IGA.
The generational change we are beginning to witness is one partially defined by pace. Our identity fabrics must become faster to respond and able to constantly apply controls. The new generation will be one of Continuous Identity.