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'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.
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.