Security and engineering have each struggled with their relationship to identity management—and with good reason. Security isn’t tasked with the day to day management of identity, yet it’s ultimately on the hook when a breach occurs. Meanwhile, developers must maintain critical architecture that has nothing to do with their core product, leaving less time for innovation. The fraught relationship of security and engineering to identity has unfortunately translated into a fraught relationship between security and engineering teams.
In this webinar, Frontegg co-founder and CTO Aviad Mizrahi leads a discussion with Ian Glazer, founder and president of Weave Identity about these tensions, and possible paths forward.
How can security have more control over identity? And how can identity be less frustrating and time-consuming for engineering? You’ll get insights into these issues and more in this enlightening and lively fireside chat.
Hello, and welcome to “Security, Engineering, and Identity: From Conflict to Collaboration.” Today’s webinar is sponsored by Frontegg and Weave, and produced by ActualTech Media. My name is Scott Bekker. I’m from ActualTech, and I’m excited to be your moderator for this fireside chat-style conversation with demos at boot.
Now, before we get to today’s great content, we have a few housekeeping items that are going to help you get the most out of this session. First off, we want this to be an informative event for you. So we encourage any questions in the questions box in your webinar control panel. Not only will we have team members responding to questions during the live event, but we’ll also have a dedicated Q&A session at the end of the presentation where we’ll discuss in greater detail some of the top questions that you ask.
That Q&A panel is also the place to let us know about any technical issues that you might be experiencing. A browser refresh is going to fix most audio, video, or slide advancement issues, but if that doesn’t work, just let us know there in the Q&A and we’ll provide further technical assistance. Now, second, in the Handouts section of your webinar control panel, you’ll find that we’re offering several resources.
I’d especially like to call your attention to details about Tri-Layered Security and a link on the Frontegg Security Suite. So I encourage you to access those resources now and feel free to share them with your friends and colleagues. Now, third, at the end of this webinar event, we’ll be awarding a $250 Amazon gift card to one lucky registrant.
Of course, you must be in attendance during the live event to qualify for the prize. Official terms and conditions of today’s prize drawing can be found in the Handouts section. Just scroll to the bottom and you’ll find the link with the details there. Now, finally, one of the best benefits of this event is the opportunity to ask a question of our expert panel who I’m about to introduce. But to help encourage those questions, we have a special additional prize for you that’s another Amazon gift card.
This one for $50 for the best questions. So after the event is over, we’ll look at all the questions that came in, pick out the very best one, and contact that prize winner. Okay, with that housekeeping out of the way, let’s get to today’s fireside chat and demo. So it’s my pleasure to introduce you to our great panel today. First, we have Aviad Mizrachi, who’s co-founder and CTO of Frontegg. Aviad has been a developer and engineering leader for the last 20 years.
And prior to starting Frontegg, Aviad held management in architecture positions at startups such as Vicon and HTS, as well as larger companies such as NICE and Check Point. And we’re also joined by Ian Glazer, one of the world’s leading experts on identity management. Ian is the founder and president of Weave Identity, which is an identity advisory services firm. In previous lives, he was senior VP of identity product management at Salesforce, and he led research at Gartner on identity and privacy strategies.
So let me bring Ian and Aviad in here. Gentlemen, welcome. Thanks for being here.
Yeah, thanks for having us.
Thanks for having us.
Well, it’s great to have you here. I’m looking forward to the conversation. So I’ll just take it away.
Thank you. Thank you. Thank you, Ian. And thank you, Scott. And Ian, it is pleasure to have you as part of it.
Yeah, happy to be here.
And maybe we should jump, yeah, right into it.
Yeah, let’s do it.
Yeah. So we are talking about, you know, I’m an engineer by heart, obviously. So as Scott mentioned, I’ve been a developer for the last more than 20 years. I’m 43 now, you know, and I always had challenges of building stuff, trying to move as fast as I can, especially in the larger organization. You know, Check Point was one of them.
You know, facing challenges and facing, you know, I wouldn’t call it a battle, but it was a battle of facing security challenges and security pulling in back. So, you know, obviously, you know, as Scott mentioned, you worked at one of the largest organization out there. So when you take a look at the main sources of conflict, you know, you have security from one hand, you have engineering from another hand, and identity is kind of torn apart between them.
You know, and you obviously, you know, deal with a lot of organizations and you consulted other organization today. How do you see, you know, that kind of conflict? What is the main sources of that conflict as you see it?
Yeah, so it’s great to be here. Thanks for having me. There’s I think two different tensions in play. One of them is security. And, you know, I love working with CISOs, but no disrespect, most CISOs think identity is authentication, and that’s it.
And yes, I’m painting them with a generalization for sure. But the interesting thing, especially about B2C and B2B identity applications is it’s actually a function of sales and distribution of marketing. It’s about product agility. There’s a lot more to identity than just the authentication and the registration of it. And so part of the tension between security and identity is about the understanding of the capabilities that an identity team is trying to bring to bear, right?
So I think that security has some oftentimes narrower window as to what they’re thinking about versus what the identity practitioner, the product management team, what have you, who’s taking requirements from marketing and sales and the other product teams and try to all cram them into a release. So that’s part of it.
But on the other hand, identity practitioners have not built bridges to engineering as best they could. For a long time, engineering teams, developers were underserved constituents in identities world. And the sad side effect of that was it forced engineering teams to learn way more about identity than they probably had any interest in doing.
Now, to be fair, I had teams full of engineers that were loving identity, but that was their job. If you are that mentality of, like, always be committing, right? You want forward velocity, you want to get new features out there, you want to deliver new value, learning about the intricacies of an OAuth profile is not high on your list, right? It’s just not.
And so for a long time, identity sort of threw a lot of junk over the transom for engineering as sort of sort out, and that has been slowly getting better, I would say. Certainly, there’s a heck of a lot of open-source libraries now to help do some of these things. But even then, engineering is still left with you.
Like, how does this all fit together? And then wait a minute, you’ve got all sorts of requirements from enterprise sign-on to social sign-on to registration, consent, all of this stuff. I got a lot of peace parts. How do we make this a narrative, right? How do we make this a continuous and great experience? And so those two very different kinds of tensions are at play all the time.
Yeah. I totally agree on that, you know, that last sentence of yours, you know, of having the experience part. You know, we keep… This is where it contradicts, right? Because, you know, security wants to have everything. You know, obviously, you know, adding more and more layers of security where eventually identity needs to serve the business purpose.
And that, you know, remove, you know, burdens from users of signing in and signing up to the product. And if you add more and more layers of security, right, it can create, you know, eventually drop in user signing up and signing into a product. And then this is where the tension is, you know.
And, you know, I always say, you know, you led teams of identity expert that this was their job. I lead a company that does that. But eventually, there are not many…you know, when you look around, there are not many engineers that wake up in the morning and say, “I want to build a perfect MFA flow.” This is not, you know…
I don’t know why.
This is not what…
Yeah, you’re right.
Yeah. Yeah. But then you have the security team coming up and say, you know, “This should be on the top of your list, building out MFA, building out stricter session limits,” right? But, you know, engineering eventually, and even product has other priorities in mind. They want to build, you know, perfect engagement for users, etc. And this is where the tension…you know, prioritization.
How do you prioritize it? You know, security comes with one, engineering comes with another. Who wins?
Well, right. And then your product teams and your peers are like, “Hey, where’s that feature?” Right? Like, “You said it was coming this release. Where’s it at?” Right? I think the first and foremost thing is, and I’m going to admit biases here, right? So I’m mostly a product manager by trade.
And so that means building a narrative that everybody who is contributing to the product outcomes sees themselves as a part of, right? Security wants to see their requirements reflected in what you’re shipping, engineering wants to understand why they’re building this stuff, right? They want to feel good about what they’re building and what they’re shipping.
All your product peers are like, “Hey, that feature, that thing, there’s a deal commit on it. Let’s go, come on.” And so I think it’s incumbent on product management oftentimes to sort of negotiate those waters. And to me, it’s about a story that says this is how we all get reflected in what we’re going to be building. And one of the consistent things that I’ve always found is you end up serving as, for lack of a better word, a bit of a marriage counselor between what other product teams want, what security requires, what regulatory bodies require, right?
There’s a balancing act there. And identity practitioners I think are uniquely placed to translate those requirements one to another team, right? So I definitely had situations, I observed situations where marketing, sales distribution are like, “We want the fastest signup possible. We want zero friction, no stopping anywhere nohow. How do we deal with the GDPR thing and all this other stuff but make it go as fast as possible?”
And security, and oftentimes myself would be sitting here saying, “You know, a little bit of friction’s going to go a long way to helping things like fraudulent signup, like griefer posts, like the… You know, so, like, from a fraud perspective, you know, let’s tap the brakes here. Maybe a little bit of friction.
Oh, by the way, it gives us an opportunity to figure out this is the best way to sign somebody in and they’re going to be…it’s going to be faster, but a little friction can actually make you go faster. But it’s that sort of broader perspective and sort of translating, I would say, the requirements into a shared outcome that really becomes the art of an identity practitioner.
Cool. So let’s piggyback…
Let me turn it around. Look, you’re an engineer for a long time. Like, how did it work well for you? Like, were there times where you saw this work well? And then how many times, like, didn’t it work well?
So I’ll tell you that because, you know, the word translating that you used, you know, I had security experts coming to me and, you know, trying buzzwords on me, right, with me being a young engineer and not 100% sure what they want from me. And then when I went back to them and I used my vocabulary of engineering stuff, of, you know, this is my React application, this is my VJS application, they were like, “Huh, what does that mean?”
And then we found ourself, you know, we are not sharing the same lingo. And, you know, this is where, you know, it started. You know, we found ourself in an obstacle. We are not sharing the same lingo. I’m not speaking a security lingo and they’re not speaking an engineering lingo, and, you know, we couldn’t find ourself.
And then actually in Check Point, we had a perfect security team, and they came to us, you know, understanding exactly what a local storage means or exactly…you know, and explaining us how a success can be achieved or mitigated on our application. And then when we went to them to consult on a new security feature that we built, okay, we came prepared speaking their lingo of what is the potential attack vector?
And then, you know, the conversation, right, is totally different because there is a shared outcome. I’m coming to you because this is what I want to build. I’m coming to you because I want you to help me mitigate potential risks in debt. And when I’m coming with debt, not, you know, like, the top-notch engineer that knows everything because I’m coming to consult with you on something, that it’s totally different, you know, scenario.
And then when we bring product to be this marriage council, you know, security engineering comes aligned on, you know, what is the security goal, and what is the business goal of this feature? And then the product, you know, it makes their job easier. And then even if we decide to postpone it in a week or two, or in a sprint or two, or even in a month or two, okay, we all know why, because we understand what is the attack vector here.
You know, that story reminds me that no matter how senior an engineer gets in an organization, that could be executive vice president of engineering, if presented with a challenge, they’re going to default want to start solving that problem, right? There’s that bias towards delivery, towards velocity, and towards solving the issue.
And I think the interesting thing about where identity practitioners can come in because security will present you with like a do the thing, right, like, “You’ve got to encrypt all your secrets at rest.” Like, “Go do the thing.” And default action is, like, “All right, let’s get going on this thing. We’ll grab some libraries. We’ll get to work on this.”
And a identity practitioner can come in and say, “We want to do that. But before we do that, like, before we start actually cutting code on this thing, are there other benefits we can get out of it? Are there other things we haven’t seen? Is there an opportunity here that we can take advantage of this work to do even more?” Right?
Just that momentary breath before we all sort of grab keyboards and go to work I think can be really, really powerful. And it’s not a comfortable feeling. Like, as a product person, I’m always like, “I want to ship more,” right? As an identity practitioner, I’m like, “I want to ship more.” But having learned over time that, like, take one beat and just be like, “Can we use this somewhere else?”
Like, I always told my teams, “Never cut a line of code that had one beneficiary.” You had to solve multiple people’s problems with the work we were going to go do. Now I was working in a platform organization, right? And so we were building services that people were building then on top of, not just our customers but internal customers as well. And so that sort of mentality of, like, “Hey, if we do this, where else can we reuse this? Right? Where else does our product peers need this kind of capability?”
Like, a good one is, hey, you know, we’ve got requirements around session length and session protection. Cool, well, does that mean that we can actually, when people return to the site, actually be a little bit more intelligent about how they sign in, get them less friction to get them to the thing they need to go do?
Can we optimize that so that we can do that from, say, an email magic link? And would that help my peer who’s trying to ship a new feature get their customers to that feature faster? Like, those kinds of questions, you’re not stopping progress. What you’re saying is, like, “Let’s get even more out of it because there’s a really long burn-down list and you all want to get through all of it, but let’s see if we can squeeze more value out of it.”
And I think that’s a really good technique to kind of diffuse some of the tension between security and engineering and identity.
Yeah. You know, this tension, you know, we keep talking about prioritization. When security comes with a potential security risk that, you know, they found on an application or a product that we develop, we as engineers or product managers tend to see it as the most frightening thing in the world, right, because there is a risk, a real risk of security finding something and then we are kind of clueless on this.
And I totally agree on, you know, spending another breath and trying to understand, you know, okay, is this the most important thing to do now? Because security would say this is the most important thing to do now, but then spending another breath to take a look and to see how is it in different product?
Right? How does other products spend and mitigate this problem? Okay? You know, we’d make a lot of difference when you go and actually implement this. You know, a few years ago when we just started, passkeys was just, you know, getting started. And we were all, let’s add another mandatory MFA, let’s add another mandatory MFA.
All the MFAs, do them all, all the factors.
Do them all. I don’t care. Let’s make our users secure. But then, you know, eventually, it causes drop, you know…
Yeah. Okay. Sure.
…because, you know, the same product manager that you just talked about that want to have the frictionless login because any step in signup would add another 10% of drop, right? You don’t want the, you know, let’s not validate emails. We don’t care. Okay. Let’s bring them into the product.
Okay. Sorry, that… Ooh, that hurts my heart a little bit, but okay.
Yeah, I know. But that’s what a product manager would say because they want to get, you know, users.
Get the person to the thing. Get the person to the thing. Whatever it is, go.
But then, you know, if they would take a breath and take a look at the broader picture and they’ll see, you know, abuse on that signup that actually is killing the CRM. And then you have leads. I’m wondering around which lead is actually relevant for me. You know, what do we do now?
So that’s maybe, you know, a very good example of having the product manager not just thinking about frictionless but thinking about the broader picture of how does that signup experience completes the entire business purpose of the organization.
I totally agree. But the one thing that I think can be a shared activity, can be really fun as a shared activity, and really enlightening is threat modeling, and having all three sort of be clear on the threat that’s actually been identified, especially if security comes and says, “Hey, we’re doing our regular vul testing, just saw this. We’re going to categorize it, you know, Severity 2. It’s not, you know, life and limb, but it’s nasty and we need to put that in backlog. You guys need to start working on it.”
To me, it was always great to have that working relationship with them where they could effectively teach engineering managers, architects, even PMs, like, this is what it means, right? This is practically speaking how this could become exploitable. This is what we think our exposure is because I feel like everyone’s job is to do some form of threat modeling.
Even a non-technical product manager should be part of it, right? Because that then gets a sort of shared buy-in to an outcome, right? Like, I get the reason why now security are jumping up and down with your hair on fire, right? But we can then have a conversation of, like, I acknowledge, you know, what you see as the exposure here.
Let’s talk about, like, how exploitable is this? Does it have to be done today? Sometimes it does. Okay. Many times it doesn’t. And it’s like, “Great, then why don’t we bundle that in with a bunch of other work we were going to do on that same subsystem, and that’s going out in two releases. Can we make agreement on that?” Yeah.
And it comes from a, like, you understand the threat, you understand how they think about threat, and that really helps when it comes to prioritization.
Yeah. That’s perfect. And, you know, we now may be going into strategy on how we can collaborate between engineering. And then one thing that I find successful in the organization that I worked with is, you know, eventually there’s one goal for all of the employees of the organization, and that to have a successful product, obviously.
And if there’s one thing that engineering specifically like to do is hackathons. So we do hackathons around innovations, around AI, sometimes around quality. I found that doing a security hackathon, of having, you know, let’s spend three days, you know, full three days pizzas and beers, of coding, all of these, you know, top-notch risks that security brought into the table, and then we have a joint celebration around it.
And then you have around the entire organization, engineering product, security, they’re all, you know, aimed at one goal, which is to make the product more secure.
Adding to that, you bring product managers into it, they’re the world’s best chaos monkeys because it’s like, “Oh, we’re going to test sign up and sign in.” Cool. I would bring all the PMs to our bug bashes and we’d be like, “Just go nuts in the way you normally would,” right?
Like, weird browsers, odd configurations, sort of different kinds of social sign-in, like, all of it. Like, let folks who don’t know how it work bring my peer product managers to it and be like, “You don’t know how this works, and that’s awesome. Just try this script out and record it and we’re going to see what happens out of it.” You’re like, “Oh, my gosh.”
You just watch all the bugs start to go away. We’re like, “Oh, why is there so much friction there? Why is it taking so long here? Wait a minute. I sent the verification email, but I still let them in even then the screen said I wasn’t going to.” Like, you find all that stuff. So, like, bring the non-experts to that, and in certain settings, you can really learn a heck of a lot and build a better outcome. I mean, at the end of the day, right, like, that’s what it is.
It’s about…
Yeah, I totally agree. Yeah, 100%. Yeah. And, you know, eventually, you know, when everyone sits together in the same room and they have one joint, you know, purpose to solve, this is where it gets interesting. And, you know, you find security bugs, you find product bugs within, you know, security-related processes.
And this is where it gets interesting. And you have one goal for the entire organization.
Absolutely. Love it.
Cool. So maybe it’s a good time to maybe go and demonstrate how… You know, so in Frontegg, what we try to do is we try to bridge this gap of having engineers, clueless engineers, I would say, I’m sorry, you know, trying to configure and trying to code off pieces and security pieces, and then bridging that gap of delegating this to the security team from one hand and in another hand to the end users that are able to build their own security policies of logging in.
So I’m going to share the screen and show a bit of what we did in Frontegg in order to help engineers delegate security to the security team without the need of coding it. So a bit about Frontegg.
Frontegg is a XIAM IDP customer identity and access management and just, you know, to show how Frontegg is integrated into a React application. So an open-source SDK, and then these three lines of code that wraps around the application. Every application that wraps around Frontegg, for example, we have Loud API, for example, will have a non-authenticated user being redirected seamlessly to a login page.
Now this login page, this is pretty much all that the developer needs to do. Now this login page is, Ian, you know, we just talked about it, you know, you are able to delegate to the product manager to build their own security and login flows using a no-code builder.
And you talked about signup, right? So whether you allow signup or not, and it goes all the way towards consent management of whether you allow users to sign up and what is the terms of using privacy policy. Now, one thing that is important, you know, if you ask a developer, what does it mean to configure, you know, a password complexity?
You know, they are not pretty much aware of whether they should go with, you know, a minimum of six characters or 10 characters. They might say, you know, the hardest one is better. What does it mean? You know, what is the right number on password repeat protection? Okay? And should we verify emails on signup? So you have kind of a mixture of product decisions from one hand and security decision from one hand, and then the engineering is kind of caught between these two decisions.
So what we try to do here is try to prevent the engineering from getting confused. So delegating it to the security and application security team of being able to choose the right number. You know, each application can have different numbers. Same for everything on the login methods.
And even, you know, what does it mean on the token expiration and JWT signature? So when a user is logging in with Frontegg, there are a bunch of security events that goes into place. So each and every one of the login attempts that users are doing, you know, with Frontegg is being checked with multiple security checks, okay?
So obviously bot detections, whether it’s a recapture of Frontegg proprietary bot detection, device fingerprinting, brute force protection, whether we allow breached passwords, and each and every one of them, obviously impossible travel.
You can either… And this is where user experience and security plays together. Allow is pretty simple, right? So you allow users to log in. You can notify them that you detected something special, but you basically allow them. Block is pretty intrusive. You don’t want to let them in.
But I think that adaptive MFA, and this is where challenge comes into place, is a perfect mix between user experience from one hand and then security from another hand. When you challenge users, you say, “Listen, I’ve detected something abnormal over here, okay? I’m not saying that you are suspicious of something, but let’s prove that you’re actually who you claim you are.”
And then you mark this device as a valid device, okay? From one hand, this is your great security flow. You made sure that this is not an attacker, but from another hand, you created something trustable with that user. This user trust this application now. This user says, “Okay, I know that I’m protected.
This application protects my identity,” okay? And this is what I like about challenging users, okay, when I detect something abnormal. Same for suspicious IPs or stale users or even users that are signing up with email that fails credibility checks.
Now, when we did all that, okay, we let the users log in flawlessly. They know that they’re protected, okay? And that means that now this user allows themself to basically configure everything on their own. So you have an end users, and this is something that we find out when…
You know, we talked with developers and we said, “What is it that bothers you that you have to build?” Right? We talked about developers that don’t want to build stuff that, you know, they have no purpose in life of building. They came, you know, they joined the company to build innovation, and now they’re facing with let’s build another MFA screen.
So with Frontegg, we allow them to use something that we call an in-app component that allows the end users eventually to control their own privacy and security, okay, configure passkeys, configure MFAs, okay, and see the list of sessions that are logged in from.
And then it goes all the way towards a granular security within each and every one of the organizations that they worked in. So when we just started, we found out that companies are different. You have one organization that want to force MFA for…
You know, I’m sure that you’ve seen it, Ian, with many of your organization that you’ve dealt with. You know, not all organizations born the same. One organization want to force MFA for all of the users. Another organization doesn’t care about it because they delegate. And another organization, that organization cares about stricter session limits and forcing re-logins, while the other organization says, “I’m protected with MFA.”
Then you kind of face a challenge here because you set the default of the applications in a way that you think it’s going to serve all of them, but eventually, each organizations comes with their own needs and say, “This is what I expect your application to serve me with.” Now this is why we built this granular per tenant, per organization security.
So one organization with Frontegg can say, “I want to set forth MFA.” Well, the other organization says, “I don’t care about it, okay? What I care about is forcing re-login or having maximum concurrent sessions set to one. So every user within that organization, okay, can connect only from one concurrent session or only from one, you know, device concurrently.
And then for the admin of that organization, you can see bunch of security recommendations of what should you do in order to strengthen your account security. And one of the funniest thing we discovered is that IP restrictions, for example, I want to limit the logins to that specific application from specific VPNs or specific locations in the world, okay, was a very common scenario that we had, you know, to cook into the product where we allow users to log in only from specific devices or to deny specific potential threats from specific IPs or specific regions of the world.
And then obviously, it all has to do with specific domain limitations, specific IPs limitation, and specific, you know, security around what is an inactive users, and when do we log them out or delete them from the system? Another common scenario is roles and permissions.
So, you know, one another thing that we discovered dealing with enterprise companies is that companies are different, and each companies, you know, has their own, I would say structure, and then you have one company dealing with, you know, admin, viewer, operator, and a DevOps roles, while the other company needs other six roles, and then it kind of messes up your entire, you know, ABAC model.
So what we built into the system is a complete granular per tenant, per organization roles and permissions that, you know, any organization that is using Frontegg eventually, the end user, can generate their own roles and tie up different policies of how a user can log in, what permissions do they get, okay, and how this permission stands even towards invite users and providing them different access for different days to the organizations.
So that all ties up to basically providing from one hand, removing the burden for a developer, the need to build this stuff, but on another hand, once you delegate this to the end user and to the end organization, okay, you cannot remove the need from a developer to build that, the need for product to develop, you know, the thought around it.
Security is happy because that kind of, you know, check all the boxes that they need in order to mitigate this, and it makes the end customer independent of, you know, security support tickets, etc. So this is how we did that with Frontegg, and obviously tying it to security flows and everything with regards of that.
Makes sense? Cool.
So are you ready for some audience questions?
Yeah, let’s go.
All right. Super. You know, we had a question that came in from Ziman and it was before the demo. So he was asking about sort of what Frontegg does, and I think you gave a pretty clear explanation of that. He was also wondering what Weave Identity provides. And, you know, Ian, I don’t think we really went into that in too much detail. So I just wanted to get a sense from you about that.
Sure. So Weave Identity is an advisory firm that focuses primarily on identity, but also privacy and security. I help technology companies with their product, product strategy, product management functions, as well as go-to-market marketing and analyst relations.
So I’ve sort of engaged with different parts of the business to help them build a better product, engage with the market better, and sort of tackle some of the really tough product sort of management and product strategy decisions that lay in front of them.
You know, another question here. What are the parts of identity management that you think security teams care about the most?
Oh, man. I mean, at least in my experience, security teams focus on, in descending order, authentication, authentication, and then maybe a lot of security. And rightly so, right, because those represent some of the largest areas of exposure that organizations have.
And, you know, I say that lovingly. Like, I had a very good longstanding partnership with our CISO organization because that’s the only way we’re going to be successful. They did amazing things for us in terms of perpetually testing, perpetually probing, making sure we’re always self-strengthening. That’s great. And there is, you know, a lot to be learned from that.
But other functions in the identity domain tend to end up more with the CIO, things like how fast are we onboarding new workforce users? The CMO is going to want to know how smoothly are we converting people? Are conversion rates rising or dropping? Is there friction in the process?
So, you know, security has kind of carved a swimlane inside of identity out and other disciplines inside the enterprise are looking at different parts of it.
Yeah. You know, and that reminds me of something, you guys were talking about this in the conversation about, you know, a lot of times identity comes up, it comes into the conversation as a security question, you know, and engineering and security talking about that, but that there are benefits on the identity side too.
I think you listed a couple there. You know, are there other benefits that organizations can reap from, you know, really fine-tuning their identity processes?
Aviad, do you want to take a swing at that one? Maybe I’ll add some color to it. Oh, I’ll go. I mean, I think the…
Yeah, I would maybe add on… Yeah, yeah. Yeah, I maybe add on what Ian just said. You know, yeah, I’m sorry I’m a bit delayed here. So, you know, authentication is super, super important, super, super important.
But then eventually, you know, when you think about identity, what does identity stand for? You know, it’s how the user is logging into the product, but eventually, the access control piece is super important as well, right?
So, you know, we are meeting with a lot of security organization that cares about excessive permissions, for example. You have a user that, you know, he’s high privileged user, and now, you know, this user is a potential hazard on specific organizations, right?
Now, if this user, you know, is a potential risk or not, even if they have an MFA logging in, right, but they have, you know, much more permissions that they should have, okay, that’s another security hazard that is not covered by the authentication piece.
That’s an access control piece that you need to think about. In some of the organization that we talked with, we dealt with the authentication piece, we dealt with the logging-in piece, okay? But now this organization comes and says, “Okay, you are covering role-based access control.” There is another authorization piece that comes from the user subscription management, and there is another authorization piece that comes from the feature flagging.
That’s an authorization problem. That’s not an authentication problem. The user is already in there, but now this user is allowed to do stuff that I’m not sure that they’re, you know, allowed to do actually. And that’s a security plus engineering problem, okay? It’s related to security, but it’s not an authentication problem.
MFA won’t solve it. Passkeys won’t solve it, bug detection won’t solve it. This user is legit, okay, but it’s now become an authorization problem that in some cases, the identity piece needs to solve. So that’s another use case that we keep hearing about, right?
And, you know, it’s not related 100% to the authentication piece.
Okay, great. Yeah, so another question here, you know, and you guys were going into this a little bit too, but this question is, can you share an experience where the relationship between security and engineering teams, you know, impacted a project outcome either positively or negatively?
And so I’ll go to Aviad first on that one.
Yeah. So I think one of the examples I gave on the signup, okay, where on one hand, product said, “I don’t want any email verification on signup.
Let’s remove verification. I want to get the users as fast as I can,” okay? And, you know, the decision was, okay, let’s do a PLG frictionless signup, go straight to onboarding, and then you have, you know, crazy, you know, email spraying attacks on signups. And then come security and said, “Okay, let’s add email verification.
Let’s allow only business emails. You know, let’s make sure that we add credibility checks,” etc. Then a few months later comes business, go-to-market, and says, “Okay, we had a huge drop of signups and, you know, some of the Gmails actually that tried to log in are legitimate users if you take a look at them.
You search your LinkedIn profiles, okay, these are viable buyers of the product. So, you know, on one hand, you know, when you open too much, okay, you cannot get a heat, but when you close too much, you get another heat.
So this is…you know, and it’s a true story that happened in one of the companies that I worked with. And then comes a decision, you know, that’s exactly the battle of who actually wins. Eventually, you know, you find a middle ground, but think about the time that you lost and the number of potential leads that you lost, or, you know, the amount of mess you made in your CRM, okay?
To clean that up is actually revenue lost to the organization.
We’re waiting for him to reconnect. You know, Aviad, are there some misconceptions that security teams have about the role of engineering and identity management, you know, and vice versa?
Yeah, it’s funny. If you ask a security team on engineering, okay, they’ll say they don’t care about security, okay? These are the top three misconceptions, right? They don’t care about security. They avoid our guidelines, okay?
And they’ll come to us only when, you know, there’s already fire, you know, to put out, right? So these are the three misconceptions. While, you know, when you ask engineer about security and say, okay, they come with too many guidelines. They don’t care about fast pacing, okay?
You know, they slow us down, okay? And these are the bunch of guys that don’t know anything about technology and just care about compliance. And so these are three misconceptions, but eventually, you know, they’re not true. You know, they’re truly, you know, sprint-based, fast-paced, you know, processes around security. And there are a lot of guidelines in engineering as well.
You know, it’s just a matter of speaking the same lingo.
Yeah, well, I mean, I caught the tail end of what Aviad was saying, and following on the question you asked. Look, the relationship between identity, security, and engineering doesn’t just happen on Tuesday once a month, and that’s it, right? It’s a continuous relationship. And so the better that those organizations treat things as that continuous relationship as opposed to here’s a requirement, punch the ticket, close it, go away, then you get that shared language, you get that set of shared experiences, and you get a shared set of outcomes.
And so it’s to me, very important that none of the three are in the habit of just sort of throwing a requirement over the fence and walking away from it, right? We’re all living with the outcome. We’re all trying to shoot at the same target here. We just have different tools that we’re going to do to bring that to bear at the job. And so really taking that to heart and building teams around that, that’s where you can really actually get wins out of those relationships as opposed to an antagonistic relationship.
Got you. Yeah, that’s great advice. Well, so we’re… This is probably a good place to leave it. But Aviad, if somebody wanted to get started with Frontegg or find out more, what would you recommend?
So just frontegg.com. There’s a Start For Free. No credit card required. You know, the docs is probably a good place to see some of the stuff that we’re doing. But, you know, if you’re an engineer or a product or a security, this is what we talk about. Probably, you know, get your hands dirty with the product is where you want to start.
The Complete Guide to SaaS Multi-Tenant Architecture
