Often without an owner who members even creating them.
So, we've been spending the last decade, you know, securing human identities, and you know, attackers obviously still go after human identities, but they also noticed that there's a new identity pathway, and that is the NonHuman Identity. So, really, over the next few minutes.
We're going to go through, you know, these new attack paths, or maybe not new, but maybe ones you haven't thought about, and kind of walk through real attack paths, right? So, and these are not ones that, you know, Craig made-up. These are actually ones that are live in, you know, from an attacker's perspective today.
Organizations have already felt some of these. And I want to spend a few minutes going through kind of the roadmap. So the quick roadmap, we're going to start with the hidden Identity attack surface, what those objects actually are, why they count as identities. Then we'll get into the specific permissions that are putting your Tenant at risk.
And then really, the most of this session is going to be around those attack paths. And then I'm also going to not only tell you about the attack path, I'm going to help you understand how to mitigate and do some detection as well.
And then lastly, we'll close with how Cayosoft can help in the NonHuman Identity space. So again, right, the hidden attack surface, right, is this every App Service Principal, AI agent is an identity and really a potential attack path. And I mentioned earlier, we spent a decade hardening user identity
through what we put in controls like MFA, conditional access, and even password policies.
So, let's get into...
why identity is more than users. So if we look at app registrations, right, so what are app registrations and Entra ID? Well, really, they define an application and the API permission it requests, right? Each is unique identity in your tenant. And then if we dig a little bit deeper into service principles,
This is where the credentials and the actually granted permissions live.
This is also where these are the ones that the attackers target mostly. And then if we look at the next group, which is workload identities, these are the apps, service principles, and managed identities. And what I want you to understand about these, they're authenticating as themselves. They're never as a person.
So there's no human that challenged this authentication. And then the latest group of identities, and honestly, probably the most growing one, and probably governed the least, is agent identities. So agent, these AI agents.
They authenticate and act on their own. And again, they are the newest and probably the fastest growing NonHuman Identity to govern. And then I want you to understand, in Microsoft Entra, default settings, if you have your default settings configured, they let all user register apps and consent.
to them quietly, right? So basically that widens the attack surface.
So now let's understand the two different types of permissions inside of Entra ID, right? So delegated versus application permissions. So delegated is permissions that are acting on behalf of a signed in user, and they're usually capped.
by the user own rights. So less dangerous, not saying completely harmless, but less dangerous. But when we get into application permissions,
These permissions grant an app, standing app only access.
No user has to be present and no MFA required.
A lot of times, they're tenant-wide scopes, right? Like Directory read, write all, they apply across the whole directory, not one mailbox or user. And consent, right? So consent is either through delegated consent or admin consent.
So really what we want to understand, the line between a read-only integration and a tenant takeover is often a single consent click on an application permission.
So let's dig into this a little bit more.
So there are, I'll say these are the most 4 common ones that attackers hunt for, right? So if you remember nothing else, remember these particular settings in an environment. So these are permissions that put the tenant at risk. Now, are these all the permissions that are putting your tenant at risk?
Absolutely not. There is a bunch more, but these are the most ones that attackers hunt for. So let's start by looking at the first set, which is rule management read-write Directory. So what is it really allowing us to do? It allows us to grant or escalate our directory rules.
up to and including global administrator.
If we move over to Application Read Write All, this allows us to add credentials to any app or Service Principal, and then also impersonate that application. The next one is App Rule Assignment Read Write All, right? So this assigns app roles, which really becomes a stepping stone to higher Graph access.
So if I can assign app rules with read write all, then I can actually grant myself more permissions in Microsoft Graph. And then here is the one that we all need to be extremely aware about. Directory read write all, right? This is broad write access across your users groups.
and all directory objects. So I'm going to ask you a question, right? So do you know which applications in your tenant hold these today?
Honestly, most can't answer that. And that's the problem, and that's why we're here to discuss this. So I'm going to talk some numbers, and I don't want you to focus too much on the numbers, but I'm going to talk about a couple of them. So 39% of third party apps request high level permissions.
So, that's a pretty high number, and I would say it's even growing.
I'm going to skip the 0 and come back to that here in a minute. 60% of cloud breaches involve compromised workload identities.
90 plus days, right? The unused apps and credentials often linger unnoticed.
So...
If you haven't inventoried your applications in your Entra ID, I bet you you have some unused applications and credentials that are way beyond the 90 days. Usually, it's far longer. Now, I'm going to go back to that one that says 0.
And I want to really kind of focus on this one, right? So 0 multi-factor authentication prompts can stop app only off, right? A stolen secret just works.
So...
I want to make sure we understand that yes, MFA, it's great for user accounts and other accounts in our organization, but app-only authentication, it really doesn't work for. So you need to look at it from a different perspective.
So now we've talked about some of the permissions and what we need to look for inside of the environment. But now let's look at some real world attack paths, right? So how hidden permissions become full tenant compromise. And I want to tell you that this is, again, not me saying this,
This is actually drawn from public security research. And I actually have some of the attribution, and we'll talk about some of those attacks. So if we look at this one, and I'll say this is probably the most classic one and still most common, is these four steps. So it's called illicit consent grants.
So what's happening, right? So when an attacker stands up or controls an app that requests broad Microsoft Graph permissions, the next thing happens is phish, right? So an e-mail lures a user into clicking the app on the app's OWASP consent screen.
So setups, minutes, lure, one click, and then access, right? So access, the app gains a refresh token, standing access for the users, mail files, directory data, depends on what they granted access to. And that access is immediate.
Now, here's the thing that I want you to understand is, resetting the password or MFA does not help, right? That malicious app keeps its own token and it persists until someone actually goes in and revokes it.
Where have this been used? Well, it was used as part of the Midnight Blizzard attack. Shiny Hunters uses this, you know, common technique. Historically, Storm 0324 as well. So again, setup takes minutes. The lure is usually one click.
And it persists until someone explicitly revokes this.
So now let's understand what we can do from a mitigation perspective. And really, mitigation is mostly one decision. Now, there's several I listed here, but I want to say it this way because if we take self-service consent away, we're going to basically
will prevent one of the biggest areas for this, right? So self-service consent. If we restrict consent to admins for privileged or unverified apps, we use consent workflow. And then obviously we follow least privileged. From a detection, we need to look at.
Entra logs for consent to applications and delegated permission grants. We need to be able to enumerate grants, but also there's things like the Fender for Cloud Apps to flag risky or overprivileged OAuth apps. We want to also be able to trigger alerts on new secrets added to Service Principal.
and unusual token activity. So if you take one thing from this deck, I'll say go enumerate your existing consent grants this week and see what you're finding.
The next one I'm going to get into is privileged role on a service Principal. And again, this was part of Midnight Blizzard, but it's used by others as well. So what is it? Right? It's A low privileged user, right, owns an app whose service Principal holds privileged authentication.
Administration role or another role which gives them standing access if they're an application owner.
I can add a secret to that app, right? So the attacker adds a client secret to the app, and then I authenticate as app only, right, beyond the user limits. And then if I can go in and reset admin, right? So with that rule, they can reset a global.
Administrator password or add a temporary access password, or even once they get global administrator, they can actually go in and create new as well, right? It bypasses multi-factor authentication altogether, which means it can result into a...
complete tone it takeover from a tenant perspective. So app ownership is a privilege escalation path. You need to understand who owns your applications inside of your organization, especially applications that have write permissions.
inside your organization. I would also say, not only do you need to understand which applications or which owners own which applications, but you want to make sure that those users, those app owners, are not using hybrid accounts.
in your environment that they are using cloud-only accounts with multi-factor authentication for additional security.
So what can we do about this one? So first of all, never assign privilege authentication administrator or equivalent to a service principal, right? That's the root cause. You need to restrict who can own those apps, right? Strip standing owners of privileged ones if you can.
Also, from a detection perspective, you need to audit your role holders, right? Review which service principles hold privileged roles, right? Trigger, again, create a new alert in your environment, trigger when a secret or certificate is added to an application, because again, with a certificate.
or a client secret, an app secret, I can authenticate as the application.
We also want to watch resets for admin password resets and separate access pass creation for these types of owners as well. So these are, again, things that will help you.
basically mitigate the privilege role on a service Principal. Is it going to stop all attacks? No, but these are things that will actually help you get in front of, you know, a larger attack occurring in your organization and you might be able to cut it off sooner if you're looking for some of these signals.
So, the next one again.
Was part of...
Midnight Blizzard, it's also part of Nobellum. It was actually part of the Microsoft breach in January of 2024. And what is this attack path, right? So it's Exchange Online Service Principal Hijack, I call it. So what am I doing? I'm adding a credential, right? So in an actor with Application Read Write All.
adds all, basically adds a secret to the Exchange Online Service Principal.
Then I inherit the power of the first party Service Principal, right? The main right role, I can forge tokens, right? So then I can add a federated domain, forge SAML tokens for any hybrid user, right? And then impersonate. So those forged tokens act could act as a global administrator with no password needed, right? So.
What's this allow, right?
This allows then the attacker to basically access Exchange Online and other resources if beyond Exchange Online if they do so. So again,
Well documented attack, Midnight Blizzard, Nobelo, Microsoft Breach. This will happen in January of 2024, but this still works today. If I were to stand up in an environment, and it's honestly not that hard to build this out and prove it. So what can we do around some of these, right? So
Again, we want to limit app admins, right? So give application administrator and application readwrite all to a few trusted admins. You want to also protect your first party service principles, right? So monitor credentials on Exchange Online Service Principal for this particular one, but extend it to all. Restrict who can add or change federated domains.
So how do you do this? Well, privileged Identity Management, right? So make sure you understand that as well. So not everybody should be able to add federated domains in your environment. Very few admins should. And no one should really have standing access to add.
build federated domains. It should be backed by privileged Identity Management inside of Entra ID.
Again, you can create alerts on secrets added to first party or Service Principal. You can also create alerts to monitor new federated domains and domain authentication events, and you can also watch for unusual SAML token use in impersonation sign-ins.
Now, I will be releasing A blog later this week or next week that I'll actually teach you some Sentinel alerts or techniques for setting up alerting, as well as we'll get into how Cayosoft can help here as well. So the other thing I will say is you want to make sure that your...
reviewing power holders, right? So audit who holds the main read write all and understand their activity.
So here's a new one, right? So it's, I'll say an emerging threat. So it's OAuth client ID spoofing. And I can't take credit for this one. So this was Proofpoint Research, so thanks to Proofpoint, as well as Help Net Security. And this was recent, July 13th of 2026.
So what is this new attack and how does it work? So ROPC abuse, wow, let's say that 10 times. It's resource owner password credentials flow with a spoofs client ID, right, through an OAuth 2.0 token. So credential, so really if inside of...
Um, Entra, there are these Entra.
tokens and these answer tokens, when they fail, they carry an error code, which can help an attacker reveal whether a username exists and whether its password is valid. And the one that really is this 70016
It returns when the username and password are both correct, yet no successful sign in is ever logged. So it's very stealthy, right? So it usually doesn't log an application name, so it shows up as a blank app name. It's a spoof client ID, leaves the application name field.
basically empty on ultra sign-in logs.
So, it's tried against usernames that do not exist, so they don't ever reach sign-in log at all. Detections miss it.
So what can we do to defend against it? Well, you can block ROPC using conditional access to disable legacy and resource owner password credential authentication. You can hunt blank names right inside of your application logs and your sign-in events, as well as look for...
the particular one that has the SDS 70016. So again, and then I'll say enforce MFA. Now what I want when I say enforce MFA.
It's not enforcing it on the application, it's enforcing MFA on all users, right? Because that also prevents them from successfully then taking over the user account. So MFA does work in this scenario. So again, this is an emerging threat, and it's something that's...
So organizations need to know that it will exist and also need to understand how they can attempt to identify this type of technique occurring in your environment. And then also what we can do to help with defending against it as well.
So here's one that I don't know if we always think about, right? So why are the workload identities are different, right? So these are NonHuman identities that break the assumption that we built around user accounts, right? So every control we built for user identity.
Assumes a human was at the other end.
So we put in things like multi-factor authentication. Doesn't really apply to workload identities, right? So apps sign in with secrets or certificates. Multi-factor cannot protect them.
We normally have some kind of lifecycle around user identities.
But that's not the case for workload identities, right? They rarely have owners. Joiner, mover, lever?
Right, or an expiration date.
So that doesn't really work very well because we don't treat them the same way that we treat a human identity. And then stored secrets, right? So these credentials, they must live somewhere and they can leak from coding, right? So.
or CICD pipelines or configuration of our applications sometimes carry these. And to be honest, these workload identities are standing access, right? The app only permissions apply tenant line and usually around the clock.
That's why user-centric security programs miss this entirely. So these are a different type of animal that we need to address from an identity perspective. But we need to apply the same rigor that we would apply around user identity, right? We need to have a lifecycle. We need to have owners. We need to know what they have access to.
We need to make sure those secrets are stored securely. And if they're no longer needed, right, those workload identities should go away as well.
So this is the newest population that we're going to talk about, and that's agent identities. And why not? Right? So agent identities are the fastest growing unmanaged identity, and really access controls haven't caught up. So if we look at some numbers again,
97% of AI related breach involved AI with improper or missing access controls.
Here's a number that really stuck with me.
Ten 1000 credentials can spawn from just 10 agents, each calling 100 tools. Now you could multiply that. You can certainly, but that's pretty a big number, right? Ten 1000 credentials can spawn just from 10 agents. Another one that is really...
that made this hit home is Entra Agent ID, right, reach general availability, making agent first class identities in 2026.
So they're here to stay. And now, OWASP now ranks Agenic AI threats in a dedicated top 10 risk list. So agents are being deployed by the business.
Faster than security teams can govern.
And this is becoming a growing problem for many organizations.
And what I want you to understand is agent identities multiply the risk, right? Autonomous agents magnify every NonHuman Identity risk and most run ungoverned. Right? If we look at a couple of these areas, right? So excess access, agents inherit broad standing scopes well beyond the tasks they were built for.
In a lot of cases, token sprawl, right? Every agent and tool call spawns more keys, tokens, and secrets to guard. The blast radius could be huge. One compromised agent can act across many systems in seconds.
Depending on what that agent actually does, it may cross multiple systems. And if it crosses multiple systems, it means the impact is large to organizations. And then here's one, right, that we're still trying to figure out.
is how do we do lifecycle around agent identities, right? So most agents ship with no owner, offboarding, or expiration once deployed.
So again, agent identities, they're multiplying the risk.
Once inside of our organization, right, if they have access of access, and they can have a large blast radius. And with the weak lifecycle management, they're really ungoverned identities in our organization.
So, let's look at one of...
You know, how you know an attack path in regards to agent Identity takeover.
And really, this was founded by AIM Security. So again, we'll give credit. It was called Echo Leak. And this one really is around planning the prompt. So what do we know about prompt? Right? So an attacker hides instructions in an e-mail or document the AI agent will later read.
The agent ingested, right? The agent auto pulls the content in the contacts and obeys it as a trusted instructions, no click needed. Now there are some new guards around this, but...
Not all of them work the same way. And then this leads to escalated access, right? So the injection rides the agent standing permissions to reach the internal files across connected sources. Or can even redirect me to a malicious site, etc. And we've seen this with some more recent attacks.
And then, depending on what this AL user has access to, it could be tenant-wide, right? So, the data is exfiltrated through auto-fetch links, images running as the agent with no user or MFA. So, again, so agent data.
is instructions and really that collapses the boundary every other control depends on. So again, a prompt attack, it's been proven. The real, now there again, there are some newer guardrails that are going in place around prompt attacks, but they haven't been completely mitigated.
So what can we do around that, right? So from mitigation perspective, we need to really scope each agent using least privilege. Also, it needs to be task-specific access.
So, no broad standing rights, no shared API keys.
You need to filter inputs through prompt injection filtering, right? Conditional access gate, so gate agent sign-ons on risk with conditional access, Entra ID, P1 or P2 plus agent 365. Govern lifecycle, right? So assign owners, expiration, and access reviews to every agent identity.
and retire idle agents just like you would offboard a user.
So how do we detect some of those things, right? So use Entra ID protection for agents to flag unfamiliar resources, accessing the sign in spikes, look for token replay, so alert on agent tokens used from unusual IPs, resources, or at machine scale. That's another one really to understand.
Well, it's not just, you know, a single IP. It could be multiple IPs and a machine scale. Again, right? These things can replicate very quickly and multiply very quickly. So, and then also watch for failed access attempts that suggest an attacker are probing with an agent's token. Monitor agents.
reaching data or external links outside of their normal pattern. But before you can do that, you have to understand what that agent is supposed to do to understand what their normal pattern is.
So we've talked a lot about these new NonHuman Identity attack paths. And really, I want to be able to help you close some of these gaps, right? So how do we do that? We need to govern permissions, enforce least privilege, and watch for abuse.
Inside of our organization.
So let's break this down. So govern apps and consent, right? So first of all, restrict consent so only admins approve the apps and agents needing privileged permissions, right? No wide user consent inside of your tenant.
So admin consent, that workflow routes request through a review instead of, again, that silent self-service grants, as well as apply.
the app instant property lock to block credentials on sensitive service principles. And here's one, right? Remove the unused, retired, orphaned apps inside of Entra. Right, so flag apps idle for, start with 90 plus days.
I bet you if you go and audit your app, your environment today, you're going to find applications out there that haven't been used in 90 plus days. Start with them. Now, do not immediately go out and remove them, but without following your normal change control process, but start putting a plan together to get those applications.
you know, removed from your environment. If they're no longer used, why carry the unnecessary additional attack surface in your organization? And then this is one that we all live by with humans, so we need to apply that same thing to, that same kind of concept to
NonHuman identities in our organization, right? So, shrink what every identity can do, and for how long? So, least privilege, right? So, make sure you're granting the narrowest Graph scope, preferred delegated over application permissions. Again, delegated is going to run under what the user.
has where applications are more broad. Right size your rules, right? Replace standing global admin with just-in-time scope rules. Definitely do that. Use privilege identity management, no standing access, credential hygiene. So rotate secrets.
And I would say go one step further, not just rotate secrets, prefer certificates over client application secrets inside of launcher ID and managed Identity. So also set expiration, right? And set it short.
and to make sure that those credentials are not living no longer than they need to. And then you can also apply risk-based conditional access to workload and agent identities using Entra ID as well.
So again, detect and monitor, right? So here's a couple signals that you can kind of focus on. So what can you do, right? Credential events, alert when a secret is added to a service principal or a first party app.
We definitely need to alert when role changes, right? Review audit logs for new app role assignments and directory role edits.
Federation drift. We may not be watching, you know, which domains are being added to our Entra ID tenants and what settings are being changed in regards to our existing domains. So we need to watch for new federated domains and unexpected token signing changes. Even modifications to our existing domains is something. You know, consent grants, right? Track new consents, apps flagged.
Agent behavior, flag AI agents acting outside of their normal access patterns, right, scope or hours.
So, again, these are things that you can kind of go back, talk to your team about, and see what gaps you are looking, you know, you may have already in your environment, and these are some steps you can immediately take to help shore up your environment. So, I'm gonna hit on where Cayosoft kind of fits into...
of NonHuman identities, right? So if we look at the manage aspect, right, so enforcing least privilege administration, we clean up the stale rules inside of the organization. From a monitoring perspective, we continuously detect risky permissions, credential changes in real time. We can also roll back malicious directory changes and restore a trusted state fast. And then help you stay compliant. We can prove control with continuous audit ready reporting. And again, it's not just human identities that we're covering. We're covering these NonHuman identities as well.

So...

Keep that in mind. I think Drew will share some links after this. But before our final close, there are four things I want you to walk away with. So the first one is NonHuman identities, they're privileged, and they are real identities in your organization. And I'll say they're most of your NonHuman identities carry privilege, right? So apps and service principles hold rules.

They hold secrets and consent that rival admin accounts in your organization. The attack paths are real. An old app, an app role assignment, first party service principles, spoof client IDs, these each lead to a tenant takeover. So if we're not watching for these signals, we don't know that these applications exist in our organization.
We're putting ourselves at risk.
We need to govern the identity, not just the user. We need to enforce least privilege control, consent, and ownership, rotate or remove those standing credentials, and...
We need to watch for the right signals, right? Alert on those new secrets.
role and federation changes, as well as sign-ins with blank application name. If we go back to the newest attack that I mentioned earlier. So those are the four things that you can take away. Go back to your organization, see if they exist, which ones you're currently.
addressing and where you might have gaps. I appreciate you guys tuning in and learning more around NonHuman Identity from Microsoft perspective, and I hope you guys learned something from this session. Drew, I'm going to turn it over to you to see if there's any Q&A.

Drew Fuhrman 38:48
Yeah, we had a couple of questions come in, Craig. Thanks for giving the presentation. Really appreciate it. Great content. There were a few questions that came in while you were speaking in no particular order. Andrey asked, you know, what's the estimated ratio of non-human to human identities these days? Do you have any, you know, idea? I didn't know how to answer that one.
Yeah.

Craig Birch 39:13
I mean, it's growing every day. I will say that. And there is, so 100 to one is what we're, you know, a lot of people are saying, 300 to one I've seen, right, as estimated. It depends on who you ask. I can be clear on that, right, and who's stating it. But it's obviously, it's a concern. It's growing very quickly.
Well, 300 to one is not something that, you know, is unbelievable, and especially with all the Entra ID applications, manage, you know, identities, etcetera, and and now agents, right? I mean, a lot of organizations are quickly moving to agent identities.
and we need to wrap our hands around this before it becomes a larger problem than what it is today. Great question.

Drew Fuhrman 40:01
Yeah. Kevin had asked, of all the attack paths you've presented today, which is the most commonly observed in customer environments today? And if an organization could only address one of those within the next 30 days, where would you recommend that they start?

Craig Birch 40:18
The Entra ID applications that have write permissions, specifically the four ones that I called out earlier, right? So, I mean, application, rewrite all, role, etc. So those are the ones that I would focus on today. And then also another area, once I identified those.
or any of those applications, stale applications. How many times, and I'm guilty, right? I'll say right now, I am guilty of this one. How many times have we maybe stood up an application in our environment to test out, you know, maybe a new technology that required some elevated rights, and then we didn't go back and retire that application?
Or maybe we bought that application a long time ago, and you know, you know, from a product or a project perspective, and that project's gone and the application never got retired because there's no life cycle around it. So check for that 90-day, right, as well. Those are the two things I would do right now.

Drew Fuhrman 41:13
Mhm.

Craig Birch 41:19
Understand which ones have elevated rights, specifically those four rules, and we can share that out after that, as well as understanding those applications that are just stale. Why keep them in your environment if they're not being used? They serve no purpose.

Drew Fuhrman 41:35
Yeah, no, that's great. Thank you, Craig. There were a couple of questions that came in about availability of an on-demand recording and the presentation materials. So I do just want to reiterate, yes, all of that information is going to be sent out probably within a day or two. So just, you know, check your emails. Again,
you know, probably tomorrow-ish, maybe by Thursday, you should have that information. I also want to promote our next webinar. Craig will be joined in a couple of weeks here, actually. We're going to have another webinar titled The New Reality of Microsoft Identity Recovery, Entra ID, Hybrid Identity, and Operational Resiliency.
I posted the link to that webinar in our chat. And I also posted a link for Cayosoft free Guardian Protector tool. This can help you address a lot of the ideas and the threats that Craig was talking about today. So this is a free tool that we provide to our community.
And that leads me to the last question that came in here. Stefanos actually asked, does Guardian Protector have a public API or web hooks for integrating alerts and incidents with external monitoring or NOC platforms? Craig, you're the one who came up with Protector. Maybe you can speak to that one for us.

Craig Birch 42:53
So in regards to alerting, it's going to be through either Teams or e-mail for protector, the free. Guardian itself, the paid versions, can integrate into the SIM, etc. And we most recently have a new integration with Sentinel.
But protector is going to be through Teams and e-mail. Once it's in the Teams and e-mail, right, you can actually then use other applications to send it into your SIM, et cetera, if needed to. The other thing I want to say about Guardian Protector is everything I just covered today around these.
NonHuman Identity attack pass.
Every version of Guardian addresses over 95 percent of these risks. So regarding...
know what flavor of Guardian you own, including Guardian Protector, which Drew mentioned. It's free. You can go download it today. It's going to help you understand, first of all, which applications have those high elevated rights. It also will tell you if you have old applications, as well as...
More importantly, if someone adds a new credential, right, or a new certificate, it can alert you in real time. So it's not just a one-time audit capability, it is live real-time monitoring with build-in threats around NonHuman identities. In fact, we have.
They build in filter just around to help you quickly understand NonHuman Identity attack paths from an Entra perspective. So, I would encourage you guys to, you know, go out and download it. It's free, even if you have any another product in your environment. Defense in depth is real.
Right, so run them together, and hopefully you'll see some true value there. Is there any other questions that came in?

Drew Fuhrman 44:47
Yeah.
And, and Stephanie.
Nope, I didn't see any other questions, but I would also add, Stefanos, if you're still out there, I did drop in a link to the paid version of our Guardian platform too. So please feel free to go check that out. It's available. We have tons of links to, you know, walk through those products or talk to our sales reps if you're interested in those as well. So
I think that's going to be it for us, Craig. Thank you again so much for your time. This was really valuable. I thought that it was riveting. I was listening the whole time. I thought it was great content. So we're going to give everybody some time back this afternoon. But thank you all for joining. We really appreciate your time. And so we're going to go ahead and wrap it up.
Thanks all. Have a great rest of your day.

Craig Birch 45:33
Thanks for joining us.