Stop Over Privileged Access in M365 with Virtual Tenant Segmentation

Good morning, good afternoon, and hello wherever you are. Welcome to this webinar, where we're going to talk about how to stop over privileged access in Microsoft 365 with Virtual Tenant Segmentation. I'm very happy to be joined by Rob Edmondson, Senior Director of Product Marketing in CoreView, and his colleague, Siam Rochanavichit, who's Solutions Architect at CoreView. My name is Jonathan Care, and I'm a Lead Analyst with KuppingerCole. Just a couple of housekeeping points for this webinar. You are muted centrally, and we are controlling the features.

There's no need to mute or unmute yourself. We're going to run a poll during this webinar, and we'll discuss the results during Q&A. There will, of course, be a Q&A session at the end of the webinar. You can enter questions for me or for the CoreView team at any time using the Livestorm control panel. Please note that we are recording the webinar, and the recording and the presentation slide decks were made available for download in the coming days. So without further ado, let me go straight into this.

As I said, my name's Jonathan Care, and here's our poll for today. So the question we're posing is, what is your biggest challenge with managing privileged access in Microsoft 365? Is it too many users having global admin or elevated rights? Is it the difficulty of segmenting access between departments and projects? Perhaps a lack of visibility into who has access to what, and you don't feel you have the tools to implement least privilege effectively.

So as I said, during my presentation, you'll have the opportunity to address that poll, and I look forward to reading and discussing the results during the Q&A. Without further ado then, let's get into it. Microsoft 365 is no longer just a suite of productivity apps. We think of Word, Excel, PowerPoint, but in fact, it's evolved. It is the central nervous system for most businesses, and it underpins critical functions like communication, data storage, collaboration, and of course, identity management. And this makes it fundamentally different from a standalone SaaS application.

This deep integration, the digital nervous system, as Bill Gates once called it, at the heart of our business creates unprecedented security challenges. Our traditional security tools, which are primarily thinking about network perimeters or endpoint presentation, frankly fall short when you are trying to secure a cloud-first environment. And when we think about cloud-first, of course, the one that comes to mind is Microsoft 365. And we need to think bigger as architects, as security managers, as CISOs.

We need to be thinking about the scale, the complexity, and the interconnectedness of Microsoft 365 data and services require a specialist approach to security. If we ignore these challenges, then we leave ourselves vulnerable, our clients, our customers vulnerable, our suppliers, or indeed, our upward supply chain are vulnerable. And relying on these traditional methods is simply insufficient to find today's threat landscape.

So, as I said, we need to think beyond traditional SaaS. We need to think about the complete business environment. And Microsoft 365, as I've said, is no longer just a collection of apps, but it's the very infrastructure supporting modern business. So let's look at three key points in that. And the first is the identity foundation. Microsoft 365 acts as the center of the business. It's the central identity provider for the entire organization.

It's not just for Microsoft 365 access, it controls access to all business systems, sometimes even including telecommunications, making it a critical control plane for security and operations. So if this goes, everything goes.

Second, let's talk about the security fabric. Microsoft 365 increasing is becoming the cybersecurity infrastructure itself. It is the fabric. It provides built-in protections, compliance tools, and of course, monitoring capabilities that safeguard not just Microsoft 365 data, but the broader business environment operations and IT landscape. This gives us this complex ecosystem. And I cannot underemphasize the complexity. It's not a single purpose SaaS application. It is intricate web, interconnected services, data flows and configurations.

And this complexity means it cannot be secured or managed with the same traditional approaches used for simpler applications. It demands a specialized and integrated security strategy. And the takeaway, the thing I want you to remember from this slide and the whole presentation, if nothing else, is that securing 365 is not an isolated task, but it is a fundamental requirement for the entire organizational security posture.

So, the crisis of privilege. And we hear this term used a lot, but I'm of course referring to this in the focus, the locus, if you like, of our cloud-first environment. Microsoft 365 is a critical privilege environment. And what does this mean? Existing tools will struggle to manage access effectively, which means without proper controls, a single misconfigured permission can lead to a catastrophic breach. And what we're highlighting here is the privilege escalation risk in the Microsoft 365 ecosystem. And authorized access can spread rapidly like wildfire.

The image, as I'm showing you, is that house of cards, and it is, unfortunately, there's some weight to this. A privilege escalation attack exploits vulnerabilities, gains wider system access across the entire Microsoft 365 tenant, and organizations must, therefore, have robust privilege management solutions to secure their critical Microsoft 365 environment. Let's look a little bit deeper. This is a problem, and as the late Professor Ross Anderson said, of complexity and scalability. This is not a simple one-shot SAS tool. This is a organizational-wide challenge.

And we have seen, all of us, existing tools are inadequate for managing the vast number of privilege users in the case. So it's not that Microsoft is bad. It's not. It wouldn't have the market dominance it does otherwise. It's the complexity and the scalability create a massive attack surface that cybercriminals can exploit. So it's not the CISOs are bad or lazy. We're not. But we are having to manually review privileges across an enterprise, and that's virtually impossible, even for the most dedicated and fired-up switched-on SecOps team in the world.

And there's, of course, the other dimension of shadow admin accounts. Once they're there, for one good reason, they tend to proliferate, and they remain undetected.

And when, of course, they are exposed, this further increases the risk. And so the solution is automated privilege scoping and continuous monitoring capabilities that traditional security tools lack. And this is a critical issue that organizations must address to reduce their exposure to privilege-based attacks. I talked about scale, and as I said, the late Professor Ross Anderson mentioned scalability as the big challenge to all of us as security practitioners in his inaugural lecture at the Royal Society. Happened to be in the audience, which was a great pleasure.

The sheer scale of Microsoft 365, all of its configuration elements, with over 10,000 options, makes manual management completely impractical. Traditional email security configurations with around 200 settings are already difficult. Anyone who's looked in their email client, anyone who's looked in their email server configuration, you know how complicated these things can be. And imagine 10,000, but if you say that's a stadium of people, that's like trying to know everybody, every individual in an event stadium individually.

So manual configuration, it's not just impractical, it's actually impossible. And this is beyond argument. Automation is essential for survival in this new reality. Microsoft 365 has become so complex that human oversight alone, the best, the most fully staffed SecOps team, cannot keep up, it's impossible. And so automated tools and processes that use automation are now a necessity, not an option. So I want to talk here about the dual risks. So we talked about the complexity issue, but let's actually talk about some operational ongoing issues.

One is security posture drift, and the other is the disaster recovery gap. On the security side, we have an ongoing challenge with configuration changes across thousands of settings, and I've talked about that. And without automated monitoring, I've made the point that the posture will degrade over time until the next breach occurs. Think of it like rust, think of it like, yeah, drift, as indeed it is. But let's look at the disaster recovery side. We have complex environment with slightly complex configurations that I've just described.

It's going to be impossible in a disaster recovery scenario to recreate this manually. Documentation, the best documentation in the world will become outdated. That's part of the security posture drift. And so the organization becomes vulnerable to extended outages. And we can see this in the world around us. Well-reported cybersecurity incidents are experiencing this security posture drift.

So the key message here, the key thing that we as practitioners need to think about is that we need to be championing for actively addressing both security and disaster recovery to fully protect the Microsoft 365 investment and ensure business continuity. Let's talk about the contractor. And in this case, contractors can be sole contributors, individuals, and even be workers from a supply, a software supply company, IT service supplier, a part of the manufacturing supply chain or the logistical supply chain. So contractors is a fairly wide umbrella that I'm using here.

And all of these people, well-meaning as they are, pose a unique risk to your security and access controls. It's critical to have a robust user lifecycle management process to onboard, manage, and off-board contractors effectively. And we've always talked about the joiners, move, and leavers problem. This throws into sharp relief. For joiners, we need to ensure that automated onboarding with the appropriate access levels and security controls exist from day one.

As contractors move roles as they do or change responsibilities as they do, we need to ensure their access is adjusted accordingly to maintain security while enabling business continuity and indeed operational continuity as well. And of course, when contractors leave, we must revoke their access across all systems immediately, especially systems and data.

Now, I posit to you that every system, every piece of data is critical. You may say to me, well, why are you just talking about contractors and not employees as well? Because contracting tends to be more dynamic. We're not thinking of people who've engaged in a multi-year career here. We're thinking about people who perhaps are there for six months, maybe 18 months at max, and then they move on, which increases the task required for lifecycle management. I mentioned the supply chain, but I'd like to dig into that a little now.

Supply chain attacks have increased dramatically since 2019 with breaches often originating through trusted vendors and partners who have legitimate access to systems. Third-party risk extends beyond just IT vendors. It includes suppliers, logistic partners, professional service terms, and any entity in your extended business network. It could be your business ecosystem. It could even include your customers. The average organization shares data with 89 different third parties. Only 54% of organizations have a formal third-party risk management program in place.

And of course, this is written extremely large when we think about the software supply chain. So let's look at that. Key vulnerabilities, software dependencies, open-source components. The one thing that S-Bomb's highlighted is how much of that software we pay for a lot is actually based on open source. Vendor credential compromise.

Again, these tend to be privileged access credentials. Inadequate vendor security controls. One of the dirty secrets about a lot of the breaches is that there are common components like common supply for IT services, common suppliers for software components. And of course, let's not forget, there's a fourth party here. It's not just our vendors, it's the vendors that supply our vendors. Recent high-profile breaches, and they're in the news, so I'm not gonna name them again.

All these demonstrate how a single compromised vendor impacts thousands of downstream organizations or can impact significant national and indeed worldwide brand names. And so effective security risk part, third-party risk management requires continuous monitoring, not just point-in-time assessments. Vendor risk management is an ongoing process and needs to be continuous. In the same way as we now think of continuous threat assessment, continuous identity verification, we think about continuous third-party risk management.

And again, we'll never do this manually. Let's talk about RBAC. My friend and colleague, Mark, Martin, points out quite rightly that RBAC is a traditional approach and we're evolving beyond that. One of the reasons we're evolving beyond that is it's insufficient for the complexity of Microsoft 365. We're starting to see PBAC, Policy-Based Access Control, which uses dynamic policies based on content and risk. This is an improvement, but still has limitations. The next evolution, which we are starting to see, is Attribute-Based Access Control.

This gives us quite a fine grain using multiple attributes to make access decisions. And indeed, ABAC is getting closer to meeting the needs of modern enterprise security. And the final one is Code-Based Access Control, identity as code. Access decisions are programmable and automated. And once again, automation is our friend here.

So, I say, what's the path forward? And the key points I want you to take away are automated privilege management. I want you to start continuously scoping and enforcing least privilege access across the Microsoft 365 environment. I want you to be looking at configuration automation. And by this, I mean intelligent configuration management.

So, in the scales beyond human capacity and maintain security. And finally, I want you to be doing this concept of seamless user lifecycle management with third-party API integrations for enterprise-wide security. Why? Because traditional security approaches are no longer sufficient for the Microsoft 365 environment. And specialized solutions are required to address the unique challenges. We need purpose-built solutions to secure the ecosystem because traditional methods, as we are seeing, are leaving organizations exposed.

So, in a moment, I'm going to hand over to Rob, and he's going to talk about probably what CoreView do. But before I do, I'd like to leave you with some related research. And I've written a executive view of CoreView, which, if you are a Cup and Goal subscriber and a Cup and Goal member, you're welcome to click on the link below. We've also written white papers of From Perimeter to Persona and why identity security is now synonymous with data security.

We've written one of our leadership compasses on cloud security posture management by, again, my colleague, Mike, which is well worth a read, highly insightful. And finally, I'd like to leave you with the idea of B2B CIM in an era of agentic AI and non-human identities. Something which becomes more and more important. If you are coming to our Identity-Centric Impact Day, it's on November the 6th in Frankfurt. We'll have a chance to talk together in person live. We'll be running workshops, hands-on sessions, and networking.

We'll have speakers from GLS Group, Deutsche Bank, IKEA, Siemens, and many more. And it's well worth your time. It's a single day where we really, really get into these identity-centric cybersecurity topics. And finally, just to talk about cupping the coal, if you don't know, we analyze trends, markets, and solutions. Our researchers, which I am one, are constantly analyzing current topics, hacks, data breaches, digital transformation, AI, one of my interests, and of course, GDPR.

We make comparisons of software solutions and indeed provide product ratings to give you guidance in when you, as a CISO or a CAO, are making purchasing decisions. We publish research papers, blogs, videos, podcasts, and masterclasses on these topics, which, again, I look forward to seeing you at a future one. As I mentioned, we host a number of events and webinars online and on-site with expert talks, panels such as these, and of course, run network events with industry experts.

My colleagues in advisory are constantly supporting IT professionals in these decision-making processes and provide evaluation and maturity assessment of IT infrastructures. You've been very kind to listen. If you have any questions, I'll be looking forward to addressing those after Rob's presentation.

For now, I'll just say thank you. And I'm going to quickly take a look with you at the poll.

And so, let's see what we have on the poll. Fifty percent of you have said a lack of visibility into who has access to what is your biggest challenge. Thirty-eight percent report that it is difficult to segment access between departments and projects. And 13 percent say too many users have global admin or elevated rights.

And so, thank you very much for that. And the good news is that Rob and Sam have some very interesting concepts and news to share with you.

Rob, I'll let you take it away. Okay, well, thank you, Jonathan, for that really great introduction there and the deep dive into the world of Microsoft 365. I want to take what Jonathan said here and just give you five to 10 minutes of stories of what we're seeing in the field.

So, these are real stories and a bit of the way that we see the world as experts on Microsoft 365 and the unique security challenges that are coming with this platform. And I want to start off by asking you a question. I want you to imagine it's 2010 and I come to you and I say, look, I want you to take your Active Directory and I want you to put it in the cloud. You're probably going to think, that's a terrible idea. Then I'm going to tell you, I'm going to connect it to all of these other cloud services that you have no control over.

And I'm also going to give applications that you've never even heard of, I'm going to give them privileges inside of your Active Directory. You would say, you're crazy. There's no way we would ever sign off on this.

Next, I'm going to tell you, we're going to build a whole digital workplace on top of Active Directory with a whole bunch of application services and collaboration tools. So many of them that you can't even list them all without forgetting some of them. These tools enable you to send and receive email, to have external guest users in your environment who you have no idea who they are. They could be cyber attackers. They're just hanging out in your teams, in your chats.

You've got files being shared externally and data being shared possibly with no expiration date with people you don't even know who they are. And you can even create applications with extremely high levels of privilege that can be accessed from the outside without you even knowing about it. If I had come into your office and said, let's do this with your Active Directory, you would say, this guy is nuts. And not only is he nuts, I'm going to call his bosses and tell him to fire him because he's insane. This is what Microsoft 365 is.

If we just take away Active Directory and we put Entra in place, you've got a pretty compelling picture of what Microsoft 365 is doing. It takes two things that don't belong together and cooks them in one pot. Number one, your most sensitive business asset, your identity directory, your identity infrastructure, that's Entra. And then it takes collaboration environments which are exposed to the internet and to users you have no control over and blends them into one thing.

No security person should ever be put through a situation where these two things are brought together and yet we are all put in that situation by Microsoft 365. So there's never really been a risk like this. It's Active Directory on steroids in the cloud, exposed to all sorts of things that it shouldn't be exposed to. And attackers know this. They know this environment is uniquely sensitive. And so there are certain things that they're doing. I'm gonna name three of them which Jonathan touched on. I'm gonna give you a bit more data here.

Firstly, configuration tampering. Attackers know that if they get into your environment, they can tamper with your configurations and you won't be alerted. For those of you who don't know, Microsoft 365, the configurations that you set up in there, the way that you set your security posture, someone could be in there right now changing it and Microsoft will not alert you. I'm gonna say that again. Someone could go into your tenant and change critical security settings that would leave your business massively exposed. There is no alerting for this.

Attackers know this and this is why this kind of attack is surging. So all across different industry reports, we're seeing configuration drift, the number one cloud security threat in the first half of 2025.

176,000 instances of configuration tampering detected by Microsoft in one month. A 79% increase in configuration tampering in Defender across a two-year period. MITRE attack technique impaired offenses now listed as the top 1% attack technique being used by attackers. And Microsoft themselves highlighting that if you misconfigure Entra or Intune, the efficacy of different types of attacks skyrockets. Ransomware is 40% more effective, device compromise increases by 70%. It's never been more important to ensure that your configurations are set the way they should be.

And yet you have no way of having confidence that they are being changed or who's changed them. And cyber criminals are increasingly using this as an opportunity to compromise you. And the worst thing is, unless you have a mechanism to detect this, none of us are able to know or to have confidence about whether it's happening. There's also another challenge connected to this. Sometimes it's not just that you lose one configuration or someone tampers with a specific set of configurations. Sometimes the challenge is much bigger than that. So I want to talk about this at the tenant level.

There was an organization that we've been working with, we'll just say they're a Fortune 500 organization. They had their tenant compromised. And when this happened, they knew that people had been in their changing configuration. So I want you to ask yourself, put yourself in their shoes, how many configurations were changed? How would they know? What's the process you would go through?

Okay, you're a security leader in this business. You know someone's changed a few configurations, but how do you determine exactly how many have been changed? The only way to do this is to go through and audit every single configuration. By the way, we are speaking with global organizations right now who have to constantly re-audit their configurations every week, every two weeks, every month, to ensure that they're all in place. Another story, this is a very large government agency. Let's just leave it at that. I'm not going to tell you what country they're in or any more details.

They had their entire Microsoft tenants taken over because someone got privileged access, something we'll talk about in a moment. And when this happened, they were effectively held to ransom. So the cyber criminals said, look, we've got control of your tenants. We know how many years you've invested to build this tenant to be exactly the way it should be. We're only going to give you access to it if you pay us money. This government organization said they weren't going to do it and we ended up speaking with them.

The problem is, if you don't give the cyber criminals the money, you can no longer have a tenant. So here's a question that every organization should be able to answer. It's a great question for you to take back to your teams. How long would it take us to reconfigure and rebuild a tenant if we were locked out of ours? Because this does happen to people, cyber criminals do do this. In this case, they figured out it would take three and a half weeks of reconfiguration because there are so many configurations, tens of thousands, hundreds of thousands.

In one case, we spoke with an organization that had over 1 million unique configurations that they had painstakingly set. So you need a way to be able to reconfigure your tenant rapidly in a situation like this.

Finally, in one instance, we had a customer, a prospective customer call us at three in the morning. Okay, this is our CTO who answered the phone and they were in total panic. They just started to roll out CoreView and one of their team members had accidentally deleted critical distribution groups, which meant there was all sorts of problems in terms of their internal communications. It had just happened. And because they started rolling out our platform, they were actually able to immediately reverse the situation but they weren't sure exactly what was gonna happen.

Just one mistake could have led to disaster. Now there's a common theme here, which is it's not just that people might tamper with your configurations and that you need to know about it. It's how do I get my configurations back to an operational secure state when a disaster occurs? How do I make sure that my tenant, my Microsoft tenant, which is the beating heart of my organization, is actually gonna be functional following an incident? Are we going to be down for three and a half weeks or are we going to be immediately able to recover and have the tenant operational?

The best way to think about this, this whole idea of the tenant and keeping it operational is to think about the analogy of a glass of water. So I want you to imagine you've got a glass of water, probably not hard to imagine. I'm sure we've all had one at some point. If you hadn't, then, you know, so that's sad news. Speak to us afterwards, we'll get you one. The water in this case represents your data, okay? This is your files and this is your emails. These are all of the bits of data you have in your business. Now I'm assuming everybody here has their data backed up.

We did a survey, 98% of respondents said they had their data backed up. We've all been doing this for a long time. The trouble is, if I take your glass of water and I throw it on the ground, the water spills everywhere and the glass smashes. And now you say to me, well, it's okay, we've got our water backed up. The problem is you don't have a glass to pour it into. Your Microsoft environment, your Microsoft tenant is the glass. And the glass is only sturdy if your configurations are precisely configured. If your configurations have been changed, guess what?

The water starts to leak out of the glass. So if you redeploy your water back into your tenant and the tenant has been misconfigured, the cyber criminals immediately have access again and you're now facing the same disaster. You're also facing compliance and legal issues as well. The real question is, after an incident, how do you know what state your glass is in? Do you have a way to instantly know how many configurations have been tampered with and then to instantly restore your glass back to the state that it should be so that you can have confidence to pour the water back in?

This is absolutely critical. For those of you who take disaster recovery seriously, as we all do, it's mission critical. And I mean this because we speak with organizations that find out later. It is mission critical for your business continuity plans to have a process to rapidly reconfigure and re-engineer your tenants in a situation where you need your tenants, which is basically every situation. So please take this seriously and ask your questions internally about what your process is here.

As you can see here, just by doing a quick online search, you can see people are constantly facing disasters and it's not always about cyber criminals. Often it's internal mistakes that are being made by administrators that simply had too much power. They've accidentally deleted something critical, they've accidentally removed something they shouldn't have removed, and suddenly the business isn't working. And this connects us to the final point, which is that this is not just about configurations, this is all connected to a privilege problem.

And that privilege problem is that users often have far too much privilege. So Microsoft recently reported in one of their big reports that 63% of tenants they investigated are failing on lease privilege.

Thank you, Microsoft. Very helpful for you to let us know that. Why? Why is this happening? What I wanted to do is give you an analogy of a house. So here are a bunch of wonderful people living inside of a shared building. Each of them has their own apartment. Why? Why do they have their own apartment?

Well, I think the answer is pretty obvious. If all those people living in a shared building didn't have their own self-contained flat, living together would be awful.

Okay, you'd all have access to each other's stuff, theft would be a common problem, there'd be anxiety, there'd be a sense of lack of trust, and the actual value of the property would plummet as well. No one wants to live in a house where everyone's got access to everything and you're living with strangers. We all understand the concept of apartments. The thing is, when you have a Microsoft 365 tenant, there are no boundaries.

So if I give one of your administrators an Intune privileged account, and they are based in France, and they're only supposed to be managing the French IT team's devices or the user devices, the thing is that account gives you tenant-wide access. That administrator can now delete the device compliance policies of every single device across the entire tenant. That goes directly against the principle of least privilege. And do you want to know something shocking? Microsoft has no capability to reduce that privilege. It just gives you tenant-wide access.

There are no ways in a Microsoft tenant to create self-contained apartments where each user only gets access to what they need. This is a stunning failure of the identity security market. We are now 10, 15 years into a huge segment in cybersecurity called identity security. You all know this because we all work in this sector. The promise of identity security was that we would be able to implement least privilege. Guess what? Your most privileged environment has almost no controls to enforce least privilege.

If you give someone a privileged account in a Microsoft tenant, they get access tenant-wide in almost every scenario. The only thing customers can do is to deploy multiple tenants in an effort to maintain segmentation. But this creates enormous operational complexity and increases the risk of configuration drift and configuration issues, the ones we just discussed. So those are three key areas where we are seeing organizations facing huge compliance and security risks that Microsoft is leaving left over. And as Jonathan said, Microsoft are incredible.

But as they continue to build this platform, we have to fill in the gap that's left over from a security perspective. Now, to show you a little bit more about exactly how this works, I'm going to hand over to my wonderful colleague, Cyan, who's going to give us a quick demonstration of the CoreView platform. So one of the things we see as a organization, as CoreView as an organization, that we see across every single customer that has a Microsoft 365 environment is everyone has the same problem.

No one knows what's going on with their configurations, especially in regards to monitoring the changes. If you're only leveraging audit for that, kind of like what Rob mentioned earlier, audit doesn't cover everything. Some of the configuration changes don't get certified via any sort of audit operation. And this problem of configuration changes gets compounded, especially when we don't know if the change was intended, was it malicious, was it just a misconfiguration from someone that had too much access within the environment?

Well, within Configuration Manager, we're able to detect the changes occurring within the configuration set of your Microsoft 365 environment. So if a admin added a conditional access policy, they modified any retention policies, they deleted an Intune compliance profile, or if Microsoft made a change, if Microsoft added an attribute or changed an enumerated state value, we have awareness to that all within the Configuration Manager platform. And everything within the CoreVue family works in a multi-tenant perspective.

So you see I've managed two separate different tenants within this Configuration Manager platform. When I wanna know about whether there has been any configuration drift or changes that have occurred recently within the portal itself, I get a notification. Underneath of the Has Changes column, I can see an information icon notifying me that within the last sync process, this CoreVue PSA downstream tenant, there has been some sort of configuration drift that had occurred. If I needed to see it, I simply click onto the history, and now I know about the latest drift that had been detected.

So nothing got added, nothing got removed, but hey, something was modified within this conditional access policy. What was modified? I can see a grant auth string was removed, and I can see the state got changed from reporting to enabled. So not too bad there. It was just enabled, but someone had removed a authentication string. So I'm gonna wanna know about what that change was, or maybe possibly reverted. That's the latest drift that had occurred. I don't see any changes across CoreVue PSA here, but maybe something occurred in a different point in time. We also report and record that.

Nothing happened today or one changed the day before that, but what's interesting to me is, something happened on the 8th yesterday. Two things were removed, two things were changed. If I needed to see the detail of what had occurred, I can now see that within this tenant, looks like someone had removed this antivirus policy. Those are my initials that I had created.

Also, they removed a Windows 10 compliance profile that I had also created. And then within this ATP anti-phishing rule, this is more alarming. The state went from enabled over to disabled, along with some of the other properties against some of these conditional access profiles. So that's a lot of good drift detection. We've noticed and we've detected that something had occurred. You can get that notification and awareness within the CoreVue portal itself, within the has changes category. We never expect anyone to live within our platform every single day.

So you also get a email notification saying, some drift had occurred across all of the tenants underneath of management. Now that you've seen that drift occur, whether you saw it within the platform itself, or maybe you got a report just today that someone got locked out via conditional access policy, you need to revert back. Each of these sync processes where we read your configurations and we report on the drift that had occurred, they're also essentially configuration backups.

So if I needed to revert back a process, simple matter of picking the tenant, I do a comparison inside of configuration manager. I pick a time period to do a comparison against. And then once I hit apply, I get four data points of comparison. Those data points being only in CoreVue PSA master. This denotes that these are all objects, configurations that are new as of the time this backup was taken, September 24th. Everything's a staging process within reconcile, meaning I can uncheck or uncheck boxes to stage something like the removal of this intro conditional access group.

I know it's newly added. If it shouldn't be there, I can stage the removal simply by unchecking the box. Available from means, just like you saw within that drift, if someone had deleted something, maybe it's this compliance profile, maybe it's this configuration profile. If I need to restore something, I could always check the box to stage the restoration. Conflicting with means someone had modified an attribute within that configuration. So something like a conditional access policy.

We see this a lot where someone misconfigures a conditional access policy and the end result of that is everyone gets locked out or you have no access back to some object workload. Microsoft doesn't care. They allow you to hit save no matter what the intent was on that configuration state. When I hit view, I see a side-by-side comparison of what the configuration is currently, what the settings values are currently within that master state, as it gets compared to what those values were in that backup state.

If I wanted to revert back to that last non-good state back in September 24th, I can just use that to use all core VPSA button there to revert back to all the settings and values from that backup time period. We also allow you to be granular about what you wanna restore. So sometimes you wanna maintain certain attributes, you can maintain certain attributes. Everything is a staging process, meaning once I hit reconcile, we don't do anything immediately for a good reason.

When you see what can potentially occur, the process turns into a sync process where we back up the existing configurations again, and then there's a workflow approval process to actually perform those changes. So you get a chance to, once again, review what can occur. You approve it if things look good, and then you reject it if you just wanna not approve it or change some of the things that were staged, but that's configuration manager.

So initial benefit is gonna be drift detection, alerts and awareness on what has occurred, and then the capability to revert back those changes if you want to revert back. I'm gonna quickly go into core view to talk about least privilege real quick. Core view to compare against configuration manager reads and records data on your users, your groups, your licenses, devices, joined to Azure AD managed by Intune, your service principles, exchange online mailboxes, SharePoint online site collections, OneDrive team, so on and so forth.

Core view is a one-stop shop reporting management governance automation platform to manage everything within that tenant. And again, it works in a multi-tenant perspective. So if I needed to go to any other tenant, I could. And now core view is essentially just an independent management layer that sits on top of each of those individual tenants. So I can come into core view and see information about all 2,400 user objects within this tenant. So all their UPNs, all the license assignments, I can see other additional detail like mailbox storage units or OneDrive usage.

But I can see all of this without needing to have global admin rights or exchange admin rights or SharePoint admin rights to see or do anything within the core view platform. It sounds scary at first, but we secure everything through our delegated administration model, ensuring least privilege access, as well as zero trust. Those two key components are virtual tenants and our permission set.

So virtual tenants allows you to delegate out very specific access to just the objects that you want that admin inside of the platform to manage, whether it's any of the tenants, whether it's any specific groups, whether they're on-prem, hybrid, dirt-sanct, cloud-only, distribution groups, security groups, 365 groups. This virtual tenant happens to be using the company attribute where it equals the British Leasing Bank. So the admin with this virtual tenant associated is only going to see users that fit into this configuration criteria.

And we can expand that across devices, across SharePoint sites, across users or groups from on-prem organizational units as well. But the virtual tenant concept only limits object visibility to the object workloads from within your tenant to control what they can actually do inside of core view to maintain least privilege access.

Again, we have our permission sets. So if someone needed to, let's say, only have read-only access to any of the reports, cool, what do they need access to? Is it someone from security? Do they need access to know about users that have access to multiple mailboxes? Give them access to just those reporting workloads in a read-only fashion. If they need to do something, though, maybe it's Help Desk. And maybe Help Desk needs to reset passwords or add calendar permissions. Do not overprivilege their access to those native portals.

You're gonna give them access to modify mailbox retention policies maybe or any other global policy that affects all the object workloads if they only need to perform very unique actions or maybe it is a process of action. So maybe it's onboarding, maybe it's creating SharePoint sites or teams. We can containerize those unique operations and combine them all into a workflow process. So instead of performing a user creation process or a license management process, put it all into a workflow and we'll execute everything all seamlessly.

Let me show you what that looks like within the context of CoreView. I'm gonna go back into my report section here to go into my user report.

Again, my access level in CoreView is real similar to a global admin. We call them tenant admins. I have access to everything.

If, however, I had a virtual tenant restricting my access, instead of the 2,400 or so user objects, I now only have access to the 198 users where company attribute equals British Leasing Bank. If I further had a permission set restricting what I can see or do from within CoreView, instead of all of the operations, instead of all of the reports, I now only have access to just the handful of operations, the handful of reports as configured via that permission set.

Now, the beautiful part about how CoreView is architected is if that permission set also gave me access to audit and I had a virtual tenant restricting the objects that I can see from the tenant itself, everything flows through the scope of that virtual tenant. So now I'm only seeing rich unified event log history for only the objects that I'm responsible for. So just the users or groups or teams or SharePoint sites that fell within that virtual tenant configuration. I know I'm one minute over time. That's it for me. Thanks. Right.

Sian, thank you so much for a really, really interesting demo. Very fast-paced. I'm just trying to get my camera going. Sorry about that.

I really, I mean, there's, as I said, there's so much in this tool. It's quite incredible. And I see we've got quite a few questions from the audience.

So, Rob, if it's okay, I'm going to serve some of these up to you. Sure thing. Yeah. Okay.

So, yeah, and again, forgive me, folks. You'll have to make do with my photograph.

And, you know, bad news is I've actually lost weight since I took that. First one is what kind of authorization access rights does CoreView need to restore the configuration? And that's from Peter. I'm going to throw that over to Sian. He'll be more equipped to answer that.

So, the way Configuration Manager works is we're going to read those configurations leveraging graph calls. So, to read the configuration, it's just going to be a read operation. But then if we need it to write back, we're going to require that write access scope to restore that configuration.

So, just read-write, essentially. Okay, cool.

So, it sounds like quite a simple, again, quite a simple way for an administrator to enable CoreView. It doesn't require, you know, any advanced knowledge. Just enable read-write, and away you go, which is, I guess, good news for our audience. And the second question we have from Benjamin, how do you restore hard-deleted objects in EnterID? And Benjamin suggested, do you create new objects with new object IDs with the old configuration, or something else?

No, that's exactly it. So, if anything's hard-deleted, or if it's soft-deleted and we see it within the Recycle Bin, especially if it's a user, we're going to restore it from that soft-delete first. If it's hard-deleted, though, and there is no object within the Recycle Bin, just like any creation process within 365, new object gets created with a new object GUID.

And so, we're going to restore that object with the same names, attributes, if it's a group, optionally the membership as well, if you want, when we do that restoration. Okay, interesting.

And, I mean, I think, again, the plethora of options, but again, I think, yes, when something's gone, it means that there is a way of recovering it. Although, presumably, CoreView is making that process of recreating new objects with the old configuration. You streamline that, I imagine.

Yeah, you don't have to worry about what the attributes that you might not have noticed within 365 were. We store and maintain all of that within Configuration Manager.

So, it's a seamless process of just reverting back any deletions. All right, good.

And so, I've got another couple of questions here. How does CoreView create virtual tenants inside the Microsoft Tenant?

Ah, that's a good question. So, that virtual tenant concept is purely a concept within the CoreView platform.

So, anything within your Microsoft 365 tenant is going to be status quo. The users won't know about what's going on. It's a management layer that sits on top.

So, if, like, we see this a lot with M&As. If you are consolidating tenants and you're bringing over the old IT team, maybe the old IT team should only manage the old IT objects.

So, in my demo case, they're the users and groups from the British Leasing Bank. That virtual tenant concept is just an overlay on top of what they can see and do within the CoreView platform itself.

So, it's unique to CoreView. Interesting. And I guess the second question, I see my secondary camera's come up. It's giving you a bizarre view of me, but sorry about that, folks. How do we use SSPN for configurations? Is this doing more? I am confident to say that, yes, it does more.

So, SSPNs generally will look at specific workloads or objects. Now, I find it's going to be complementary, right? Because depending on the tool or platform or utility you're using, there's going to be some things that it does that Configuration Manager or CoreView just doesn't do.

So, but in that regard, the breadth and scale of configurations that CoreView reports and manages and backup and restores reaches across a lot of the different platform workloads. And I didn't get into it, but across your Defender and security and compliance platforms, no matter what Microsoft renames it to later, configurations under Entra.

And the unique way that we're doing drift detection ensures that if something doesn't get surfaced between audit, if something doesn't get surfaced with a typical API call of what those configurations are, we notice it and we detect it just because of the unique nature and how drift detection gets processed within CoreView. I would add to that, that the SSPN tools have a really, really hard job to do because their job is to look across hundreds of different SaaS applications and apply basic configuration security across all of them.

So, I want you to imagine you're the product manager of an SSPN company. You need to have the ability to integrate into these apps and to understand their interfaces and the way that they work and all that. It's a lot to do. And the consequence of this is, if you're using SSPN, it will provide some checks on Microsoft. They are very, very shallow.

So, like Jonathan mentioned, there's like 10,000 different configuration elements inside of a tenant and individual configurations can go up to hundreds of thousands in some cases. An SSPN tool is barely going to scratch the surface of monitoring those configurations. It might monitor for 50 of them. And on top of that, there's no customization because they just don't have the ability as a product team to build that kind of maturity into their management of so many different applications.

So, the key thing here is, if you're concerned about 365 specifically, we are seeing organizations all around the world have a dedicated approach to configuration management in 365 because it's the beating heart of your business. It's not Canva. It's not monday.com. It is categorically different.

So, it's really a case of prioritizing. If you rip it out, you've got a real problem. And we've got another question in from Benjamin, which I'd like to squeeze in if we can. And management, are management for Entra ID enterprise applications also foreseen in this virtual tenant?

Right now, virtual tenants do not segment across the owners of the service principals. But that's a problem I'm seeing across the board with every single organization is once a service principal gets granted, someone grants consent to an enterprise app or an app registration. What I'm barely seeing is anyone adding themselves in as owner.

So, right now, we're not segmenting or delineating virtual tenants based off of service principals or enterprise apps, just because we can't tie them back to specific users. But that's a good call. I might suggest that to product management later on.

Okay, well, let me see. We are nearly at time. I don't know if I can get in 60 seconds. Is it possible? How does this all compare to a PAM or privileged management solution? Depends on the use case, depends on the organization security policy.

So, if you have someone, or if all of your admins are required to undergo PAM escalation to perform things like modifying conditional access policies or anything like that, great. Keep that aligned. If your organization requires PAM escalations to have a admin go and manage a team, create a channel, create a SharePoint site on behalf of end users or manage SharePoint sharing settings for site collection, CoreView would say, let's eliminate that because they're gonna have way too much privilege to do a lot of other things than what you wanted them to have access to.

Okay, thank you so much. One of the great joys of this job is talking to two experts in the field. I hope we've all had a chance with both of you today.

Rob, Sam, thank you so much for your time. It's been a pleasure. And for all the rest of you, we look forward to seeing you on a future Cup and Goal webinar or indeed in person at ICID or in EIC next year. Thank you everybody for your time. Thanks a lot guys, cheers.