How to Extend Identity Automation to Every App, Including Disconnected and On-Prem

Alright. Hi, everyone. Welcome, and thank you for joining today. My name is Aaron Yee, and I'm cohosting this session with my colleague, Rick Weinberg. Today's session is focused on a problem that I've been wrestling with, for almost my entire career. I've been in identity management for a while, and that problem is how do you manage identity life cycles for disconnected applications without it being manual, painful, and then error prone. So if that resonates with you, if you're running into that problem, this this session is perfect for you. But before we dive in, I just wanna give you a quick sense of where I'm coming from because I want you to know that it's not just a product pitch. This topic is personal for both me and Rick. As I mentioned, my background is almost entirely on the technical side of identity and access management. Started out as a developer. And early in my career, I was creating provisioning workflows for the Air Force as a government contractor and building these these workflows in Sun Identity Manager with Express. So how many of you remember that technology? After that, I moved on to Okta because I could see that they are doing something that the legacy identity vendors weren't doing, and that's solving identity for the cloud era. And that was back in the early twenty tens. And then more recently, I joined Cerby for a very similar reason. Cerby is solving a problem, that major identity platforms still aren't addressing, and that's what do you do with all the apps that don't support modern identity standards, disconnected applications? And I heard that problem raised by customers again and again when I was at Okta. Nobody had a clean answer for it. Cerby does. And that's what we're here to talk about today. But before I do that, Rick, you also bring a deep identity background to this conversation. Can you share a little bit about yourself with the audience? Yeah. I know. Yeah. Hi, everyone. My name is Rick Weinberg, VP of product here at Servi. Thanks, Aaron. Yes. We we do share some commonalities. I've been in the identity space for, gosh, going up to twenty years now. And, yeah, this has definitely been an ongoing challenge for for many, organizations over the years. I think progress is made, but there's, you know, there's always room for more improvement. And I think, you know, hopefully, you'll see at the end of the day that there's there's there's, you know, some real value to be had there. And, yeah, like Aaron, we actually share something in common, Aaron. I too worked for an express line of a large company's, identity management product. In this case, I worked on TIM Express, was actually the first product that I managed, TIM Express. Many moons ago, didn't do so well. Be that as it may, excited to talk with you today about this topic. Great. Aaron? Yep. Next slide, please. So here's what we're gonna cover today, and I wanna be deliberate about this because we designed this session to give you real actionable insight, not just a product tour. Our goal is threefold. First, we're gonna examine why traditional identity platforms like your IDPs, your IGA solutions struggle to automate life cycle management for disconnected applications. If you're if you are an identity practitioner, you probably have some instinct for why this is the case. We're gonna put a sharper point on that. Second, we'll walk through the security, the compliance, and the operational risks that these gaps introduce. It's not just workflow inconvenience. It's meaningful risk exposure, that most organizations are underestimating. And then third, we'll show you how Cerby bridges that gap, bringing the same kind of automated controls that you're used to for your other core connected apps, now for your disconnected apps, all of your disconnected apps in your environment. So here's the thing. I'm willing to bet that everyone on this call has both connected and disconnected apps in their environment, and the goal is to build a strategy that can handle both. So let's get into it. There's a a deeply held assumption in enterprise IT, and it is understandable. And that assumption is that, eventually, every application, every vendor will support modern identity standards like SAM SAML for authentication and then SCIM for provisioning. The thinking goes, vendors will eventually get there. We just need to wait it out. And in the meantime, we can manage the exceptions manually. I hear this constantly from identity practitioners whenever I go to conferences, whenever I talk to folks. They they think it's fine, except it's not. And the reality has not met has not matched the assumption. So here's the thing. Application vendors actually have legitimate reasons for not supporting these standards. One, engineering complexity is real. Implementing SAML and SCIM take real identity expertise, that most product teams don't have. And even if they are able to build it, the ongoing maintenance is pretty problematic. Two, on top of that, most SaaS vendors are running lean with competing priorities, and identity standards adoption, rarely drives growth for them, or it rarely shows up in product demos. It stays at the bottom of the product backlog until enterprise customers make it a hard requirement to, you know, purchasing it. And then there's the economics. Right? For vendors who aren't primarily selling to large enterprises, there's really no financial incentive to build these capabilities. And for those who do, you guys see this, they often lock them behind premium tiers of licensing, which is known as, you know, the SAML tax for authentication and sometimes even the SCIM tax for provisioning. So the result is that SAML and SCIM adoption is still far below a hundred percent. Saml's a little higher, and SCIM is very low. We'll talk about that on the next slide. But the gap isn't closing as fast as anyone had hoped. And, meanwhile, the number of applications keeps on growing. Right? Saas sprawl is real. Shadow IT is real. And even on premises and legacy environments, they're they're not going anywhere. So the manual management of disconnected apps has become the norm. Right? It's not the exception. And manual management leads directly to security risk and operational drag. And what most people underestimate is they think disconnected apps aren't high risk apps. They think they're low risk edge cases, but we often see that these are actually business critical tools holding sensitive data. Right? These disconnected apps are HR systems, financial platforms, collaboration tools, even proprietary internal applications. So the assumption that these apps are low risk is one of the most dangerous assumptions in identity. Next slide, please. So I wanna put some numbers behind this, because the scale of of the problem is important to understand. Ninety three percent of applications lack SCIM provisioning. So read that again. That's only seven percent of apps have SCIM support. That means the vast majority of your application portfolio, the tools your teams actually use, cannot be managed through standards based provisioning. And this isn't getting better. Application adoption keeps on increasing. It's accelerating faster than identity teams can handle it. It's accelerating faster than the vendors are putting standards into them. So every quarter, organizations are adding new SaaS tools, deploying new internal systems, inheriting legacy applications through mergers and acquisitions, and the gap in the portfolio just continues to grow. So the result is a proliferation of disconnected applications and with them increasing security risks. That's the structural problem that Cerby was built to solve. It's not a workaround. It's not a patch. It's a purpose built platform for disconnected applications. Next slide, please. Right? Before I wanna go before I go further, I wanna make sure that we all are using the same terminology, because a disconnected app can mean different things to different people, and you might have heard alternative terms such as nonstandard apps, unmanaged apps, etcetera. We think about disconnection in two dimensions. The first dimension is authentication. Does the app support SAML or OIDC? Can you connect it to your identity provider so your users can log in via federated SSO? If the answer is no, it the app is disconnected on the authentication side. You have no centralized control over it. The second dimension is provisioning and the life cycle management angle. Does the app support SCIM, or does it expose user management APIs that your identity platform can then build connectors to? Can it use it to create accounts, update roles, deprovision users? If the answer is no, the app is disconnected on the provisioning side. Now here's the important nuance, and this is something that surprises a lot of practitioners. An app can be federated with SAML and still be disconnected because it doesn't support automated provisioning via standards. So it's partially disconnected. You might have SSL working beautifully, but if the app can't support SCIM, if it doesn't support provisioning, it's it's disconnected in our view. Next slide, please. So why do disconnected apps create risk? What happens when you have a significant portion of your ecosystem outside your identity controls? The first is security risk. Right? When provisioning is manual, accounts get created with more access than necessary because it's easier to over provision access than it is to figure out the exact right permissions every single time. And when people change roles, or when they leave the organization, deprovisioning is incomplete or delayed or not even handled at all. And so the result is persistent access that shouldn't exist, which is textbook identity risk. And this is pretty common in breach threads and investigations. The second is compliance risk. If you cannot automate life cycle actions for an application and you're relying on manual effort to do this, you don't really have a reliable audit auditable record of who has access to that app. There's no authoritative source of truth, so when auditors ask for evidence, and they will, you're kinda scrambling to pull together all of this information with spreadsheets and tickets and emails. So audit findings in this area, disconnected apps are really common. They're increasingly common, and then regulators are paying just closer attention to to this. Lastly, it's operational drag. This is probably where you feel it the most. Manual provisioning means tickets. Right? Lots of tickets. It means someone, an application administrator, maybe IT, has to provision or deprovision access whenever an employee joins or leaves. It means access reviews are really painful. So these three risks compound each other, and they all trace back to the same root cause. Identity platforms weren't designed to manage apps that don't speak their language. So this is where Cerby comes in. Think about your modern identity, architecture. You likely have an identity provider like Okta, Entra ID, Ping, handling authentication and provisioning. You might have an IGA solution like SailPoint or Savient, you know, to do governance and access reviews. These are excellent tools, but they all share the same limitation. They work by connecting to the app via standards like SCIM or perhaps user management APIs. And if the app doesn't expose those types of interfaces, you really can't reach those platforms, so there's a gap. Service sits in that gap. We integrate with your existing stack, your IDP, your IGA, and we extend their reach down to the applications that they cannot connect to natively. So this includes SaaS apps without SCIM support or user management APIs, but it also includes on premises apps and includes legacy and homegrown systems, tools that your business units have procured and and now manage on their own manually. So what used to be disconnected now can be fully managed and secured using your same identity tools, your same processes. Those have now just been extended to disconnected applications. Servi complements what you have. So what does Cerby do? I'll give you a clear picture at a functional level because I want this to be concrete. It does three things. First, it extends the controls you already have in your IDP and your IGA system down to disconnected apps just like we talked about on the previous slide. It integrates with your platforms. It doesn't replace it. And Cerby listens for, you know, life cycle events, a new hire, a role change, a termination, and then it executes the corresponding action in that disconnected downstream application. Your current identity investments, just get extended. It becomes a lot more powerful. Second, Cerby, connects the applications that your identity platform cannot, and that's how it actually does it. So that includes SaaS tools. That includes, on prem apps and so forth. If there's an app with a a user interface, Cerby can connect to it. And lastly, Cerby automates the identity controls that you're used to, and you would otherwise have to do this manually for disconnected apps, but these are the same identity controls that you use for your connected apps. So that means automated account provisioning and deprovisioning, automated, credential management, which is kinda new to to these disconnected apps, policy enforcement, and visibility also into your disconnected apps. So the bottom line is Cerby closes the gap. Every app, it can be managed. Every access decision is auditable. It's clean, and it's automated. Now I'll hand it over to Rick who will talk take you through some of the use cases where Cerby helps out, peppered in with his great knowledge of this space. Thanks, Aaron. Yeah. So I think, you know, to start, you know, we see a number of our customers just really looking to leverage, as Aaron pointed out, the their identity provider, you know, to just core provides it for joiner mover lever provisioning. It's it many cases, it can be sort of push face event driven. Right? If there's an event detected there, it might be tied to user creation. It could be a group assignment. Right? That ultimately triggers downstream changes to those disconnected apps that Servi manages. Right? And so in this event, you know, as as Aaron pointed out, Servi is responsible for executing the provisioning policy that is defined in this case, you know, say, it's Okta or Biantra. Right? And and, you know, making sure that, you know, we align that, you know, desired state with the, you know, the current state, so to speak. And so, know, as we as we look at this, you know, we're really, you know, helping you eliminate manual provisioning, you know, for those apps that, you know, are not SCIM enabled. Right? And and we do those, as Aaron touched on, for, you know, those SaaS apps that don't have modern identity, either protocol support, or on prem apps, whether those exist, you know, in a browser based app behind the firewall. It could be a client based app, behind the firewall. And and that's either because, again, they they don't they don't sort SCIM or, as Aaron touched on, they don't have user management APIs. And and at the same time, we, you know, don't intend to drive and create, integrations for where there already are out of the box connectors, you know, from your IDP or even your IGA for that matter. And so, you know, as as many of you know, the benefits here are are are very tangible and real. I mean, you you not only have faster time to access so the users can be much more productive, you know, than they perhaps, you know, were, and just get them there as quickly as possible. The reduced manual workload, right, not only helps reduce the cost to support that, but also it reduces potential for, you know, error. Right? And you're not having to, you know, make perhaps, you know, fat finger a provisioning, you know, event as an example. And, of course, there's time to, you know, offboarding as well and and or suspension of access, right, that is is vital for ensuring that the the so it it it strengthens the security itself, you know, and, of course, you know, providing the the relevant, you know, auditing logs, to to ensure that you, you know, have what you need for compliance purposes. Right? So there is that side of it as it relates to, you know, again, the joiner mover lever life cycle motion, from the IDP. I would say, you know, to complement that, we we we see this from the IGA, the identity governance administration side of the house, in particular where Servi provides life cycle and compliance automations that really extend those governance workflows. Right? So not only, you know, can Cerby do this sorry. Can do we support that same scenario where you might have an IGA IGA provider provider, but it extends beyond that to these additional, governance workflows. So we do this by, you know, first, of course, aggregating user entitlement data, you know, to perform a regular synchronization, you know, aggregation. This, of course, provides the ability to deliver effective governance so that you can constantly have a clarity on, you know, what that, you know, native state is on the disconnected app and how that harmonizes back to the the IGA system of record. Right? And so how does this manifest? Right? It stems from across a number of different governance use cases. Again, whether that's part of the automated JML life cycle or even as part of an ad hoc user request that's been approved. Right? I'm thinking as it relates to compliance, right, it might be tied to an access certification campaign where a user's access is determined no longer needed, or maybe they moved on to another project. Or, you know, maybe it's tied to a separation of duty policy scan that identifies a conflict. In many respects, Servi doesn't necessarily care what drives it. Again, we're serving the policy. We're executing the policy that's typifying by your IGA provider, and we're executing against that. And so all those scenarios fall for a need for remediation of access, which we execute against. And so, you know, as we look at this, of course, that data synchronization also has benefits just on its own relative to visibility to to truly improve your organization's security and compliance posture because now you've been able to extend and bring these apps that have been out of your visible control underneath that sort of perimeter, if you will. So now you have visibility and and can see a given app's a given user's access, know, on that particular app, and that will certainly simplify your auditing and reporting and and need, particularly, for your access certification campaigns in in in many respects. So, you know, as we touch on here, as you bring that in, you now don't have to run your certification campaigns for those disconnected apps by, you know, say, a spreadsheet or even at the same time, you know, not having to drive, you know, these automations, you know, even ad hoc, or they might be tied to a trouble ticket as an example. And so, you know, we just find that there's a real opportunity to continue to, complement and extend the value you've already invested in with your IGA provider and how we can extend that much further and and build that security posture up, not to mention, you know, the the comp to support the compliance needs that you have. So how do we do this, and and and how is it different? I think first, it's it's looking at the traditional approaches that, we've seen to solve this problem. I mean, I touched on it just a minute ago. We see a number of instances where you might get some visibility, right, via a flat file, or perhaps you've leveraged a JDBC connector to, you know, bring in users and their access users and their accounts, you know, so you can see that. And there's value in that, of course. But you're still dependent on a manual execution via a trouble ticket, say, in ServiceNow. Right? And so it it's nice to get some of that visibility, but you're not getting the benefits of the automation itself. And so in other instances, you might have investments for building a custom connector. Right? And, you know, while there's value in that, it it has proven to be quite costly. As you can see there, at the same time, it it takes a while to develop and ultimately deploy. And not to mention, and probably even most importantly, they can be quite brittle to maintain, especially when you might be leaning on a third party to support that. It it becomes quite complex. And so where survey comes in is we can certainly, you know, not only look first at our app inventory that continues to grow, but, you know, drive rapid configuration and or creation of those integrations themselves. And at the same time, do that in a matter, you know, of of days to weeks, not, you know, weeks to months, right, in terms of what you're getting. And most of all, we manage it for you in terms of the maintenance itself, and we'll talk a little bit more about how. But in terms of, you know, managing Drift and and how we can apply, fixes or there's self healing associated with that. I'll also add to that. There's probably some apps that you can't even connect to even if you wanted to via traditional connector building because maybe the apps don't even have SCIM or APIs you can build against even if you wanted to to build something there. Yeah. No. That's a great point. I mean, it it it I think many of these apps, Aaron, as as you touch on, you know, it you know, exist because they don't have the the reason just kinda they don't have the APIs. Right? They might be in some cases, they have internal APIs that are undocumented, but invariably, you know, they're very hard to connect to. And and we we, however, have means to do that, and that kinda is a segue into the next, you know, slide here. And and how do we, you know, scale and manage and connect to these apps to to begin with? I think, first of all, when you're in a situation where that integration doesn't exist in our inventory and you're looking to have it built, you know, how do we do that? Right? I think the first thing is you've gotta be able to observe how that you know, how the the workflows that are associated with that particular app that you want to ultimately create an integration against. So when you're dealing, though, with an app outside of the identity perimeter, you're gonna be dealing with the line of business. Right? In in many cases, there's gonna be explicit workflows that the app owner has created to support that. But we need to observe how the user uses the app. So many rare cases, we lean on a Servi extension we call Scout to enable the user to train survey on how to carry out those different workflows that might be, you know, creating a user, changing an attribute. It might be offboarding a user in these different life cycle automations. Right? And as, you know, in this case where we don't use the APIs, but they don't have them. Right? So we interface with the app against a UI that you'd leverage that browser extension or, in in this case, lean on undocumented internal APIs. And and, ultimately, that data that we collect as part of that can be fed to us in a sort of a a a DOM structured data format. Right? And and it goes through an encryption process, converts that, you know, in a way that that is then ultimately assigned with a key to your particular workspace in Cerby. Right? And that helps ultimately create the integration. The challenge with that, though, is once you've created that baseline, we feed that to our machine learning models, but we have to monitor change. Right? And and so if there's a change to the app itself, you know, we need to find a mechanism to be able to to to manage against that and support you. And so we what we do today is we detect when there's a change that's made, and evaluate. Are we aware when we isolate that's a change relative to that application and not something that's on the customer's environment or to do a survey? We then will evaluate, is this a a known set of drift where we can auto heal directly, and we'll apply the fixed ones that's the case. And a majority of that's the time that's the curves. Of course, there are instances where that fall outside of that. And in in that case, we still have a human in a loop to support that corrective action. And when that is is done, it's a question of how do we then feed that back into the learning mechanism so that when we apply that fix, the models continue to learn so that self healing expands. And, you know, again, we have a broader and, you know, array of known, you know, types that we can then self heal against in the future and and don't require that human in the loop. I think the key here is that that whole motion is the the plane of the app creation itself. Right? You know? And and and once we actually do that, one of the things that it's important to note is we are very particular about the approach we take there, but we're not using that, you know, agentic model, you know, where we lever lean on our our you know, the training itself, but also to manage self healing. We don't do that to run the workflows. We are very specific about running the workflows separately. We have a deterministic execution engine. And the reason for that is because we found that even in the recent, you know, change advancements, you know, on the agent side, the the when an agent directly interfaces with the apps, we've encountered two things. One is still a significantly high, hallucination rate. Like, anything over one percent is high. And in some instances, depending upon the app, we can see it up to forty percent. So we don't want to, of course, drive these critical, you know, identity automation, like, when you have that degree of unpredictability. And then secondly, leveraging agent to capabilities that needs to reason and interact with the UI, you know, at runtime can be very slow. And so we wanna take this we take this combination of a deterministic execution engine with you know, on the running of those workflows, coupling that with a very, you know, AI centric approach to create them, you know, to drive the scale that we need. And so that's the realm of, you know, the app creation and and putting that in, if you will, into operation. Once those app integrations have been published, the integration between the, you know, IDP or IGA and Cerby has you know, then you know, and that's been established itself. We then can enable life cycle automations to happen. And and here, we, you know, generate a a SCIM gateway that connects to the disconnected app itself. And then that when that gateway provides essentially SCIM endpoint capabilities to the app and and enabling it to receive those notifications. So in that example we mentioned earlier, we might be triggering an event from the IDP, and that that that's where a group, you know, provisioning deeper driven group deprovision event has has been detected. And then once that's once we've received that, we can then verify the operations performed and perform that provisioning action within the integrated app itself. But let's take a look at actually how we do that. I'm gonna just shift over here for the sake of the the demo gods, so to speak. I am doing a super demo instead just to to to walk you through this. But as we do that, it's important to showcase that oops. Did I lose you? No. There we are. That, in particular, we're gonna showcase a provisioning and deprovisioning event from, you know, a SaaS app, in this case, Amazon Developer Hub. And in that event, we're going to showcase, you know, basically, just how we look at rolling this through again, just granting, alternative as a user here in a provisioned event, and then we'll deprovision as well. And so this, you'll see we're in Servi. This is our integration dashboard. And as part of that, you know, you've got you'll have a list of your different, integrations here. And then when we if we were to drill into the developer hub, in which case we're gonna showcase provisioning for here, you know, you're gonna get a lot more depth in what's available as part of that. And so, you know, within that, you can see this this particular integration is up to date on this particular workspace, what when it was last updated, what was the last workflow type, when there was a synchronization performed with that target app, you know, what were the numbers of users and roles, you were brought back and forward, you know, giving you that detail that you're seeking. This, of course, is an integration that's already established. We're not taking you through the creation of it, and how you configure it. But in this case, when we actually want to take on a a provisioning event, in this case, we're gonna leverage Okta in this case. So we've switched out of Cerby. Now we're in Okta. And in that event, for Okta, again, they're defining the provisioning policy, you know, ultimately, and then Cerby's executing against that. Well, in Okta, you know, as we look to assign a user to a group, in this case, we've defined an Amazon developers group in Okta that is is particularly for any users that have the marketing role in Amazon developers can be assigned this particular in our this into this particular group. And so when you when you drill into that, you can eventually see, first of all, that there there are no particular users, you know, provisioned in this particular role. And then when we drill in further and you want to assign a user to that, it it showcases the potential users that can be, you know, assigned to this particular group. And so in this case, we're gonna select Paul Turner. And as we do so, you know, we can drill in and and, of course, we we're doing this to showcase this individually, but this, of course, being done via API and scale. But if you were to add Paul, that will then trigger the SCIM event downstream for us to execute that provisioning event. Once Servi receives that, we're about now back in Servi. We'll go in the developer HUD. We then complete that provisioning action. In this case, you're now looking at our automation log, which details the status of each of the events that has occurred. In this case, we have a provisioning event that's occurred, and and in this case, on Amazon Developer to showcase that Paul has been. So to go back out, we'll go into Amazon Developer, and you can see Paul Turner is now is now part of that marketing role that we have assigned to him as part of that group based provisioning that originated in Okta. So that brings into the provisioning side of the equation. The same thing can be held true onto the deprovisioning side. So if we're back in Okta and we want to initiate a deprovisioning event, again, whether that's triggered here manually or done automatically by the policy, you know, you would click on that the x to to remove, and and and that would trigger the the group removal, assignment removal that is within Okta, which which again triggers Cerby downstream. And, again, once you go into our our automation log, you see that indeed a, you know, a b provision event has happened in this case on Amazon developer, you know, Business Hub or Developer Hub as part of that. And so when you go back out to Amazon Developer, Alternate is no longer there and has successfully been deprovisioned. So that gives a quick summary of just a a demo of provisioning and deprovisioning event to a SaaS app that does not have SCIM enabled. Obviously, you know, we'd love to be able to showcase a little bit more detailed demo for those of you that are interested, you know, you know, going forward. But with this, I'm gonna turn it back to to Aaron, and let me pick up where we left off. Oh, Mark. So I think just go back to my screen. Think I've lost it. Forgive me. There we are. Perfect. I think we can go two slides for Greg. Oh, here we go. So we have several customers on this slide, and we won't walk through all of them today. But I wanna spend a few minutes on monday dot com because their story is one that I think will resonate with a lot of you. You might know monday dot com as a a work management platform. And what you might not know, though, is that by twenty twenty four, they had surpassed one billion dollars in ARR growth, and they had grown to more than twenty one hundred employees. So they had phenomenal growth. During that time, their IT team had connected they use Okta. Their IT team had connected close to a hundred fifty applications to Okta using, you know, SAML and SCIM, but they hit a wall. They had hundreds of remaining applications, that simply did not support these standards, and they had no way to automate provisioning via Okta. So their IT of their director of global IT, Lior, he said, hey. We hit a wall. Traditional identity tools can't bridge the gap. What do we do? So to them, that gap created real operational cost. Their team was spending more than thirty three hundred hours per year managing identities manually. That meant new hires waited days for access. Shared accounts required manual password resets. Audits were just a complete pain. And Monday dot com evaluated, you know, whether they should build custom connectors to do this, or they even looked at robotic process automation to do this. And they realized that neither of them would really scale to their needs, and so that's when they found Cerby. The the value was pretty immediate. Once they integrated Cerby, I think they got close to two hundred apps integrated in in one year. Like, these are apps that weren't in Okta. So they got two hundred apps integrated with Cerby in one year, which is unheard of if if you're an implementer. And disconnected apps started appearing in the Okta dashboard alongside everything else, which is pretty neat. Cerby handled the authentication for those applications in the background, so that includes, like, credentials, filling in the MFA. But even doing credential management, you wanna, you know, rotate the passwords for these disconnected apps every thirty days for security purposes, all without user intervention. And then life cycle management became fully automated. Access was granted on day one to new users. Access was revoked when it was supposed to get revoked when someone, you know, left the organization across every disconnected app, and the impact was pretty dramatic. At the start of twenty twenty five, only twenty percent of their apps were centrally managed. By the middle of twenty twenty five, that number had jumped to seventy eight percent. So that was all done with Cerby's technology. And the results were those three thousand three hundred IT hours, that were spent manually managing these these apps disappeared. Right? So that saved them more than four hundred thousand dollars in life cycle management costs, which equates to a two hundred eighty percent ROI. I'm not making these numbers up. I'm reading them off of the case study on our website, and you can go there for for more details. So that's real outcome that's at real outcomes at real scale. And monday dot com is representative of what we actually see across our our customer base. Next slide, please, Rick. So that's what survey looks like in practice. I wanna close with what it means for your business because, ultimately, that's the conversation that matters. The headline number is an eighty five percent reduction in manual effort, and that's not theoretical. That's what our customers are actually experiencing when they deploy Servia across their disconnected application portfolio. And I wanna unpack what that actually translates to in practice because the number only tells part of the story. It means faster onboarding and offboarding. New employees get access when they need access, including all of the disconnected applications. And when someone leaves, that access is complete is terminated completely and cleanly. It means stronger security and audit posture. There's no more orphaned accounts, no more over provisioned access sitting around because no one got around to cleaning it, no more scrambling around to produce audit evidence from spreadsheets. Survey gives you that auditable record for these disconnected apps. And, of course, it means reduced ticket volume for your help desk. Every provisioning and deprovisioning system or every provisioning or deprovisioning action that used to require a manual ticket is now fully automated. So that's what it looks like when this gap is closed. Your life cycle automation that, you know, runs from your IDP or IGA system just gets fully extended to these disconnected apps. Next slide. So now that wraps up the the formal presentation. I now wanna open up the q and a to the attendees. So start dropping your questions into the chat if you haven't already. And then Rick and I will be happy to answer those. Yeah. Aaron, it looks like we have one here. And so I mean, I I think you can take this one out. But right off the gates, nothing like that. Right? How is Servi different from building a custom connector through our IDP? I love this question because I used to build custom connectors. Great great question. We hear this, a lot, because custom connectors are the traditional answer to this question. The challenge with custom connectors is the economics. I used to be a systems integrator, so we would we would charge anywhere from twenty thousand to sixty thousand dollars, building a connector for a given application depending on the complexity. And that's that allows your IDP or your IGA solution to then automate, actions in the in the applications. But when you factor in the scoping, the development, the testing, and the deployment, not only is it not only is it cost prohibited, it just becomes really lengthy. It takes, you know, months to to build this, test it, and get something that's actually production quality in in place. And that's only just building it. The problem with traditional connectors too, like Rick mentioned earlier, is you have to have you you need to provide upkeep and maintenance for it. So if the application changes its APIs, if they deprecate calls, who's on the hook for, you know, updating that? Well, you are. You have to hire consultants and professional services to come in and go through that whole process again. Cerby takes a fundamentally different approach like what Rick talked about earlier. Instead of relying on SCIM or proprietary APIs, which many disconnected apps don't have, Servi uses UI automation combined with AgenTic AI to interact with applications in the same way a human would, but automatically and at scale. So that means we can connect to virtually any application without the limitations of needing it to support SCIM or or APIs. That the practical difference is we can onboard a new application in days because, like what Rick talked about, we're we're training we're training this interaction, right, with our approach. So we can onboard a new application in days instead of months at a fraction of the cost, and the connectors that we have or the integrations that we have are self healing. So that means when an application changes, and it will, the APIs will change, the UI will change. We use AI to detect that drift, and then we self heal. So we'll correct it. We also have backups. So like what Rick mentioned, we have a human in the loop process if, for instance, the AI can't make a definitive decision. So our approach is faster to deploy. It's easier to maintain and just presents overall dramatically lower TCO for for customers. So it's far less maintenance and headache for for you. Great. Thanks, Aaron. Looks like we have one more, but I encourage you all to ask questions here, if you have them. I can probably take this one. It says, what about on prem apps? I think you touched on this a bit, but can Servi really automate those life cycle management, you know, like, automate life cycle management for apps behind the firewall? And, yes, the answer is we can. And it you know, we look at, again, those on prem apps kind of falling into two categories, those that are, browser based, right, or those that are, you know, more thick client based, you know, many variable, in many case, Windows, desktop apps, if you will. But it yes. We can. And so the idea here is we have, basically, an agent based model that allows us to, support, the ability to provide that same type of survey automation where we, in the main variable, have a a funnel that's created with this agent to, provide that survey automations that you'd expect. So you can perform the same, whether it's the life cycle automations or even access automations depending upon the situation on those on prem apps just as you would with those that are SaaS. I think the discovery part of that, you know, for the browser base, we can lean and leverage our our browser extension for those sick clients. It it it does require a little bit more exercise to to gather the the components to go and and ultimately create the integration if we don't have it, you know, as part of that. But on the whole, it is something that we see a number of our customers lean into because that's where they have a lot of their disconnectivity. And and especially for large enterprises where you have a heterogeneous environment, and Variable still have a number of those applications out there. Looks like we have a question here from one of the audience as well. And and we've also got John Elton on here who might be able to assist with this one. There's a question here that says in the demo earlier, how is the response time to app actions like group member group membership changes in Okta? John, as you hear that, you know, I I know there's ultimately lots of factors that could affect response time, but maybe what what what comes to mind as you hear that? Anything in particular that you wouldn't would see being a bit closer to it than me? Yeah. I think there's sort of at a high level, there's kinda two pieces there. I mean, first of all, from Okta or really any, you know, sort of the upstream identity platform, where the SCIM connection, is is set to to then connect to to Cerby, that's gonna be pretty much instantaneous. I mean and then so, you know, for instance, in the demo where we would have clicked on that, you know, added in the the Paul Turner, user into the group, it would have immediately sent the the scam, command out from from Okta to Cerby, and we would have received it and started working on it. The I think part of the the bigger question probably, though, is is, okay. That's fine. But when when Cerby receives it, how long does it take to to go run that the the the process to enact that that request on the downstream application on the the disconnected app. And so it's not instantaneous, but it's pretty fast. And so what what we will what you will see is that, yeah, it's it's gonna be pretty quick on in in most cases. That's that's I mean, they're given, you know, variability and things like that. It's pretty fast. Yeah. No. Thanks, John. There's another question that's come in here. It says, can Servi handle apps that only just I guess, maybe only provide just in time provisioning, I e, to set permissions once the user is created? And, yes, the answer is yes absolutely to that. And as I I think touched on in earlier, especially when you might be relying on, say, you know, Okta, Entre, and you just wanna push right at the time of, you know, the the creation where someone needs access to the account, create the user, create the account, boom, go. We can handle that. It's just a question of, you know, how it aligns and where it originates from. But more often than not, it's just a question of doing so directly through and from, in this case, say, you know, your IDP as part of that. Don, anything else to add or correct there? No. I think that was that was spot on. Okay. Okay. I think there might be a nuance of that question. I don't know if the We just got another question here. I'm sorry to interrupt. To clarify, curious if there's a polling period to Okta system logs or basically a real time streaming logs to Cerby. I don't know. Maybe I don't know. Jeff, you know, offhand. We might be able to follow-up with you offline on that. Will, thank you for sharing that. If yeah. Let let us let us come confirm and and get back to you on that specifically. Sorry, Aaron. I didn't mean to cut you off. Did you did you wanna expound on the other questions? Oh, yeah. So previous question was around JIT provisioning. There's a nuance there. I we can unpack if the if the person who asked the question wants to provide additional details. Were they specifically talking about SAML JIT provisioning into Okta, like or into the app? I well, I think for the benefit of the rest of the participants, perhaps we can also follow-up with, in this case, Paul, offline. Paul, if you have one of our step further, let's let's happy to do so. But I think, given where where we are in the time, we should probably move to to to part here. Thank you all very much for taking the time to spend with us today. Hopefully, you educated and learned a bit more about Cerby and how we provide life cycle automation. And, Aaron, any last parting words from you? Yeah. If if today's session, you know, sparked questions specific to your environment, your app portfolio, your disconnected apps, your IDP, your governance challenges, the best thing you can do is to get a a personalized demo, not just a generic product tour, and we can customize that for for your needs. You can scan that QR code that you see in front of you or just go to that URL. Rick and I are also happy to continue the conversation directly. Feel free to look us up on on LinkedIn. So, yeah, thank thank you all for your time and attention today. We know you have a lot of competing demands, so thanks for setting aside the time on your calendar. We appreciate it. Thank you all. Have a great rest of your day. Take care.