Name: Episode #1 | Continuous Identity fundamentals: what it is and where to start
Uploaded: 2025-08-21T18:08:02.817Z
Duration: 47 min 40 s
Description: Episode #1 | Continuous Identity fundamentals: what it is and where to start

Transcript for "Episode #1 | Continuous Identity fundamentals: what it is and where to start": Okay. Here we are. Welcome. Here we are. Welcome to the official launch of, Continuous Identity Sessions, where we're gonna connect the brightest minds in identity with some strategies and real world approaches to make IAM work better. I'm your host and generously generally curious technology security. So generously curious. Don't don't think so. As well as general, Dustin Abel. I, am also director of market strategy and partnerships at SGNL. And in these sessions, we're gonna sit down with the people building, managing, dealing with identities at enterprises. The ones who figure out, like, how do we get through these issues? How do we reduce manual work? How do we automate? How do we actually improve business agility and security without being a burden to that business? And for those of you who are joining live, welcome. Thank you. Please use the q and a panel. We'll try to tackle as many questions as we can towards the end of the show, and there will be a follow-up to everyone that we, don't have time for today. If you subscribe, there will be follow-up emails as well. So let's get to today's topic. Since it's an introduction here, they'll launch episode one on continuous identity. This is the continuous identity session. So let's figure out what the heck is continuous identity? Where does it come from? And how do we even, approach adopting it? So my guest here, who you see joining the screen with me, is Ian Glazer, chief customer and strategy officer at SGNL. Hi, Ian. Hey there. Little bit of background on Ian. And, correct me where I'm wrong and jump in and cut me off if it makes sense. Yeah. Can I make up better stuff too? Is that an option? I mean, it's it's it's pretty good, I think. So I don't know how much better we can get. I'm on Mike. So Ian has a a long standing career, very visible in the community, digital identity, seasoned product leader, has been a founder, an advisor, product exec, both at Weave Identity and Salesforce. And early in his career was a research VP in identity and privacy strategies at Gartner, so on on the industry analyst side as well. But some of the work that I think is probably most evident in the community is as a board emeritus and cofounder of IDPro, which is a professional association for digital identity management, as well as a board member and cofounder of the Digital Identity Advancement Foundation. He blogs. He speaks. He's front lines and and speaking with customers and has some sort of fascination with SOX that we'll get into at some point. So so, Ian, thanks for being the first guest of, Continuous Identity Sessions. How are you? I love being the first one off the diving board. What can I say? Great to be here. What have you been up to lately? I mean, there's been a lot going on in the industry in where have you been? Where are you from where are you calling from today? Right. So today, I am in a little town of Hinton, Virginia, just outside of Harrisonburg. If you've ever heard of James Madison University, Got a place out here, and, I'm actually in my newly outfitted office. I'm feeling good about that. But, usually, you can find me in DC, or more likely and more recently on an airplane. That seems to be the current vibe. Have you been, hitting up some of the events in the industry lately in the first half of the year? I know we had a couple weeks ago. There was some Yeah. First half. In Vegas. Yep. Was that black hat? This is my first year that I was not at Identiverse. I missed exactly one Identiverse, and I've now missed exactly one cloud identity summit, which is the thing that became the or Identiverse. So, otherwise, European Identity Conference, places like that, but also just, trying to, where opportunities arise, meet up with, identity community around the world. So I had an opportunity couple months ago to do that in London. I'm looking forward to doing it again next month. So, yeah, just trying to be out and about. It's it's great to have you here. I couldn't think of a better, you know, thought leader to have on the first episode of Continuous Identity Sessions. And before we get into Continuous Identity and what it is and and what it means, Maybe you could give, the the audience a quick sense of what you're doing now, your current role, what what sort of identity challenges you're working with. So as you mentioned, I'm overseeing both customer sort of experience. That means delivery, training, support, all of those aspects of our business, as well as product strategy, as well as analyst relations and product marketing, and there's probably a couple others. But the cohesive aspect of this is there is a virtuous cycle between customers and strategy, and you can't have one without the other. So that sort of comes together underneath me as well as the way we talk about what we do, how we talk about it internally, how we express relatively relatively speaking, complex topics to one another, to the market, how our customers then take those messages and sort of talk amongst themselves in their own businesses about what can be, in some cases, feel like. So, again, really complicated things that end up being actually pretty simple. When you sort of reframe them, and making sure that they are delighted in that journey and that they're delighted with the experience they get as they use their products. So that's sort of my remit. And the way I joke about what my role is is I'm a lawn sprinkler. I sort of water different parts of the business, and I sort of rotate through the business. And as things are growing well, I can, you know, sort of focus there. When we things need more help, I can focus there. But, you know, fundamentally, I'm a lot sprinkle. I can appreciate that. Put put a little bit everywhere. Sprinkle it up. Yep. I mean, speaking of that, like like I mentioned in your intro, you've been a product executive and and product manager and product strategist and builder and practitioner. However, there's also this other side of your of your career, if you will, that's really about building the identity community. You literally cofounded ID Pro and helping what you just said, like, some of the communication to take place between folks in the community maybe that are wanting to learn, maybe that have done it before. What sort of drives that? How did that get started, and and why is that an important channel for you? I I think it's sort of two parts to that story. One of them is the personal desire I have to make future practitioners journey through this industry easier than my own. Gotta understand that come October, I'll have been in this industry for a shocking number of years. Certainly shocking to me. And when I started, which was twenty five years ago, there weren't the kinds of opportunities to connect like there are now. And so that meant learning this practice was hard. You you often learned a very single product, and then maybe you learned a second product, and you realize, oh, wait a minute. This is kinda part of the same domain. But the resources we had to learn about this more globally, let's say, our own experiences globally, was primarily blogs, and, you know, random website articles. Message boards? Gotta be what's that? Message boards? Yeah. Also that. And then, you know, maybe some text driven things, maybe some IRC channels. You know? But one of the things that started to occur to me was asking the question, how long did it take you as a practitioner to become productive as a practitioner? Right? Like, how long did it you know, you come up to speed, if you will. And I started asking this question of customers and their organizations. Like, hey. How long does it take you to train a new identity person for your team? I did this all all around the world, and, you know, I get answers like, well, it takes, if we're being honest, eighteen months. Is that acceptable? I'm like, no. Absolutely not. Like, it can't be. Right? And this is back a while ago. And the other thing I asked was, you know, what are the opportunities you have to get back to one another, and how aware are you of the community around you? And one of the, really crystallized in my mind was I was in Germany. I was in Frankfurt visiting a customer and asked these questions. And we took some of these questions to a mailing list that we had had around some of this and said, like, hey. If you could meet with one another, you know, like, do you know of communities or meetups or what have you near you? And two people responded from the greater Frankfurt area and said, nope. Nothing exists. And I know no one of my practitioners. I'm like, but but you're kilometers apart. Like, this seems like a problem screaming out to be solved. So I started going around and asking people, like, do we think that it's a good idea if we could, I don't know, like, build a community where people could connect and maybe get back and learn from one another and have some vendor neutral training materials? Like, could we actually make this easier? And everyone's like, yeah. That that that's a good thing for you to do. And I was like, oh, I did volunteer for that, didn't I? Yeah. And that became, like, the early, early origin story of ID Pro, which is fundamentally two things. One, how do we make our practitioner's journey towards excellence faster and easier? And two, how do we afford people that have been doing this a while the opportunity to give back? Because I think, fundamentally, no matter what industry you're in, no matter what walk of life you're in, you are looking for a way to contribute to something bigger than yourself, and I wanted to give an opportunity for that to happen inside of this industry. Great. I love that. I love the the giving back and the full cycle. And in in industry terms, I'm gonna use this into a segue here and say, yeah, and say, you know, this is the type of thing, the community building, the education, all the connections that you were talking about. You can't just do it once. Right? You don't do it once and then walk away and expect that it's done. It's this thing that has to be done repeatedly, or one might say continuously. So so we're talking about continuous identity. Let's let's just dive right in. It's one of those terms that comes up occasionally, starting to be seen and heard more often, especially at, industry events and in online and other places. And as per usual, it can mean different things to different people. So let's let's start with the basics. How do you define continuous identity? Sure. Let's I'm gonna work my way towards that. Sure. Yeah. Let's start with a growing realization that we've been kinda doing the same thing for about twenty four years in this industry. We the practices that we have put in place are heavily, heavily influenced by the Enron scandal and resulting Sarbanes Oxley legislation. So we've been doing a lot of the same kinds of things post Sox. And the best way to think about how that works today is to think about our piano, which is not an obvious statement. Bear with me. Grand piano has 88 keys. Cool. Identity's piano has five, and one of them is broken. Now, first, what are these keys? Well, these keys are an opportunity to apply an identity control. So, for example, create an account, add an entitlement, create a session, challenge for strong authentication. So sort of the things that identity systems can go do. K? So if each key maps to one of those, we have five. One's broken. So those map to essentially join. Right? The joiner mover lever function. So so those are three of the four working keys. And this is true, by the way, for both workforce and in more consumer citizen facing systems. The moment that someone self registers, that's an opportunity to apply identity control. When someone changes job roles or they, buy a higher level of service from you, that's an opportunity to change the kinds of things you can do or they should be able to do. When an individual leaves the organization, when they close their account, like, this too is a place where we can apply identity controls. Now the fourth key is login or verify. That moment of, like, hey. I wanna know really to some degree of strength, this is the person they claim to be, and it's the same one we saw before. Now we can also include in there when I issue them a token or when I issue an app on their behalf of token. So if we think about those those four things, the number of times we, if you go with the analogy, get to press that key in a day, it's actually not that many. It's not that many opportunities, especially compared to our security peers. Right? Our security controls, right, their keyboard, they have a lot more keys, and they can press them a lot more frequently. And that realization that the number of opportunities we have and the kinds of keys we can press is actually very limited. Now it worked for a while. Right? We certainly know how to do those things well, but it is comedically out of pace with both business and how it's expecting things to react, to be enabled for productivity, and to defend against adversaries moving again at a much faster pace. And so in some regards, when we start hearing organizations talk about continuous identity, when we start seeing this in the industry, really, I'd say it started around Identiverse this year. So back in June, the momentum's been picking up. It's in some regards a generational reaction to how we used to do things or how we're currently doing things, but acknowledging, you know, this is not gonna take us another twenty five years. Right? We can't keep doing those same things. So long way around, if that sets up the context, if you will, for it, like, continuous identity then is that reaction. Okay. Well, what does that reaction look like? Fundamentally, it is about getting faster, respond to different kinds of signals more frequently and applying more controls. It is the opportunity to use more of that keyboard and press those keys more often. So let's start with that, and let's let's see where that takes us. Yeah. It it reminds me of a blog that, sort of introduced CAPE, continuous access evaluation protocol at the time. I think it's profile now that Atul, Autosri Bagwali wrote, and it talks this term that I that I as again, not as a technical person myself, but a term that I could really understand and get my arms around was fire and forget. This idea of, you you know, you you access and then it's done. You you push that butt to your to use your analogy, you push the key and then you're done. It's there's there's not, like, another it's it's not, okay. Let me go back and check, and then let me go check again. And how's everything still still going? Excuse me. But but rather that one time action. So, you know, let me let me pick up some let me pick up something Justin. Because, like, you you you alluded to it there, which is the, you know, I I sort of do a thing, and it's isolated. Mhmm. Right? It's sort of an option in a vacuum. Yeah. And if we think about what organizations are increasingly expected to do, which is build a real zero trust architecture, that's antithetical. Like, those two things don't play well. Right? Zero trust architecture is saying, absolutely never trust. Always verify. Is this the right access in this moment for these kinds of things? If we wanna go towards that, if we're being required in some regards to go towards that, then we can't have a sort of batch oriented once every, you know, moment I have a press the opportunity to press a key, I can do it, but that's it. Like, those things can't live together. Right? So we need to be more continuous in terms of the ability to to affect identity controls, to bring those to bear not just at these major moments in the life cycle of an identity or throughout the productivity journey of a user during the day. But more continuous needs to truly say, yeah. We never trust, and we always verify. It's a popular term now speaking of of, you know, what we're seeing out there, what we're reading, what we're seeing smeared over materials, zero trust. There's other there's other hot button terms or or maybe growing, I should say, in popularity, like real time or just a time, just JIT. Is that continuous identity is it not continuous identity, and is there a line that's drawn between these types of things? Yeah. So here's what I would say aren't con examples of continuous identity. First thing, anything that puts the human in the loop for either an approval function or some other, manifestation of a control. Right? Human in the loop type mother, may I, policies or controls is really a reflection of the way we did things post SOX. Why? Because SOX was very explicit. Like, you've gotta demonstrate these controls, and you've gotta have essentially the fingerprints of someone on these controls. And so there's a lot of sort of workflow driven things that came out of that. Now the other sort of side effect of why or the reasoning why we would have a human in the loop is that one of the classic things is you ask for access for something. And we, as practitioners, did not know really what the end result was supposed to be. Right? Like, oh, I need access to this application. Not having enough data, not having enough context, we would kinda punt to a human to be like, I don't know. Like, what do you think is the right thing to do here? And that became the model after. Like, copy Ian's access so that Matt can have it. It became essentially the human in the loop to evaluate policy, whether that policy was formalized or not. So first thing that is an anti pattern, if you will, for continuous identity is anything that's got human in the loop. The second thing is anything that primarily relies on standing access, especially highly privileged entitlements, that's an anti pattern. Right? The idea is that we can affect our controls more continuously than at the moment of need. Again, especially for highly privileged actions, systems, and entitlements, just have that need met in that moment with that access and absolutely not before and absolutely not after. Right? When work is done, remove the access, I don't let it leave it around. So anything that is using standing access. And there's a couple ways this can masquerade. So for example, I may not have a session all the time in AWS. But you know how I get it? I just click the tile in Okta, and boom, I get a highly privileged session. No matter what's happening, no matter the state of my machine or the business or anything, if I can click that tile and always get a highly privileged resource, that's effectively standing access. It just has a different path to get there. That's not something that we're looking to do here. And then the last thing is the third of the three things I would say are anti patterns around continuous identity are anything that's not using real time signals. Now that to be let me be very clear. It would be great if everyone was using the shared signals framework, open standard, created in the OpenID Foundation, but but it's also realistic. Like, we're in a transitional period, so there's plenty of proprietary signals that you can pick up on and take action on. Examples. If suddenly your endpoint detection or response system suddenly hates a user out of the blue, you know, maybe we shouldn't keep all their entitlements assigned to them. Like, maybe we shouldn't remove those highly privileged things. Or, like, when we see that, an individual is rolled off of an active duty roster. Right? So they're off duty now. Maybe it's DevOps engineer. Unless there's some other evidence, should we really allow them to create a privileged session in, in our AWS environment or GCP environment? Should we let them check-in code to production right now? Like so these real time signals can be used to inform much more expressive and much more useful policies. And if you're not using them, then that's really an example sort of a previous way of doing things. We're, again, we're waiting for the opportunity like, oh, I'm gonna press the key. Oh, yeah. Gonna press the the move piano key. Yay. Like, we gotta do something better and signals are a path to do that. Yeah. I've heard you mentioned context, a couple times and and teaser, like, maybe a future continuous identity session focused around some of these contextual signals, if you will. And I'm reminded of this phrase that I will butcher, but this idea that you never stand in the same river twice. The river might look the same, but things have changed. Right? It's it's flowing water. And so you might go to click that that chiclet in your on your dashboard whether it talk to our entrar or ping or whatever your, you know, IDP might be, your single sign on provider, and you still have the same account. But there could have been things that have changed in in the background, and let's evaluate based on that. Yeah. You know, the one of the important things to realize and and, honestly, I grew up as a user provisioning person in this in this industry. And user provisioning systems, IGA systems, are as smart as the things they can connect to. They know the world about those things, but that's not the whole world. Right? And so one of the things that it took me a little while to realize the power of, and now I totally get it, is if I can reason larger than what I my specific identity system can connect to, I'm just aware of the world around me. I can do a lot more. I can make my existing investments a lot more valuable. So having a sense for, like, what's going on, that information is crucial to make decisions, but it has often been outside of the reach of our identity infrastructure. Or where we've had it, it's been extraordinarily limited, like a point to point integration between vendor x and vendor y. Right? Oh, I can get, ITSM ticket information, but only from Jira and not from Salesforce. Right? Like, that that doesn't work in a large complex enterprise. I need sort of ubiquitous sources of context that then I can read it against, and that's really, really powerful. You've spoken and and alluded to some of the tools and some of the approaches over the the past twenty plus years. It's not that organizations have not been attempting to solve these problems. They continue to invest, I think, in technologies in order to govern, provision, some of the other other things that you've mentioned. So I'm curious what's what's driving this shift? And maybe more specifically, in your role at SGNL, when you talk to customers, what might be the tipping point where they realize, oh, we've got a gap here, or we've got an issue that we need to address? So I think, inherently, people can grasp the the value that could be there. Like, man, if I could just spice up my SSO policy with the awareness of my EDR data. Man, you know, what would that do? That would well, that would allow me to maybe prevent future breaches. Why? Because I could say, look. If I see that your your system has been, is compromised in some regards, I really, really shouldn't be spawning up privileged sessions for you. Right? I wanna contain a blast radius. Similarly, that sort of realization of, man, just one other piece of information, duty roster information, what have you. Gosh. That's really powerful, or that could be really powerful, but I couldn't find a way to connect it to what I already had. So so sort of step one was like, wow. If I could just yeah. It's like you you you take someone to a place and say, look. If you could add one more piece of information that maybe you're asking humans right now to evaluate. What if you could do that in a more automated fashion? Light bulbs turn on immediately. And it doesn't have to be super complicated. It's like, oh, if I just knew if someone was on duty, wow. I can actually do a lot with that. Sure. So then the the tipping point side of it is an example I'll go back to is a friend of mine in the industry architect was saying, look. I can't squeeze any more access out of our access certification process. I just can't. Right? All I'm doing, if I'm being honest, is I'm burning a lot of FTE hours doing access certification. And I get it. There are regulatory interpretations of a requirement here, let's say. I certainly have an audit requirement around effective controls around who has access to what, especially for material systems, and this is sort of an expected control. But I gotta do better because waiting for an access cert to sort of clean up Aisle 2 if I have an access spill, that's not particularly timely. That's a long window of exposure potentially. But with the tools I have today, I can't go any faster. And it's moments like that where people are like, okay. Maybe it's time that we say we can't just keep drilling the same well different and expect some other liquid to come out of it. I've I've, I've seen I've heard a lot of audiences, and and maybe the virtual audience out there live and on demand is nodding and going, yeah. This makes sense. I mean, all these points are not sort of, argumentative in in folks sitting there and going, like, no. That wouldn't work for me. But rather, I'm wondering if we get practical from continuous identity perspective, all those opportunities you just mentioned, where does somebody start? How does somebody get going? Yeah. You're you're absolutely right. Like, this isn't on its surface, it's not contentious. Right. It's the, like, oh, great. What you're telling me is I gotta go blow all this stuff up that took me ten years, fifteen years to put it like, that's a nonstarter. Yeah. But I want this. How do I get it? Starting can be actually really, really simple. First and foremost is acknowledging and identifying, look, what one single spice, if you added it to this dish that you call your I'm infrastructure, would just make it better. You know, and some people say, you know, it's it's security related information. Right? Like, if I had EDR data or if I had some threat intelligence data or IP intelligence data, that could really go a long way. For other people, it's business conditions. Right? It's like, look. I have release windows, and I don't want people pushing to mainline production inside these release windows, and we don't have great controls over that. And it may be sort of more business process related, which is, damn it, we have a change management process. Why the hell can't we tie our identity system to it to make sure that someone can't do something like work in production when we don't have a log change ticket against it? Right? So the first thing first is like a that sort of realization. Now you can do that on pen and paper. Right? This is a non ones and zeros conversation. This is about a how do I take the the process that I wanna put in place and actually identify the data to make it happen. Step one. Step two is then look for a great place to apply the control for many people. That is, you know, for these kinds of systems, right, especially cloud native systems, they're pretty good about doing ephemeral access or just session bound privilege. I've been using classic IGA tools, for example, to manage access there. I've got hundreds, thousands of IAM roles that I seem to be statically assigning or time based assigning, and I've got risk exposure because of it. It. And I have to do access cert because of it. What if I could lean into the native capabilities of the systems that I've already got and just better inform them? Like, what if and, oh, you know, my IDP knows how to do claims enrichment. What if I could tell my IDP, let it reason about this contextual information without changing a single thing from a user experience perspective, but let it know, like, oh, hey. Based on the fact that the individual is off duty, this is the IAM role I want them to inherit in AWS. That is a really small but meaningful step forward. Yes. It's relying on login as a key. I fully acknowledge that, but but it's making it far more intelligent. It's making a far more rich decision that will go long ways to mitigating blast radius in case of misuse. And so it's the hey. What one or two spices could really change this dish? What one or two pieces of information really get me going? Two is, where's the most likely to be used control? Is it at the time of provisioning? Is it the time of single sign on? Do I have something that's continuously evaluating state so that maybe I can enforce some reactive controls when I see something change? And then just start super simple. Like, no one's got perfect data. No one's got even great data. People have, like, fine data, and that's just fine. Like like, embrace that. So, like, cool. I now can bring this one piece of information into the story without changing my infrastructure dramatically and certainly without replacing big ticket items, and I can get better. I can get better by reducing my need for access certification. I can get better by providing more ephemeral access. I can get better by minimizing my standing access. Those are really big wins to you as identity practitioner, to see your security peers, and overall enterprise risk. You are touching on some of the the, components in this framework, this four components framework that I think you've presented on in the past year or so. And and by the way, for those watching live, we have some resources linked in the docs tab on the right of the screen, and this is one of those resources, I believe, that the framework that includes policy orchestration, execution, and data. Yep. How does that help organizations better understand what they're missing? So end of last year, beginning of this one, I was really struggling with how to talk about the market because the names we would call functions have sort of drifted. So, like, what used to be, you know, single sign on or web access management is now access management with a bunch of things that live under it as an example. And it's it's hard to know what we're talking about sometimes. So I created this framework to help me better think about what capabilities do I have in sort of requisite components of my architecture, So policy, orchestration, data, and execution. What this framework allows someone to do is to say, okay. Cool. I have these kinds of capabilities from a policy perspective. And so, for example, like, I can create local policies around access, but I can't, for example, add contextual information. I just know about the subject and the resource I wanna protect. Okay. Well, good. That's that's what my current state is. Similarly, you know, I know how to orchestrate workflows and provisioning, but I don't know how to orchestrate with my security infrastructure. So it's an evaluative matrix or evaluative process to understand what capabilities we have, more tightly identify what's missing. Right? So an organization may say, look. I need the ability to do something really, really specific, like OpenID Foundation's, financial API, the FAPI profile, because I'm doing open banking. But the OAuth infrastructure I have doesn't support that. The execution part of it doesn't support that. Cool. Then I know exactly the the component I need to focus on. Would I gonna choose to build something or augment what I have, replace something? It helps narrow the focus to where's the real pain and need, and how do we then begin to address it? And so this is one of those places where that framework then says, look. You know, I I'm great in orchestrating inside of maybe my identity stack, but what I can't do really well is both take signals in a real time way from, say, some of my security infrastructure, and I can't then send signals to different parts of my identity stack based on that. I'm just missing the ability to pick up on this important security dial tone and then take action based on it. Okay. What does that mean? Well, now I wanna go augment maybe some of the capabilities I have in orchestration, or I wanna go see how I can get certain pieces of data. Maybe it's that EDR data. Maybe it's that pager duty data, what have you. It helps sort of focus and then decide what do I wanna do at that point? Want to remind the audience that we do have a a q and a tab, that you can add questions to, and we'll we'll get to towards the end of the episode, which is unfortunately rapidly approaching. But you you talked a lot you just mentioned it, Ian, this augmentation instead of replacement. You mentioned earlier when we were talking about sort of addressing existing I'm investments. What does augmentation instead of replacement look like? How how do organizations evolve their existing IAM investments instead of just saying, like, well, now I have to replace it. That that's the only option. Yeah. It can take a lot of forms. The the through line on this is gonna be adding some combination of just a little bit of contextual insight. Doesn't have to be a lot, but a little bit of contextual insight consistently and continuously evaluated can be applied in multiple parts of your IAB infrastructure. So if it's let's say, if we're focusing on our admin time processes, so on our IGA system, it could be like look. I think we'd agree that if someone has an open, cybersecurity incident with them or with their device, it feels like they shouldn't ask for more access. Like, it just feels like it's a bad idea to be like, by all means, sir, here's the keys to the kingdom. Like, no. Okay. Well, if we just use the tools we had, it would mean I would put up maybe an approval workflow for the individual. It would go to their manager or maybe someone in IT to swivel chair and look at the security system and be like, oh, hell no. Not that guy, not that laptop, And then make a decision. Can we just automate that? Because that just feels like I'm burning cycles. Like, that that that's just like a no brainer. So how do I bring that information to places in, like, an IGA example in my approval workflows, for instance? In my sort of run time or my IDP environments, this is one where now I've got a really great preventative control or the possibility of one, which says, I bring more kinds of information to bear. Like, oh, look. Ian wants to click on the chiclet for, Azure to go do something in the compute environment. And, oh, hey. You know what? There's an ITSM ticket assigned to him about a critical issue. It's open. It's active. It's it's specific to this Azure instance. Great. Let him on through. Otherwise, like, don't bother. Like because he's probably not had the second cup of coffee, thinks he's clicking on stage, he clicked on prod, and will invariably push a breaking change because have you seen the quality a's code, especially without coffee? Like, it's those kinds of things. Right? We're not even talking about, I've gotta defend against adversaries. I gotta defend against humans. Right? Like, misuse is a thing. It happens. So why don't we put some preventative controls in place to do that in our IDP? And then lastly and to me, this is actually one of the great places to start is, let's do a reactive control. Right? Let's say, look. When I do see that an individual is trending risky from a human behavioral system or an IDR system, then why don't I immediately tell my IGA, take away his highly privileged access, and put them into a remediation group, go tell my IDP maybe the same thing or it'll draft off the back of that action, but also open up an a ticket to help this individual get remediated. Right? Help them get on a better path. And let's do that as a reactive or a detective control. So as soon as we see something happen, let's get them on a path to better. And while we're doing them the path to better, we're actually mitigating future abuse. Right? We're gonna take away some of the most damaging things. We're gonna put them in a bit of an isolation, but not, for example, say, cut off all their access or deny them connected to the network. It's a much more nuanced approach, but it's really, really powerful. It's sort of an airbag for your IAM infrastructure for that individual. So you can have both those detective controls, like, or reactive controls that I just described when you see something happen, as well as the preventative. Like, don't let them in the front door. Don't let them ask for more access when certain things happen. Take all those things together, and you've started to build a really robust continuous identity system. Yeah. Once again, not super contentious. It makes sense. Ian an I let's say I'm an IAM leader. I want it everywhere. How how do how do we help these IAM teams to avoid that that sort of challenge that becomes like, well, I want this everywhere. What do I do? Like, it becomes this analysis paralysis. Man, the the the the siren song of automate everything everywhere is tied in memorial. Right? Like, that goes back to the provisioning day. Same same kind of story. So I want this everywhere. The first question to ask is, among the outcomes that you think you can get, what is the one that is the most attractive or the most sexy to upper leadership or the most timely based on new initiatives? Right? So I think it's first, focus on the outcome. What is that outcome? Like, hey. We have a real problem with, work happening in critical code lines or applications or what have you, and we want more change management governance around them. That's the top level mandate. Right? Like, maybe we had an incident, and we've gotta get better. Right? We just mature our processes. That's super timely. Like, hey. Identity team, you help out here? Traditionally, it's been like, maybe. Now it's like, of course, we can. Of course, we can do that. So focus on what that that sort of timely outcome you'd like to render is. Then it's look at what is the most effective place to put that control. Some people are gonna say for their use case or their outcome, they're gonna say, oh, you know what? If I just put if I raise the bar to entry at my IDP by infusing these three pieces of context, or I have this one piece of context, I'm gonna materially improve the state of play. And, oh, by the way, I may even have the opportunity to remove an approval process, making the individual's experience even better. Or, man, if I do this right, I bet I can get rid of a big chunk user access reviews. That's a super big way. Right? So it's what point can I put that control? It may be in my IDP. It may be in my provisioning infrastructure. It may be actually putting a new piece of of capability to do, say, CAPE, insured signals framework, to then orchestrate the existing framework that you've already got to go take actions. Let's focus on the outcome, pick a great place to apply and control, and start super, super simple. Like, you'd be blown away by one piece of context, what it can do for what you've already got. Okay. Yeah. I mean, it seems like a practical approach, which is what we're about driving here at Continuous Identity Sessions. We wanna talk theoretically, but really leave with some some actionable steps. So as we wrap up, a couple of a couple of quick hitter questions for you just to, better understand some some key components. One is, where can we find you in the real world in the next few months? So are you gonna be picking up, some some socks at these, at events? Or why why did socks become the the most popular and creative swag tool? I'm not sure. But, I don't know. That that was a thing. I had nothing to do with it. I appreciate it, but I have nothing to do with it. Alright. So where am I gonna be? Busy busy fall coming up. Super stoked to support the women in identity, at their yearly event at Capital One, in September, here in the DC area. So that's gonna be great. I'll be helping hoping helping to host, a identity salon in London. Hope to see folks over there. I'll be at CellPoint's Navigate conference in Austin and a September Authenticate in San Diego in October October. Yeah. Identiverse is doing some regional things. I'll see people in the DC area one. And then I think the last sort of sighting is I'll be roaming the halls at Gartner I'm in Dallas. Probably. I mean, there's probably a few others that I'm forgetting of, but those are, like, a good places you can go find me. Yeah. Yeah. That's it. Right. That's it. Getting back to sort of summarizing our our talk, if someone was watching the session and, you know, they they thought, again, this is great, but I can only really do one thing. What's what's one thing that someone could take away from this session from the last half hour or so and say, I'm gonna try to focus on this thing next week? I think it's the acknowledge that we're in the middle of generational change from a post SOX type approach, which is very batch oriented. I've only got four keys, press the key when I can, to there's something different, more continuous that's happening. And in that recognition, right, that an acknowledgment, then I would say, pick one piece of contextual information. Just one one interesting little nugget. And so, like, if I could infuse this thing into my IIM, what would it change? It'd be an ITSM ticket. It could be a duty roster. It could be security EDR. Just pick one. Do this as a what if exercise. You'll be pretty amazed at, like, what and that starts to point towards a real tangible use case that you can actually take steps on immediately. That that's great. I mean, I want I want as as we host these events and more upcoming, I wanna remind people to subscribe at signal.ai for these continuous identity sessions, but we wanna get back to the actual practicality and where folks can take this into their own organizations as they strategize. But final question for you, Ian, as as we look to do things continuously and to evolve, what's an example of something you've done recently? It could be a skill, a hobby, something that, you continuously maybe attempt. And and in the interest of fair play, I'll share that, not recently. However, every year, I continuously try Eggnog because I think I'm gonna like it. For some reason, I think that during the holidays, the context has changed to use some of the right? But it turns out, even though I'm a year older every year, still still doesn't do it for me. But I continuously go back and try again. So anything that you could share, again, it doesn't have to be something like that, but maybe something you've taken on recently. That has a sort of Simpsons esque, like, ow, quit it. Ow, like, sort of feel me. Yeah. Yeah. Exactly. This is this is actually not a new answer for me is I continually try to suck less at something. Right? It's really hard when someone says, like, you know, just get good. Right? Like, folk I'm gonna focus on excellence. I'm like, no. No. No. No. No. I'm focusing on, like, sucking less at things. So, like, most recently, I have been trying to suck less at mountain biking, and I am slowly achieving that. But that sort of mantra of, like, let's just do slightly less bad today at something, to me, is like a more realistic way of approaching getting really good at something. So Yeah. Love it. I love it. Well, thank you, Ian. Thanks thanks again. And thanks to everybody who who joined us today live and on demand. I don't think we have any questions. So either we, you know, knocked it out of the park on the first episode, or, or we're gonna get a lot of, that we can respond to on the on demand from the on demand nature. So another reminder, all these sessions are recorded and available at signal.ai and on the YouTube channel. So bang that subscribe button both on signal.ai and on the YouTube, and you get all the details for the upcoming episodes. I mentioned before some of the resources that we have under the docs link to the right on this model. And any tools that we mentioned or brought up, we'll we'll follow-up, in the subscribe. A little teaser that next time on the continuous identity sessions, we're gonna be talking with identity strategist, Felix Gaikens, on next Thursday, the twenty eighth. We're gonna talk more about specifically machine and nonhuman identities. For those of you wondering, how do we manage identities beyond just the human ones in your orbit, you'll wanna join us. So join us live and then on demand. And until then, thank you again, Ian Glazer. Let's continuously work to keep making identity work better. I'm Dustin Abell. We'll see you next time on Continuous Identity Sessions. Thanks so much, everybody.