#374 - Sponsor Spotlight - SGNL

This is identity at the center. Welcome to the Identity at the Center podcast. I'm Jeff, and that's Jim. Hey, Jim. Hey, Jeff, how are you? Oh, not so bad yourself. Doing great, man. I'm so excited for this episode. There are a couple of hot trends in the identity space right now. Continuous identity that we're going to talk about today is one that I really believe in. I'm really excited to talk about and I'm just excited to jump into things. Yeah.

So today we've got a sponsor spotlight episode. We do these from time to time. It's a fully sponsored episode. So we get into the mindsets of our sponsors and sort of the big thinkers they've got on their side, get their perspectives on I am market straight from the source, which is a little bit different than our normal episodes where we are. We try to be as vendor neutral as possible, right, not talk product, but that is not one of these.

Today we're actually going to talk product and the product today we're going to talk with is Signal. And for those not familiar, you can find them on the web SGNL dot AI slash IDAC. We'll take you to there. I know it's like a lot of letters, but it's Signal.

And for that we've got Eric Gustafson. He's the Co founder and CPO at Signal. Welcome to Identity at the Center, Eric. Hey, well, glad to be here. Yeah, thanks for taking the time. So I, I, I, I kind of, I'm joking a little bit because it's like SGNL dot AI slash igac and yet somehow people will know that that is signal and identity at the center, which is amazing. Yeah, brains are amazing. So this is your first time being with us.

I always like to find out how people got into the identity space. It's such a varied kind of skill set and background. So let's start there.

Eric, how did you get into the IM space? Is it something that you chose or did it choose you? You know, in some ways I'd say it was both back, what was it, 2011? My Co founder, my current Co founder, Scott and I were working running identity and product at a, of all things, a fantasy sports gaming company. We built games for the NBA. We're B to B, so we built and operated the games under somebody else's brand. So we did things like NB as games, World Cup games, we did

NASCAR's game. We did some TV shows like The Bachelorette. It was a lot of fun. We were using all SAS products. Basically people weren't even using that term at that point. You know, you had the sales forces of the world, they existed. And you know, at that point we were, we were just hired guns there. We were employees and the company is being sold off and we were there to help transition it

over. We got done with that and we're looking around going, well, what do you want to work on next? Let's go, let's start a company. But what's the problem we can solve? And we kind of realized, hey, everything we're using is cloud based. We have this whole IT department, they use Active Directory, we've got Exchange, it's all running on our own hardware that's in some data center. We're managing it all. And that group has no clue about any of the web things we're doing.

Like they don't know how people get access to them. They don't have to remove people. We were, you know, obviously transitioning the company to someone else. You're removing access to things. So you said how, how are people going to solve this problem with these web applications? There's going to be a million of them, which, yeah, at that point wasn't the most popular consensus. I got laughed at a few times for suggesting that. It's like, Oh no, it's all going to be just sales force.

They're going to own everything. It's like there's no barrier to entry to make a a web application. And so we started looking around and we ran across this start, this little start up called Okta. And we looked at Okta where we're like, huh, this is kind of what they do. But it seems really tied into Active Directory. And I'm not sure about this.

Like we could do a better job. And so, you know, there were two years into it or so we, we said let's go raise some money and start a company we called that that was called Bidium. And we built an identity platform. We didn't actually even know much about identity at that time. We were mostly focused on, you know, credential vaulting what we came that, but we built in all the typical things, single sign on, SAML, open ID, connect, directory sync, provisioning, all that stuff.

And we did that for about 6 years. So we kind of stumbled into it, but I guess of our own volition because we are going down this path of starting this company, you know, sort of Fast forward, that brings us to 2017. We were fully competing with Octa. We were winning deals. I think we won like Bank of America against them and Liberty Mutual and they filed to go public. Oh man, what's this going to mean for us? Like what happens, you know, we're, we're a lot smaller than they are now.

They're going to be a public company. Like, are we going to be able to compete? And that actually catalyzed the entire industry to go, hey, this identity thing seems real is now a public company that's, you know, an identity provider. And every one of the partners we had. So we, we took, we took a very cloud forward approach to things. We weren't trying to tie back to traditional LDAP systems.

We were looking at HR systems, we were looking at skim, we were looking at Google Cloud as identity sources to allow you to authenticate. And so these partners all reached out to us and we actually ended up selling the company to Google and that became part of Google Cloud identity, which is their single sign on provisioning directory

sync product. And I, I ran a big chunk of the single sign on portion directory sync for about two years at Google as Scott came along to and worked a bunch of interesting things. So that's kind of how I got in the identity space. I guess, you know, prior to that I was just doing software, various kind of enterprise software and it just it, it made sense to us and been on that

journey ever since. So as a recovering fantasy football player, I don't know if I should be shaking your hand or trying to tear it off because I've had good and bad seasons. But I won't go over there with this one.

I introduced you as ACPO and that's a chief product officer. Tell me about that role. What is what is ACPO? And tell me a little bit like what is a normal day? And maybe it's a normal week or average week, whatever you want is portrayed as it's a so at signal. What I do as a chief product officer is I oversee. Both the engineering team and the product team.

So I have very solid product lead and engineering lead underneath me and they take care of their respective teams, make sure things get built, make sure our products released, talk to customers, be happy. My job is really actually the way I formulated is to talk to a lot of customers. I try to talk to as many customers during the week as possible. I try to go along on sales calls. I try to talk to customers that have been deployed, what are their problems?

And I try to, I'm trying to kind of see around the corner like what's coming next? Like when someone says something interesting or customer A says, hey, I want this sort of, I'm trying to solve these problems and customer B will probably tell me they're trying to solve completely different problems. But I realized there's some Venn diagram overlap between those things. I'm like, OK, my ears will perk up and I'll bring that back to the team and we'll work on, OK,

how do we develop that? How do we turn that into product road map and product features? So I think my job is to listen as much as possible to the market, reflect that back internally and then take what the teams are coming up with too and bring it out and say, Hey, what do you think? You know, customer X, what do you think of this sort of thing? We built something like this. Is this interesting? And then for pre sales, the customers who have we're not

working with yet. So prospects, I guess see if it fits them. Where are they on their journey in the identity space? What we're building at signals pretty new. And so there's a lot of education in the market. It's it's there's definitely people out there who are way more advanced than we are in their thinking and they're like, yes, this is what we've been looking for, but there's also a lot there like what is signal to wait? Like, isn't that some messaging app? Like what do you guys?

Do so I want to start up with how did you get the company name together there SGNL signal like how did you come up with that?

So Wes, we're thinking through this what we're now calling continuous identity back in just probably mid 2021, we were about to leave Google. We were Scott and I were sitting down. We're like, hey, what do you want to call this company? And we start thinking about this is broadly in the authorization space where post login. So we're not dealing with who the user is, not that part of identity. We're the what can the user do now once we know who they are that side of identity.

And a lot of what we thought about was this is a game of what signals can you get in from existing systems? Can you get threat intelligence? Can you get signals from directories? Like thinking about as big way of meshing the data together that's already living in the enterprise and pulling it into a sort of what we now call a fabric. Like bringing all those relationships together to be able to understand what are people allowed to be doing at this moment in time.

And so we knew we only used the word signal somewhere in the name. So I, we spent probably like 2 weeks just texting random names back and forth to each other. Like what do you think of this? What do you think of that? And we'd then go look to see if the domain name is available. So eventually we came up with like, hey, if we take the word signal, I think I, I came up with this and remove the vowels from it. That's a short, that's a nice

short domain name. sgnl.com. Somebody's got that and squatting on it. O dot AI. Let's do that then. This was pre open AI, like there wasn't ChatGPT at this point and coming from Google DNA or like, OK, machine learning AI stuff, that's a thing. And eventually, you know, we want to bring some of that into

this system. So yeah, let's go with SGNL dot AI. Like that kind of encapsulates it. Some point later, one of our customers pointed out to me, like, do you realize that you just took the vowels out of the word signal and moved them to the dot after the dot? I'm like, yes, I'm really brilliant. No, I did not realize that. Yes, of course. Yes, we planned that all along. It's an. It's an anagram. Don't you get it? Yeah. We should also say Head of marketing then.

I don't know. You know, you probably have one of those and I don't. Want we do. Steal from that person. So, you know, usually Eric, or I should say always when somebody has an idea for a company, a solution, it's a solution to a problem. So what is the? What is the problem that you guys are solving? Yeah, absolutely. So a lot of this has some roots inside when we were together at Google. So Scott and I were both there.

You know, after we came in two years of stabilizing the acquisition, Scott took a role inside Google to look at how do you deal with authorization across the entire platform. So this is everything from like Waymo to Google Maps to ads to Nest, you know, every subsidiary that Google owns. How do you deal with policy across the board on that?

And I was spending a lot of time with who's now our CTO, Otto, And he was wanting to propose this thing that is now we call Cape Continuous Access Evaluation Profile. And he wrote a blog on that. I actually was the guy who approved the blog being published in 2019. His manager came to me and said, does this make sense? I'm like, Yep, that is brilliant.

I want to talk to this Otto guy. And so we were thinking about these these problems, specifically what Scott, the pain points Scott was being asked to solve is Google has, you know, they've got a couple engineers they can they can do some stuff over there. And they've built for themselves pretty much every possible type of security and identity technology and probably own licensing to have like all the

other ones anyway. But they ran into this issue where, you know, for geopolitical reasons, they wanted to lock down user access in Hong Kong. And they want to lock it down so that only customer data for customers that were located their headquarters are in Hong Kong could be accessed by employees who are assigned to work in their very big building in Hong Kong at the time and probably still do. There are a lot of engineering teams from different parts of the company working in that

building. And so how do you actually do that? And it sounds like a simple problem, but it actually gets complicated is like, how do you know the customer's base there? How do you know it's the headquarters? How do you know the users not just like passing through temporarily and then office, they don't actually work this. You have to pull all these data feeds in to be able to solve those kinds of problems. And it wasn't something that could be done quickly.

And obviously, you know, geopolitics doesn't move fast, but it does move, you know, in weeks, not in years. And so realize, hey, this is a probably a blind spot to our systems that we can't do policy fast. How do we solve that? Hey Scott, you seem like the delusional entrepreneurial type of guy. Can you solve this? And so he went off and, and they built this platform for like 2 years or so.

And when he got done with it, I was comparing notes with him because I had been always kind of interested in the post authentication, the post login problem. Like how do you know what people are supposed to do right now? Atul is obviously interested in this too with Cape being focused on session transitions. And so we were comparing notes like that seems like a really good problem to solve.

It doesn't seem like there's, you know, but is this just a, something that you have to be Google or you have to be Amazon to have these, this is that big of a scale issue or do sort of mere mortal enterprises actually have this problem? So we went out, we talked to some CSO's at large companies,

like, what are you all doing? And the answer we got back to them was like, there's nothing good in the space that does this for us. We were probably going to assemble a team of people together and do this ourselves. That's enough. We were at the time where we had this sort of stick around at Google. So like, hey, let's quit our jobs next week and let's go found a company. You know, let's let's get the band back together. So that's what we did.

So many questions based on what you said, and I'm going to stick with the one that we entered the show with and talked about this term, continuous identity. I mean, it has so much meaning to me and it's something that has been, you know, needed for such a long time. But I wanted you to get want to give you an opportunity to put in your words what is meant by continuous identity. What is the the dream behind

that? Yeah, it's a great question for continuous identity and I'm really glad the market's starting to, you know, customers are starting to use this terminology. I heard it a lot at Identiverse this year. I've heard it come up in just natural conversations now because it hasn't had a name. In some ways I think of it if if you think of the kind of asynchronous, always on sharing first architecture that something like Cape and the shared signals framework

envisions being there. Continuous identity is kind of that solution. It is continuous identity is the idea that you should be always pulling in signals and information from your systems and they should be evaluating that in real time whenever a user's doing something. And on top of that, you should be broadcasting it back out so everybody knows about it, all the other systems know about it.

So really simple example is, and I guess I should add, time is important to this, right, The time factor. And we'd often think, don't think about time when we think about identity policies. We should think in terms of more what I call static access. Like I can do a thing. But now really you want to ask like I can do a thing right now.

So imagine your dev OPS and you're supposed to go out, You know, today's the day I'm supposed to go to AWS and I'm supposed to do ADNS update to deploy some new system into production. Or maybe I'm supposed to do it in staging it better. And I go there and I have access. And now as soon as I get into that environment, I realize like, hey, I have, I'm waiting for something to happen. I click a link and I'm boom, I've got malware on my device. I still have that session open.

That malware might be harvesting those credentials, getting me in there. There's systems. Crowdstrike does a great job of detecting those sorts of things. But how does Crowdstrike tell my IDP to tell AWS that it should cut me off? Or let's say I'm actually not supposed to be in. I was supposed to be in staging making this change, the prep for next week's production release, and I accidentally clicked on the tile for production.

And now because I am the guy that deploys the production and I'm in production, I make this change too and I break things. All these problems have to do with standing axis and a problem of not sharing information. So you think of continuous identity as, hey, we pull the data in real time from systems, we react to that changing state. You were OK from a crowd strike

point of view. You're no longer OK now from a crowd strike point of view or you're on call this week, you're not on call this week or you're supposed to be the tickets for staging in service now, the tickets for production, ServiceNow, these are all state changes. And when that state or better, I think for a, a less nerdy way of saying that is, you know, think about context, the context of me doing my job, that changes our identity system should react to

that. This is a really common concept in the kind of cybersecurity land. We have threat detection and automation and sores and Sims and all these tools. How do you bring that into the identity play? And then how do you have the identity? And for the security side, these, you know, we've been treating these two industries as separate for a really long time and I see them really kind of

converging. Yeah, I mean, the the podcast name identity at the center has been all about the story that you just relayed there. You know, I think a lot of people think, OK, well, identity is new perimeter identity center is kind of a play on that. But it's really that the identity and what's happening in all these systems kind of comes back to the center and drives things.

Because you made a great point there about, OK, crowd strike detects us. Does that information just kind of die there or does that become identity data that comes back to the center? And I think, I think where we're going with this is that then that data becomes usable for

making smart identity decisions. And not only just making smart decisions or throwing information on a dashboard, but in real time saying this is a session that looks like it's from an identity that's been compromised over here. Let's do something about, let's temporarily shut off access, for example. Is that kind of what you're getting at exactly? Exactly.

It's that idea of like and I, I like to think about it as that identity comes from the perimeters back to the center and then is processed mixed with other information from other, other systems and then rebroadcast back out. So not only are you getting all these superpowers of I can do things in real time, I can take all this rich information that we, hey, we already have inside the company and I can make better use of it. But you actually make all your

other products better too. Because suddenly your, let's call it your Okta instance or your Entre instance is suddenly a lot smarter because now it's getting data feeds piped into it from your Crowdstrike solutions. And Crowdstrike's smarter because it sees somebody's probing at the at the IDP and it can bring that stuff back into Crowdstrike or bring it to a

sore. And you can run a playbook against that saying, hey, well, if Jim's keeps hitting the thing that says deny, deny, deny repetitively, maybe that's not Jim doing that. That's right. Yeah. And by the way, so we you said there with identity is at the perimeter comes back to the center that goes back out to the perimeter. We thought of that as a podcast name, but we decided just to go with Identity center. It's a little long. Yeah. It's a little long.

It's hard to search for, but yeah, kind of what I wanted to get at is something that I think you're talking about. And for me, this has been one of my big questions about Signal is what are the systems that you want to collect this data from? You met your crowd strike. Give us some more examples. Yeah, absolutely. So there's probably 3 big

categories of data. I'd say there's traditional identity data. So think your directories, your HR systems, your groups policy information, that's all identity data. There's security data. So your crowd strikes, I'd say your device compliance data, if you have a device management platform, if you like a jam for an Intune, it's that's the security feeds. Maybe you've got other sources of data, other types of telemetry that you've wired up in the enterprise.

Maybe you've got VPN logs or something if you're still using that type of topology. And then you get your operational data. This is your tickets, your ServiceNow, your pager duty. Hey, I'm on call this week. I'm the guy that's supposed to be going in there. If I'm not on call, well, I shouldn't be able to get access to things. Or if I'm on vacation, you know, unless I'm working for that kind of company where I'm should be dialing in from Hawaii to do my do my work mostly, I probably

shouldn't have access. Because if, if I'm coming in and work day says I'm actually out of office right now without any other information, you should probably assume that I'm an attacker. But I'm not actually me. But somehow I've been compromised or from suddenly coming from a strange IP address I've never shown up before in a browser you've never seen. So it's that type of business telemetry and all these things exist in the enterprise.

We just stick them in silos and don't ever talk to them again. So that concept of silos leads me to a very interesting question. I think is the concept of data, is stale better stale data better than no data or is no data better than stale data data, I can't even say it correctly, you know, but the better or stale data or no data, like what is what is the thought process behind that I think?

I usually try to flip this around when when customers bring this up and I say, let's start with the policy instead. What are you trying to accomplish and how if you had like write that down, like literally write it down a piece of paper. I only want on call engineers who have a ticket assigned to them to go to a production system. That's like the most basic policy a company's going to have that gets them in trouble.

I think no one thinks their cloud systems are the most secure they could be in that scenario. How would you go about proving that? Forget real time. Forget non real time. Like actually, literally like if you had the if your job was to go check out if Jeff's allowed to be in this system right now by manually checking things, what systems would you go to? OK, I need to know about tickets. I I where would I go? Service. Now I have some data there. Do I need all the data to be

perfect over in ServiceNow? No, I need some basic ticket information available to me. Maybe I need a process that I actually open tickets. But that's your policy. I hope you're following your policy or else you've got different problems. Do I need to go look at device compliance? Yes. OK. Like, should people be in the production system if they're on their old unpatched Windows 2000 laptop that's sitting in their garage?

No, I probably want them to be on a company managed defeat machine if I'm letting them do really serious things. So I'd say you need some data. You need to have a good handle on your data, probably more than you need to have good data. Knowledge of data is probably the number one thing. Just where are the systems? You can paper over quite a bit by taking data from multiple systems and then organizing and then signal helps you kind of stitch it all together.

And that creates a lot of power for you. It doesn't need to be perfect. It doesn't all need to be pristine. But if you know the different systems that you you'd use to force your policy, like if you can put your hands on that manually, then you can start. And I think that's a better position than just saying, oh, it's all in these silos. And I just not like, I, I don't know, I'm not even going to go after it.

I'm not even going to try. So Eric, it seems to me what you're talking about here is that most of the signal data that you get the most value from is from your own IT systems, whether they're stash systems. So what about getting data from like big ID PS, like a Facebook or something like that?

Does that make any sense? Does it, do you ever see a future where it's like, you know, you're you're getting this from a broker, in other words, you're plugging into some kind of central broker data hub, or does that just go against what you're trying to achieve? I, I, I like to be more agnostic about where the data might come from.

I think the easy, the low hanging fruit is your internal systems, but you know, it's a sibling standard to Cape is Risk, which is for account takeover feeds and Google publishes one and the US government publishes one for account takeovers. That's reasonable. If you're dealing with consumer identities, that might be handy to, to grab that data feed and use that in your policies.

There's lots of sources of IP reputation, data, threat signatures, there's lots of vendors of that information. And so I think for the the enterprise use case or the second party like the contractors, vendors, use cases, your internal systems are great for that. For consumer use cases, which we're starting to see some more customers tiptoe towards building those sorts of things, Yeah, they might be good public sets mixing it all together.

Those the real, the real power comes from, because the more you layer into the system, the more you map out the connectivity, just this gets exponentially more powerful for you. You have a lot more capabilities as you start to expand the network of data that's coming into this. What you know, we think of it, we call it the identity data fabric. It's stitching. You've got to weave all those threads in together. So I'd say, yeah, I can see a world where there's going to be

public feeds. I don't necessarily think I'd see a world where that's the only source of feeds. Companies are always going to have their internal systems. They're going to have their home grown things and they're going to want to use those for their own business reasons. I'd love that. Answer So one more, which is, you know, around kind of whose signals built for, is it built

for? You know, who's going to use it? I, I, I'd love the answer if it would be IAM practitioner. I also think the role of the IAM practitioner is expanding, but where in the organization do you see folks getting excited about this and kind of reaching out to you and you know, being interested in the product and potentially buying on? I'll, I'll make your day at the identity partitioners. It's really the IAM architects that we see.

We, we deliberately designed signal though to handle two different personas in the organization. So the identity partitioner is the main operator. They, the architect, they manage the system, they define, we call them policy snippets inside the system. Think of them as like they're the nouns.

So they've built the Lego building blocks that we use to assemble how signal operates inside your company, because we want to do that because they understand the identity principles that the enterprise wants to put in place.

But then we give an interface where a business analyst or someone who's closer to the application we're trying to protect, we refer to that as a protected system, that persona, they should get a very simplified, not simplistic, but easy to use way to say, here's what I want to do and do that by taking those Lego blocks and then snapping them together. I, if you're familiar with Mad Libs, it's kind of like Mad Libs, like there's just the policy. And let me throw in who's the principal?

What are the actions, what are the assets they're trying to protect here and what are some conditions? Those are all pre canned. My local identity architect has already come up with those based on the data sets we've pulled in the signal and I just seem to put them together and layer that, hey, now I have a policy and let me go stack up a couple policies. We really want to think about

reuse. So I want that policy like I can go to the cloud if I have a ticket and my device and I'm not a compromised device that should apply if I'm multi cloud. That's literally the same policy we shouldn't care about. Yeah, GCP uses a different identifier from Azure uses a different identifier from AWS. Or even if I've got a couple different ID PS in the mix, which is really common, the person who's trying to put that policy in place shouldn't have

to worry about those details. Let this graph, let this fabric handle that, let it do the on the on the fly translation. And that's so the architect role defines the terms of use in a way. And the business analyst or the end person who's after maintain their job is to maintain a system. That person is also a persona and signal. So we usually come in and talk to the architects first. They're kind of like the hero of the journey, and then they bring it to their internal teams who

rely on them to get things done. You're pushing all my buttons. In the right way, when you start mentioning things like Lego and

Mad Libs and things like that, I, you know, I think right or wrong, the industry likes to put things into a box. And so we already have boxes like IGA, Pam, Kim, and a whole bunch of other ones that, you know, would take forever to kind of list off. Where does Signal fit into that ecosystem? Is this a new category or is this creating something new? Does it complement things that already exists? Tell me a little bit about like where you see Signal fitting into the ecosystem.

Sure. In some ways it's a bit of all

the above. We do complement, so we go into companies. They already own everything. They probably already own 3 or 4 versions of everything. Like I've got octoping onto running around, I've got division over here that uses Curity, I've got sale point from this thing and oh, this acquisition we made there on Savvy and I've got Cyber Ark. So we work with all those systems, we stitch them together and we make them all better. I'd say the way I really think about it, it is a new way of

looking at the identity stack. And so there's some parts of IGA in here in terms of the ability to deal with users and groups. Like a lot of times in I when you're trying to solve this with an IGA hat on, you go make more roles, you make more groups, but really you're trying to emulate policies rather, but you're

doing it statically. And that eventually gets this problem where you have like 3.3 groups per every user or employee of your company and your, you know, Sarbanes-Oxley quarterly access reviews start exploding because you just have way too many things for all your managers to review. Or you might approach it with a privileged access management lens and go, all right, well, yeah, this is early.

I need to step up. I need a special token to go and do something that that technology is very based on credentials. It's passwords you're checking in and out. Yeah, they might be piped through something, but it's it's inherently different from the single sign on workforce identity world that we live in in 2025. So we pull some aspects of Pam, we pull some aspects of IGA together. But I really argue like we wouldn't build identity solutions the way they're built right now.

Like these things came up over time. Pam arose from pre cloud. This is like, how do I deal with my Cisco routers and root passwords on Linux boxes, not even thinking about single sign on at that point. IGA that came out of Sarbanes-Oxley. Like we're in this sort of generational change. Like these technologies and techniques had been around like

25 plus years. It's kind of time to rethink how we're doing stuff because we build this massive identity edifice and yet we still have problems. We still get hacked, we still get breached. Like we're clearly we're not doing like everything's 100%, there's never going to be 100%, but we're clearly not doing something right in the identity space that we can't even keep basic use it as a basic security tool for us. So I do think this is a new way of looking at the problem.

I don't, I don't want to have the hubris that a startup can define a brand new category and be like, tada, here's the silver bullet magic beans. But I do see we're reflecting the trend of where the industry is starting to go in terms of thinking about these problems. And we want to help with that. But we also, we will play nice with the existing stack. We don't come in and say, hey, yeah, like we don't coexist with these things. No, we coexist with everything.

Like, that's actually part of the. It's a nice aspect of the way the system works, and the way it works best is when it integrates everything together that has a nice property of. Will work with what you have too, so there has. The reason I bring this up is

because I know we have all these different acronyms and one of the ones that's kind of newer, at least to me is this idea of authorization and Gartner has a term for authorization management platform or AMP. At the same time, we're seeing things like P back policy based access controls kind of rearing its head up again as people try to solve for, you know, well, RBAC just stinks. It just takes forever to get it right. And it's, it's outdated as soon

as you press, you know, submit. So where do you see, you know, the, the industry going? But also how does signal like aligned with things like AMP or PBAC or you know STAR dot back, you know, whatever acronym you want to put in front of the the access control? So I say we're pretty aligned

with this idea of amp. Like I really like when I was Paul Mozzaro, who wrote that. If you have a Gartner subscription, I highly recommend giving it a read. It's it's, it's going in the right direction. You know, if you talk to Paul himself, he'll, you know, it's, this is evolving still. This is the first foray into trying to find this movement that's happening in the identity space. It hits on a lot of things that really resonate with me and with signal.

So it it asked like Paul, like, hey, what's the what? How do you differentiate this from what's come before? And it's this orchestration layer. And that's where the Cape side of things, that's where the signals, the emitting of signals, that's the we send information from the edge to the center and send it back. That's the orchestration portion of this. You need policy on top of that because you need that. You need the rules of the road. How am I steering my car or, you

know, on my steering my ship? Pick your analogy. That has to be part of it. And then you need the data fabric underneath it. And those are the three main legs of the signal stool policy engine orchestration layer, which looks a lot like policy, but you, you think a little bit more asynchronously with the orchestration and then the fabric that powers both of them, which is the aggregation of the data. You want to back up all your

policies. And you know, we call them triggers in the in the orchestration tool. All those things kind of come into play here for us. And so, you know, P backs an interesting term. I think there's lots of really solid P back tools out there. But historically, like if you think back to like as ACMOL days, like 25 something years ago, if you can remember that long ago, those are kind of meant to be more developer

tools. Like I just want to build a better framework within my application for dealing with these problems. And what we've seen is a lot of customers who are not successful trying to apply those concepts horizontally inside their enterprise. If you try to take a a classic, you know, Zac Amol tool, or if you get to like alpha and stop having to deal with XML and you can use Jason, it is, you know, 2025 now, it's still difficult because they're not they weren't designed to think about the

enterprise state. You need to have these things all work in concert, but you need that backbone saying like this is what I'm trying to apply across horizontally, across the board, not down into the application. So you know, when, when you're all were asking about personas, like I did not talk about developers, like we're not a

developer focused tool. I think they're great P back tools out there like OPA that are good for a developer wanting to do something better than hard coding authorization logic into the system. But as soon as you need data that's not resident to that application, who's on vacation? Unless you're building an application that manages the vacation schedule, you want to get that from somewhere else and you don't want to deal with the stale data problem of that.

And how do I synchronize that information and maybe some of that sensitive like, you know, obviously vacations might not be that sensitive, but think of something like it's a legitimate policy. Citizenship might come into play. Maybe I have to be a certain citizenship to see some piece of government data. That's a very common regulatory policy, difficult to enforce. And I don't think we wanna be pushing what citizenship my employees are to every single one of the applications in the

enterprise. I'm sure that'll get you in trouble in Europe, if if not in the US to do those sorts of things. So feedback tools are interesting and they're, I think they're a useful part of the system, but it doesn't solve this problem. And I think amps on the right direction as we start seeing the space emerge and these architectures get real mileage in the space and more adoption, I think that will also evolve a little bit too. But it's, it's promising.

So Eric, I want. To go back to what you're talking about with the agenda architects. So the one that once that pull you in, they went under and I, I realized like making the case to those folks is no easy task because they need to really understand this. So at that, at that point that you achieve like, OK, they get it, they buy. And I'm thinking of like some really smart people who could probably do both sides of this

equation. So you know, I'm thinking of Shawn Odell, thinking of Andrew Cameron. They first you have to sell them on the tech right after that. These are guys who can speak the the language of business to make the case. I'm wondering, you know what, what does that sound like? Help us out for the people who are listening who are like excited about this and maybe when we dig into the tech, that's great. Eventually you get them sold on that.

Now you have to explain it to somebody who's used nothing about the tech and probably doesn't care and you have to put it in the language of business. So how do they do that? How are they successful? Yeah, absolutely. I think, you know, it's kind of like what does it look like to win in a company when we go into it? And this is where I, I usually start with something.

I think Ian Glaser put this on a on a blog of his called, you know, we endearingly inside a signal called the pyramid of pain, which is if you think of all the applications in your company that you're using, which ones are you the most worried about? Like where is the biggest problem gonna be start there. That's the top of the pyramid. That's the most painful thing. And those are usually applications that you're you're not in it every minute of the day. It's not, it's not slack or

e-mail or your calendar. It's your production environments, your your production systems, maybe your financial systems, maybe it's your CICD pipeline. So things that are like someone got in and just went haywire in there. That's potentially a company ending moment, if not at least a career ending moment for someone. Those are the most difficult.

They require the most context. They require the the biggest need to reduce access to them so that you're not always able to, you know, it reduces the attack surface. That's where we try to frame people to start there. And then we look at, OK, can you reduce the number of roles and groups in the system? Can you reduce the amount of standing access? Can you be more responsive? Like the problem of if your Crowdstrike or your other security systems detect a problem with this user, can you

react to that? And can you pull them out of an environment If the user's been no longer an employee, like they were terminated in the morning or they resigned in the morning, but they had an open session from the night before, or are they still I'll get access to things like, can you shut people off quickly in response to some type of HR event that goes on? So then those become wins for the business because the business recognizes this is a lot of risk.

Or if I've got a lot of groups, I've got to do access reviews in those groups. And after I've got 100,000 groups for 10,000 employees, that's a lot of work for people that's not really helping the business move forward. And so we can start to show value. It somewhat depends on who we're talking to. So if I'm talking to application owners, we might talk in terms of I give you dynamic access to things rather than, you know, I talked to identity person. I talk about 0 standing access.

Like people don't have access when they're not supposed to, but magically the access is there when they need to use it. The business likes to hear it the other way around. Like it'll be there when I want it and it's not there when I'm not looking. That's the right stance to be in. And that ultimately drives a better security posture. I'm talking to kind of the CISO persona. They tend to be the ones they start thinking about. What are my risk signals in the

organization? How do I lower overall risk the things and icing on the cake, can I make my business operational processes simpler too? Can I reduce access reviews? Can I reduce toil inside the company? Those are all wins for us. Yeah, that I. Mean that's a great business story about reducing risk, reducing that kind of overhead of things that help reduce the risk so that it makes it more

effective. You actually start to steal from my next question, which was around what are the use cases, right? Because you think of a good picture there especially, and tied back to the continuous identity because you talked about, you know, someone has been terminated from the system, but maybe they have a a session

open. I mean, literally, I've run into that before where it's like, well, yeah, we shut off their access, but if they still have their laptop and they're already logged in, you know, and we wouldn't know it. And I'm like, that's terrible. That is absolutely terrible. So this whole idea of, you know, being able to go in and like

surgically kill sessions. The one thing that you'd mentioned earlier is I asked a question about what are the sources of these signals and then, you know, obviously you link that to them, we can take action. And the example used was the IDP. I'm wondering if you have any other examples, like is are there examples about going into IGA systems or privileged access management or anything else that, you know, maybe I didn't

mention that. Just seems like, you know, when you want to brag about a little bit, yeah. Absolutely. You know, the the IDP to to cloud provider is probably our most popular use case. Closely related though, CICD pipelines, I've got my GitHub. If I can push code, I might as well have console access to the cloud. So predicting that I can't push unless I need policies. I have to be the release

manager. Right now I'm assigned to do that and I'm on my a pash device and it's doesn't have malware. All those things are important to me. That's another popular use case. I'd say the other ones, API gateways is a big one for us. So I'm making API calls.

This really comes into play. And I know we haven't used the AI Buds word yet, but you know, MCP or model context protocol that's just an API Gateway pattern protecting that we're getting a lot of interest in. How do you put policy in place for that, especially because it's really easy to vibe code out one of these things without thinking about any kind of identity security practices. Roll it out.

And now I've done all kinds of egregious things like embedding tokens and not thinking about access control and not thinking about deployment and no one knows about it. So this is just a, a sort of accident waiting to happen here. We got, you know, pits with spikes at the bottom of them in this area. Working with IGA and Pam, those are good ones too. So we've got some nice use cases with say, sale point where maybe we want to do some of these

checks against security systems. When someone comes into Cell Point and requests access to something, Cell Point could call it a signal, look for a policy. The signal says, yeah, the person, you know, Jeff looks good. He's, you know, his everything's fine with him. He's allowed to do this. Beyond this, the normal rules.

And then or flip that around, something changes in a system and we could go say, hey, deeper vision Jim, like go take him out of this Active Directory group because you've got that all wired up anyway as part of your join remover lever settings in Cell Point. Let's just trigger that. We see something anomalous that comes in from the SoC. We can go tell cell Point to do that. And that can speed things up too. That can make you more reactive and make your existing

investments better. Do something similar with Pam, like, hey, we know it's someone's compromised. We could tell it to rotate a credential or we can we could even potentially block access to the Pam system itself for that user so that they, if they they can't just go start doing X fill against all the passwords that are in the vault. So there's a lot that we can do in conjunction with those other

systems. And these are all we tend to see people solve the and we encourage folks solve the easy problems first, like solve those and then expand because the way the platform's built, it's meant to keep going to more use cases. And we just see customers follow that pattern. They start with one use case or two, we nail them, we roll it out, everyone's happy. We're all, you know, popping

champagne, celebrating. And then, hey, the next use case, the next use case, the next use case and so forth, we can pop some. Champagne in a little bit. I got a couple more questions for you. What is it that makes signal different from, you know, your

contemporaries in this space? Tell me what sets you apart because this is my jaded CSO time where I say OK I already got a bunch of tools, why do I need signal and why is it signal over something else? I'd say there's really not much out there that does this in the way we approach it. So there are other tools out there that understand Cape signals and protocols. There's other tools that'll pull data in, like you could use Octa and they have a directory system

that they use provisioning. But these weren't men and they weren't designed to think about it from an enterprise wide scale. They have kind of their corner and their main objective and they tiptoe into these other areas. So all the IGA tools have some kind of Pam module that can do some privilege stuff. All the Pam tools out there have now acquired some IGA vendor and they can do some simple IGA things.

Sokta just announced, I think, you know, the other day that they've got, you know, they made an acquisition in the space and they've got some IGA and Pam things. So everyone's kind of tiptoeing around this, like refactoring of the identity stack right now. We built this from day one to

solve this type of problem. How do I stitch my entire stack together, not just of identity data, operational data and security data, bring this all in one place and give you the ability to have this continuous identity architecture within the organization. That's what sets us apart is we were purpose built for this problem. We're not trying to retrofit this into an existing system.

In some ways it's kind of like the innovator's dilemma issue, like you have to reinvent your IJ stacked work in real time or you'd have to reinvent your Pam system to understand workforce and single sign on none of these systems. They all kind of want to play in their own sandboxes if no one else exists. And I said, hey, this is 1 big sandbox, we all have to work in it.

And maybe we should look, talk to the guys next door about the security stuff because that seems kind of important to us. Yeah, I can see. Definitely a lot of linkage with things like, you know, security operations center and some of the tools they have, right? It's, it's all data you're trying to pull in. The more data that you've got, the more interesting and educated decisions you can make on how you want to leverage it, right? Exactly. So let's take a look.

At the broader range, industry at large here from an identity perspective, and I'm hoping I won't hear AI is the answer, although it probably is. What are some of the big trends that you see coming along that people should be keeping it out for? So I kind of call this of like skating to where the puck is going to be from an ice hockey

analogy. What's coming up that you know that that is really kind of piquing your interest or is it just, hey man, AI is here and we've really got to got to get that figured out? I mean, definitely I'll, I'll we'll put the AI one out of the way like AI is here. We got to figure that out. I'm not smart enough to know all the impact it's going to have in the identity space. It's definitely having an impact and we'll continue to have one.

I probably the only thing I won't be surprised by is that I'm going to be surprised about where we are in a 12 months in the AI world. So putting that one to the side for the moment, the two big trends that I see here right now, one, we've been kind of dancing around a little bit here, the convergence of identity and security together.

And I actually think some drivers of this are it's becoming pretty common for your CSO to start taking over your traditional CIO roles or your CIO taking over CSO. This, those two leaders are morphing into one leader. A lot of things that the CIO looked after before probably live under like a COO, like what productivity suite we're going to use? Are we going to be on Slack or you know, teams? Are we going to be on Zoom or

Google meet or you know teams? Those decisions aren't don't require a specialist as much as they require someone to negotiate price points on a per user per month pricing concept. So where's that leave the identity team? Because if you're thinking about identity systems and traditionally, you know, you guys know this probably better than I do, your IGA tools, your IDP tools kind of live in the IT world and kind of we're more like productivity things.

And your Pam tools, if they weren't in identity land, they were more in the security land. And as those worlds come together, it stops being about just productivity. It starts being more about, OK, yes, single sign on gives me productivity and reduces passwords and I get MFA and all this goodness out of that. But I also started wanting to use this as security controls, which has historically been the sea sales world. So I think that's a massive

trend right now. It's just the convergence and mind meld of those two sort of organizations together into one. And I'd say it's probably not a surprise that of our customers who are moving the fastest, who are the furthest ahead here and of the industry voices you hear they probably work in an identity security team. And obviously like you see, you know, Palo Alto's acquisition of Cyber Ark, you know, that happened a couple weeks back. They're talking about that as

identity security. So this is in the air. The other big trend I see is this generational change. It's been 25 years since we kind of came up with the IGA and Pam things. It is that is a long time. Like there's whole generations of humans who grew up after those events, right after, you know, the Enron events of the world that drove Sarbanes-Oxley. It's time to rethink how we do

things. And so that's the other big trend to see is we are coming up on massive replacement cycles of two entire sets of sort of the core identity stack. I'd say ID, PS and pass through lists are probably the latest generation and even those are like those are 15 year old things. So it's it's natural that we're coming up on rethinking this. Yeah, some of these. Solutions are not old enough to vote. Maybe you can drink exactly. They're old enough to rent a car. You. You. You've.

Been so gracious with your time. I want to kind of pivot here to

a little bit of a lighter note and kind of wrap the show up here. We were talking before we hit record and you mentioned that you are into cooking and I am into eating. So I think this is going to be a great conversation. So I would like to pose a hypothetical to you. So let's say you've got to create the perfect meal, and I'm going to put you on the spot here. Not only create the perfect meal, you have to create the perfect meal for me, OK.

What are you going to make? Why are you and why, you know, why are you making decisions, decisions, you know, for what you're going to make? And you can feel free to ask me questions if that helps you in any way. Yeah, yeah. Let me ask if you like, you know, First off, like anything you don't like eating, like what's you know, any, any areas to avoid? Hey, I really hate, you know, spicy food or I don't eat fish, you know, anything like that to be aware of.

Well, you hit two right there. So I'm not a fish person. I'm generally not a seafood person with the exception of shrimp. As long as the heads are cut off. I don't, I don't dig on, you know, the shrimp showing up with their heads on. No, give it to me after the sushi. I thought you liked sushi. Sushi is the one. Exception, I will do something like tuna, maybe like a lighter fish, but it has to be with like something else like in a roll or something like that. Not spicy, although I can

tolerate a little bit of pain. And then mushrooms are just not my jam at all. So other than that, I feel like I've got a pretty open palette now that I've, you know, cut off like a third of the of the menu. No, no, no. So, yeah, So my thoughts are way out the window now. No, I'm just kidding. I'd say let me think through this. If tuna's on the menu, I'd say a really nice piece of like ahi tuna that's just really well seared, a little seasoning, a little salt, pepper, you know,

let the fish speak for itself. It'll probably be sort of I'd anchor that around the main. Maybe a really good I I'm thinking Japanese would be a a good venue to go down. Go with a nice tuna over some nice rice, just like sliced up for you. Like nice presentation. Maybe a little seaweed salad on the side. I'd probably think about a couple courses. Make it really good miso soup to start with. I like roasting vegetables a lot, so I'd probably roast up

some carrots. Look for some, you know, go see what's fresh, what's interesting, what's going to be colorful. Think about putting that together and then maybe serving it out. I like to do more family style, like put things out on plates, share it around. I think that just makes for a better conversation and it comes out nice because it uses a big plate with lots of stuff on it looks always looks great. So that's probably the direction I would take it in. OK. So, Eric?

What time do I show up for this? Because you absolutely nailed that. Like, that is totally my jam. I am totally on top of that. So I'm going to invite myself over for dinner at some point. Or maybe we'll just go out and get a nice sushi dinner somewhere. Yeah, no, whenever. Whenever you want, happy to happy to cook for the both of you. Next time you're up in the Bay Area, we'll, we'll make it a date. Jim, how about? Yourself like how does that strike you of like a dinner like

the AHI tuning as possible. Yeah, I'm pretty open minded. The only thing I don't like is really strong cheese, like blue cheese. I don't like feta. It's just the smell turns me off and I've always been that way. But other than that, I mean I'm pretty open. I mean, I'll even eat like really strong meats, like organ meat, like liver and stuff like that. So yeah. And wild game, like, I know a lot of people don't like that. I think it's interesting. So yeah, I'm pretty much up for anything.

But if you put blue cheese on it, I might just leave. Yeah, I'll leave the blue cheese off the nice piece of ahi. So there you go that. Sounds good, I totally. Appreciate that because blue cheese is one of the things I absolutely detest because I spent the better part of probably 7 or 8 years bartending and one of the things that we had to do was stuffed blue cheese olives for our martinis. And so if I never see blue cheese again, I will be totally

fine with that. I'll, I'll be the contrary and say I I like blue cheese. I love a good piece of feta, but I, I will probably eat most anything. I early in my career, I spent a year in Hong Kong working on a project. And yeah, before that I was a little, I didn't eat as much seafood. I didn't like eggs too much and I just went in with the mentai. Like this is a totally new cuisine. There's influences from all over Asia here.

I'm just going to eat whatever. So if it didn't crawl off my plate, I'd eat it. And so now I'm a much, you know, this has been a while now. It's been 20 plus years since I was there, but it's definitely opened my palate quite a bit. I was not always. An adventurous eater. I would stay I'm, you know, starting to put my toe in the water. I was very much like a grilled cheese and, you know, chicken Nuggets growing up. But as I found as I've gotten older, that I have been more

willing to try things. So I will try just about anything once, just now. I know that like Daniel. I mean you you either get experimental or you don't eat. I will give a lot of. Credit to Daniel, so you know our our boss here at RSM, but he has definitely taken me on some excursions and I'm very grateful for that because I have tried things that I would normally not have eaten and I've enjoyed some of it. I won't say all of it. I have enjoyed some of it I. Like, hey, I liked a lot of

things. I wasn't big on bone marrow, but I mean, at the same time I could eat it again. Just wasn't my favorite. Yeah, I hear you. Yep. I think it's important to try it once, see if you like it. You never know. You'd be surprised. Yeah, that's how you. Discover, you know, Hey, new things, you know, it's kind of like music, right? You just like, oh, I didn't discover The Beatles until I was 30, or I didn't discover Metallica until I was, well, I discovered them, really, but you

get my drift. Exactly. Exactly. Well, Eric, you've.

Been great and really appreciate you taking some time with us. Thank you again for sponsoring an episode here with us. I'm going to have links in our show notes here for people to reach out to you on LinkedIn. Maybe, you know, share recipes or other things, whether it's recipes for, you know, identity data or other food items. Let's see what else. Visit the website SGNL dot AI slash IDAC.

There'll be some information there that people can kind of check out and that also show support for the show that hey, you heard it here on on identity at the center. So with that, we're going to go ahead and leave it for this week. Thanks everyone for watching and or listening and we'll talk with you all in the next one. You've been. Listening to Identity at the Center? We hope you've enjoyed the show. Make sure to like, rate and review, and we'll be back soon.

But in the meantime, hit the website at identity@thecenter.com. See you next time on Identity at the Center.