From vulnerability management to vulnerability operations

So, guys, thanks for joining us today. You've got myself, Dave from Devicey, and George also from inforcer on the call. Hope everyone's having a good day. Whether you're on the East Coast and we're halfway through your day, West Coast, you're maybe just starting your day, or like George and myself, we're based in the UK and it's 6 p.m. here. We're coming towards the back end of our day. So, where were you actually based, Dave? I don't think I checked that with you. Austin, Texas. Oh, sure. Okay. My geography of the US isn't great, but I'm going to say somewhere in the middle. So, you're not East Coast, not West Coast, kind of middleish. Getting enough of a nod. That's all right. Guys, we'll get started here, and if we have stragglers coming in, we'll add them as they come. But thanks. As I said, thank you very much for joining us.

Okay. It's a great webinar. inforcer have an awful lot going on at the minute. We've also got a new product launching next week. Lots of updates and changes coming. And in the midst of all of that, George Cochran, Mr. George Cochran, who I'll let introduce himself in a second, has gone above and beyond and developed our most requested feature since we've been a platform alongside Devicey and brought Intune app management to life for inforcer partners. We're also aware it's not only inforcer partners in this webinar. There may be some Devicey businesses as well, and thanks for joining. Hopefully this is a good insight for you. What we're going to have a little bit of a chat about today is this idea of vulnerability ops for the modern endpoint and this idea that the speed at which the world is moving, cybersecurity, AI, the speed at which exploits are being developed, being reactive, and slowly reactive at that, isn't really going to cut it anymore. We need to be developing how we're going about these things and updating our approach. That's largely what we're going to talk about, and it also plays really nicely into why Devicey and inforcer have come together to partner on this.

I'm going to hand over to Dave to introduce himself. Dave, if you want to jump in there. Absolutely. Dave Rafell, Chief Product Officer here at Devicey, responsible for R&D and product. Been here for almost three years. Prior to that I've worked in the RMM space, very familiar with the MSP's business models and pains and challenges, and been doing cyber for 25-plus years building SaaS products. So that's me. Well, great to have you with us, Dave, and look forward to speaking to you throughout this webinar. My name is Jack Cook. I'm a Director of Partner Programs here at inforcer. I look after a lot of our third-party relationships and hence why I've started working with some of the guys over at Devicey, whose app library is very much powering our Intune app management feature. I've worked in the MSP space for coming up on a decade now. I've been incredibly fortunate to spend a good chunk of that decade working with George across a couple different companies, Autotask, Datto and now inforcer. It's great to be here with you guys today and talk to you a little bit about what we have coming up and what we've just released. And I'll hand over to George. Hello everyone. I am George Cochran, Principal Product Manager for inforcer. I've been with inforcer for a couple of years now, which is actually more than half the lifetime of the company's existence, which is kind of crazy. And as Jack alluded to, I've also spent a decade in the MSP space, all the way from Autotask through to Datto and Kaseya. And the last position I had there was a Product Manager for Datto RMM. So shout out to any Datto RMM users in the chat. My day-to-day role is to take all the wonderful feature requests, gather feedback, speak to prospects and customers alike, and make sure that inforcer's roadmap is the most impactful features we can do, the things that really help your day-to-day and make Microsoft 365 manageable. Very happy to be here to show you a bit of the Intune app management that we've just recently released. Thank you.

I can see George being George has already been active in the chat and let people know that it's there and they can use it. Feel free to use the chat. And I can see we've already had, it looks like Tim, jumping into the Q&A feature. Please do use the Q&A feature as well, guys, and we can make sure that we address any questions we need to address. We will definitely have time for it towards the end. We want to keep this quite a sharp webinar today. For those inforcer partners who have joined us and aren't familiar with Devicey, we'll cover very quickly who Devicey are, and same on the flip side, we'll cover very quickly who inforcer are. We'll then have a little bit of why we've come together and what we think we can help MSPs achieve, and really what that benefit is for MSPs and ultimately the opportunity for MSPs around this. That is very much the appetizer to George's main course of the demo, where he'll run us through what the Intune app management looks like in inforcer. And again, massive shout out to George. This went live yesterday morning, so for any inforcer partners on the call, this is now in your platform. You can jump into and see this as well. Massive shout out to George and Dave, who worked incredibly closely on bringing this to life for inforcer partners. We'll cover that a little bit further on. Then we'll have a little bit of time for Q&A at the end.

I'll hand over to Dave to cover a little bit about Devicey for those who aren't familiar. Thanks, Jack. Devicey, I always like to tell the origin story a little bit. I think, similar to many companies in the space, we were born out of deep experience running Intune at scale, especially around the COVID time, moving to zero trust. Lots of folks on SCCM trying to figure out what on earth they should be doing to adopt this cloud-driven orchestration layer. And born out of that was a platform that drives, similar to inforcer, a lot of the Microsoft stack through the Graph API and other integrations that we have. We've been big on supporting every platform as a first-class citizen, whether that be Windows, Mac, iOS, Android. And we've made our name by helping a lot of different industries in the enterprise space with dealing with the complexity of the device fleet, configuration, compliance and applications, obviously being the focus of today's conversation. One of the things that I think we're coming together on in this conversation today is that there's also been a big shift in the landscape, which we'll talk about in a little bit. We're here to make Intune easy, a lot like inforcer do, focused around some different things. This is our little badges of honor. We've been working and partnering with Microsoft for a few years now. We have all of the requisite SOC 2, SOC 3, and we are Mac eligible, co-sell ready in the Microsoft ecosystem.

I'll cover who are inforcer for those on the call who aren't familiar. Very similar to the point Dave just made, we've been working with Microsoft for three, four years now, part of MISA, and we were a founding member of the Intune for MSPs program last year as well, which is a huge thing for us and a really clear sign that Microsoft is sitting up and taking notice of MSPs. Why that's important to inforcer is because we were born out of an MSP. We started to fundamentally solve problems around the Microsoft multi-tenant issue for MSPs. Microsoft is a great tool. It's a great solution and they've got some phenomenal, market-leading software and functions, but it's just never been maybe fully utilized by MSPs because it's not been particularly user-friendly. Particularly with the shift to the cloud that we're seeing and have been seeing now for the past five, seven years, MSPs have been so focused always on monitoring endpoints, monitoring servers. Both George and Dave have highlighted their past experience working in RMM vendors, and if that's not a clear indication of where the industry is moving, I don't know what is. These guys have spent a lot of time working on RMM tools, but with everyone shifting into the cloud now, the tenant is just as important as servers. Too many MSPs are operating a little bit blind on that. They don't have a clear tool to help them monitor, manage and ultimately strengthen a customer's M365 tenant. And that was a problem inforcer was designed to try and solve. Can we create operational efficiencies by just making that easier to do, particularly when you're going to be doing it at scale across 10, 20, 50, hundreds of customers, help MSPs reduce the risk to themselves and their customers in doing so and start plugging some of those gaps, and then give MSPs an opportunity to make some more revenue? Because just passing Microsoft licensing onto your customers where you make one, two, 3% on the licensing isn't great. There's additional revenue and margin to be made out there.

Will not dwell on this for too long, but be remiss not to mention it that inforcer, we've been very much focused on that tenant hardening side of things, that left of boom, that M365 tenant management. Can we strengthen it? Can we try and prevent attacks? But what was becoming evident is that, in a lot of cases, no matter how much time and effort you put into that, there's ultimately humans in the seat. People can make mistakes and particularly your customers can make mistakes, and there's a chance that threats could get through. And so actually that right of boom, Threat Detection and Response, was also equally important. What became really apparent was that there wasn't really a platform out there that was connecting the two together. And so we've been fortunate enough to be able to go and develop, and actually we're bringing to GA as of next week, a Threat Detection and Response solution. So now if anything does happen to get through the net, we can stop it in real time, give you forensic reporting of what's happened in that attack, how it's got through. What's also really cool is we can actually give you six months' worth of logs as soon as you turn it on to let you know if there's any active exploits or attacks going on, what's happened in that customer over the last six months, and then obviously automated response that points back to left of boom and saying, “Hey, look, this is where we think this got in.” Again, all coming back to this idea of trying to create operational efficiencies, reduce risk and give you additional revenue opportunities with what is ultimately now a bit of a unified platform across that.

I think two of those points, and really actually all three of those points, play really nicely into this question of why have Devicey and inforcer come together to do this. We'll touch on it in a second, but this idea that I've already mentioned, the industry and speed at which this stuff is moving now is unlike anything we've ever seen. The speed at which threats, vulnerabilities, risks can all be identified is massive. And so for an MSP to now try to stay on top of that stuff is becoming increasingly difficult. So we looked at how can we help MSPs do that. And again, it's not brand-new information. As mentioned, it's been one of our top requested features for a while, Intune app management. MSPs are aware of that and looking for ways in which we can get on top of that quicker and resolve that quicker, and that's really where the Intune and Devicey partnership came together. George built an amazing bit of software into our platform to help you do it, and then Devicey brought that app management library to make sure that we can actually do this at scale and with speed, so that we are giving you the operational efficiencies, helping you reduce risk for your customers and ultimately giving you another way to prove your value and potentially add additional revenue options.

Absolutely. Thanks, Jack. It's accelerating even on top of the already insane speed. I actually just saw something yesterday where there are small, not even frontier models, being attached with the right harnesses, discovering similar volumes of provable exploits against software out there. So if we thought it's happening fast, with last Patch Tuesday I think was the largest on record by a factor of three or five or something along those lines, we are dealing with a volume and a rate-of-volume issue that's unprecedented. There's always the joke about better to be lucky than good. And in some ways there's a little bit of that happening here because we've been investing in kind of the next generation of application management, which is really all about the curation, testing, hardening of applications. And that was something we were just doing to say we want to plant a flag and be the best we can be for applications in the space. But then this movement started months and months ago with ChatGPT cyber methods. At first I'll admit I got a little bit tired of hearing about it, and then we started seeing all the volume increasing across the board of the amount of things that need to be patched, fixed, updated, and then the time and window with which you have to update that is shrinking faster than we can even think. That's part of where this next-generation application bit comes in, is everything from the left-hand side of knowing that there's an update available to ensuring that it's tested, hardened and ready to be deployed is what we built around. And so that's where we're at, as this ability to react, respond at, people are using the phrase machine speed. It really is changing.

I'll leave that with one more thing, which is this all still needs to be coordinated with good change management, coordination between ticketing and everything else. And we need human in the loop by exception. So we look at the continuum of vulnerability operations. A lot of it's led by that vulnerability and applications, but then your reaction and operationalizing of what you do with that also includes other surfaces like Conditional Access and how you want to shift configuration accordingly, various just-in-time policy tweaks. And so we see that as the continuum, and we refer to that as the containment aspect of it. How does your topology react to these things that are happening? Yes, updates are part of it, but a huge other part of it is ensuring that you've got control over the blast radius and affected surfaces. And I should mention that vulnerability operations, if you haven't seen the tagline yet, I think you're going to see it a lot. It's the same thing that happened with DevOps and IT ops and all of the shift left and move things this way. And it's all about doing things faster with better precision. Today we're dealing with things like the lag with which you can actually deploy and roll out patches. A lot of that's influenced by systems that have set up automation and it's hard to bypass that automation. And so we're considering that dimension as we think about these features and how we create the ability for whether it's the enterprise or the MSP to react to that in a way that's still systematic, still scalable. Not to mention, Jack, you talked about the business opportunity. I think there's also the business risk where more and more your job as an MSP to ensure that people are protected becomes table stakes, and so we think that adopting that vulnerability operations mindset, looking across the landscape, is critical.

I actually think you made an incredibly valid point there, and that risk and almost what's expected of an MSP these days is no small thing. I guess what's been expected of an MSP has had blurry lines and it's been probably growing and growing over, I guess, as long as MSPs have been around, officially 15, 20-odd years. But to Dave's point, this idea of being the reactive element of this is ultimately what a lot of MSPs are doing. They're being reactive. But is there a shift now or the option for you to, again, differentiate yourself or bring new services to market around that proactive vulnerability operations versus just management? I imagine for every MSP on this call, if I was to jump onto your website, I would almost bet my house on it that every single website will have the term proactive on there somewhere. And it's this idea of, are we actually being truly proactive, or are we just being quickly reactive to things that are happening and things that are going wrong? Again, I think this is a really great way, in a day and age when competition is becoming as much as it is and as great as it is for MSPs, to look to differentiate themselves from some of their competition out there.

And again, while we're talking about this in the realms of vulnerability ops and the Intune app management side of things, it's also worth knowing that goes across the board. I think it also is a big part of why inforcer exists, because a lot of MSPs were being quite reactive to their customers' Microsoft environments, whether it be patches or updates that were coming out from Microsoft or just the drift side of things or trying to keep those environments up to date. It was more, as and when we see a big issue, that's when we react, versus can we be truly proactive and stay on top of that? And I think there's a huge opportunity out there for MSPs to start getting on top of that. And again, as mentioned, don't make a huge amount of money off Microsoft licensing. So any of the services that you can start to wrap around those are additional value, additional revenue, additional MRR to use as an MSP. And I think those are big steps forward in the right direction. I think if we look at what that ops loop might look like, this gives you a really nice example of what that could look like for you guys and how you could potentially take this to your customers. And again, if you're going to present this as a differentiator for yourself or a real value driver, what are those six steps looking like in terms of being able to discover what's there, but what's at risk potentially to begin with? Be able to prioritize it, configure it, remediate it, verify it, and then ultimately explain it in an easy way to your customers that's going to make it easy for them to understand, but also easy for you to show your value. Again, I think if I was an MSP on this call, I'd be looking at maybe screenshotting this slide and looking at ways in which you can start building around this, either building this into talk tracks with your customers or adding this into services, QBRs, things that you're delivering to your customers. It's a great way for you to show your differentiated value from the rest of the market. I think that's going to become increasingly important in this day and age. It's just getting tougher and tougher out there with competition. Being able to show why you're a step ahead and why you're that trusted adviser to your customers is becoming more and more important.

I'll hand back over to you, Dave, to maybe cover a little bit more of this, where Microsoft sit and where Devicey sits within Microsoft and Intune in particular. Absolutely. Kind of beyond Intune, we also look at what is a device, and we've extended that to include the browser. And so we integrate with the Edge for Business platform and are working with them on the roadmap for features that actually are things MSPs want, certain APIs to be able to push Edge cloud policies, etc. And then, of course, integrating into Security Copilot, we provide a marketplace extension there as well to complete the loop in the Microsoft story.

And ultimately what this is about, I like how you framed it, Jack, with the tenant and servers analogy. That's actually pretty strong. It all started out as everything moving to the cloud or whatever, but really it's about understanding the pieces that back everything that we do and having a control plane to be able to deliver on something like vulnerability operations. Having consistent outcomes, and as we all know, security that breaks everything doesn't work either. And so a big part of unifying everything and bringing applications as a vault is to be able to have that complete 360 around all the things that are going to impact folks, both from the security side but also ensuring they stay productive, keeps your end users happy because, as we know, just about any change that disrupts people's day is generally not welcome. I think that this is a pretty exciting time to be Microsoft native with these toolings. And I'll close off with, I hinted at this earlier, but there's something that you all are probably pretty familiar with, with the drift remediation and understanding how to manage things against your standards, but it's also a vulnerability surface. And as we think about things that are coming in from an exposure posture perspective, we have to consider all aspects of what we need to do to ensure that we're preventing, remediating, controlling, containing. And with connecting all of these together, it really becomes a way to express security intention across the board. And so it's another area of vulnerabilities that doesn't get talked about enough, and it really extends to any aspect of the system.

We'll pass on to the main course that is George's demo. One point I will note, this is our second one of these webinars today, so maybe we're a little bit more polished by this one than we did the first one. We had a ton of questions when we were on with the EMEA audience earlier today. So obviously Tim's asked a question. I think George has jumped in the chat and answered, and maybe more questions will pop up as George runs through the demo. But do not be afraid to drop any questions or thoughts or feedback in the Q&A or the chat. We welcome it and we're keen to make sure that you guys get as much value out of this as possible. Absolutely. I hope you touched wood when you said that we're more polished in the second session because that's bound to make something go slightly all right, but we'll see. Hi everyone. Thank you again for joining us. I'm going to run through what we have built. And when I say we, I mean the royal we, a very big number of very talented engineers on both the inforcer side and on the Devicey side. And you built this all by yourself. Not quite, thankfully. You really don't want this to be my code. I promise you.

So we are here to solve the Microsoft 365 challenge for MSPs. And there's a reason that Intune app management made its way to the very top of our request list. Anyone that's had to package an Intune Win file for the 10th time because there was a 10th upgrade, and then go through every single tenant to upload the Intune Win file, to fill out every bit of metadata, click save, and then realize you forgot to assign it and have to work out the assignments, this is a slow, painful process. But there is some real reward by doing it right, which is you get those Microsoft magic features. You get things like Autopilot that allows an out-of-box device to pre-install the required software. You get things like the Company Portal where your customers don't need to be admins on their machines, and they can go through and self-serve the software they need without yet another support ticket, yet another remote-control connection just to click yes on a UAC prompt or something. So it's a great result, but it's hard work to get there doing it the old-fashioned way.

And really that's where we started with inforcer app management. This page here is the first place you should go. When you first look at this page, it's going to be empty because this is your procured catalog of apps that you're managing across tenants. There are two ways to add apps to it. Either use the catalog of prepackaged apps powered by Devicey. I'm going to jump straight in and just start with a very simple end-to-end example. Let's go Visual Studio. I haven't subscribed to that yet. And let's go and take that app that I've just subscribed to, deploy out to one, two, three tenants, set them to auto-update. There are times when you want to fix a version because the customers only paid for this license tier or something, but most of the time we're really after auto-updates to keep on top of those vulnerabilities. And then the choice of assigning to all users available would be a great way to put it in Company Portal, but then there might be a selection of users that are required to have this app. I've got a development group here. I expect developers like VS Code, or maybe not. Maybe they're all just working out of Claude these days and don't even look at the code that's being generated. Let's hope not. So, with that deploy, watch it in progress, see that app rapidly pushed out to tenants. And as I come back to the catalog page and find the app one more time, I can immediately see which tenants have this app, what version they're up to, and if I need to click through into the specific tenant to see all of the app versions that they have. So, believe it or not, that is the basic job done for a vast number of apps, right? And that is why it's been so valuable for us to partner with Devicey.

I'm going to jump back to the central catalog here and just do a little bit more of a behind-the-scenes, under the hood of this catalog. So you'll see that already in two days we're up to 1,353 apps. From a technical perspective, we are mirroring the Devicey app catalog into our own storage and deploying it out from the inforcer Azure platform, which does mean that you don't need to have another enterprise app deployed to tenants. You don't need to allow-list more IP addresses, etc. We are very good at reading and writing data to Microsoft. That's where we specialize. But we have this mindset internally that we focus on what we're best at, and we partner or use third-party tools sometimes for the skill sets that we know we're never going to be the very best at. And talking of being the very best at, the Devicey team have been awesome to work with. I sound like a bit of a fanboy here because I guess I kind of am, but the nerdy audience members here may know of something called PSADT, PowerShell Application Deployment Toolkit. Now, there's a reason that Dave chipped in and quickly corrected me. Dave, what's the Devicey link to PSADT? Well, there we have a couple, actually. So for the last year plus, if you look at the top contributor in GitHub for PSADT, that is Mitch. He is the lead engineer, open source lead for PSADT. And then also on our team, we've got Dan Cunningham, who started the project. So we've got a pretty strong pedigree.

And I'll just chime in on, and we did this because a couple years ago, when we were looking to how to really level up the applications game, a lot of it came down to looking at, just like you said, you don't do the things that you're not best at. So which shoulders of giants do we stand on? And PSADT is a core part of what the delivery manager, which is part of the magic that's bundled in every one of these applications, is built on PSADT. And it's the piece that allows us to do things like deal with the clunky existing installations from different types of installers. What kind of magic and intuition can we bake into that system by introspection, just in time? How do you control the UI experience with a silent installer? Do you let the user know something's happening? So it was a really key part of getting that end-user experience right. So thanks, George. That's awesome. And a very simple example, actually, the one I just did. I think VS Code is a little notorious to those that have needed to update it in the past, that if you force an install of VS Code on a user's device when they are writing code, it could force-close their app and lose all of the progress of whatever valuable code they were writing just to perform the update. So again, that wrapper layer on Intune app packages that does all this amazing logging and better end-user experience is just some proof that this Devicey lot know what they're doing, basically.

I also want to shout out that the Devicey team have built an incredible pipeline that is fueling this catalog. So there is a bit of a split between the known trusted download locations and those that need a little bit more attention and manual input. But essentially, new versions of apps, like in my testing I've seen multiple Claude updates happen in a day, and all of them being brought into the catalog by Devicey. Those install binaries get vulnerability-scanned. They get packaged up automatically and deployed to VMs that will then verify that they install and uninstall correctly and silently and the rest. So this is, again, we're standing on the shoulders of these giants, of the folks that really know what they're doing and can deliver this much value in the first day or two of release. So this list will grow in size. But if we're realistic, I think any app that I could come up with off the top of my head will be in here already. So do feedback the apps that you really need. The one area that we tend not to have in the default catalog are the apps that are behind a paywall or a subscription wall. And for some RMMs, like my previous employer Datto RMM, there is no generic version of that RMM agent. You do need to download your own one from your own portal, else you'll risk deploying an agent to the wrong RMM or the wrong end customer.

Now, with that in mind, I'm going to show a little bit of the custom app catalog. So this should handle all of those more bespoke edge cases, like the RMM agent that can't be standardized or maybe a backup agent or line-of-business software for a customer. And as I shortcut to my demo folder and drop in an example here, at this first release, we do need an Intune Win file to be uploaded. There is a really comprehensive guide on how to package an Intune Win file in our documentation. So just search that out: how to package a custom app for Intune. And because I actually packaged up an MSI file, we get to leapfrog through so much of the steps here. MSIs are so standardized that the metadata gets captured into the Intune Win file and things like the name and the publisher and the version are already there. I do need to grab the logo, otherwise my OCD will kill me. We set a lot of sensible defaults for things like the architecture and the minimum OS version. But we still leave things open to override if you do need to. And again, the default MSI installer is there ready to go. Now, here is where, if it is something like an RMM or a backup agent, we built in, even in version one, a bit of a power tool for MSP users, which is some installers will give you the option to put in an argument like the RMM key or something like that. And you'll see this insert variable button. This is where you can create new variables, or maybe you've already set this value for customers in a previous installer. We can inject in, if you like, the right license key, token, custom ID, whatever it is, just by filling that out in the custom install strings over here. So make great use of this custom app manager. We also have things like custom detection scripts for superpower users. And with that, I'm now going to have my own custom app available, uploaded once into inforcer, deployed out to 10, 100, a thousand tenants in a super-scalable way.

Okay, so with that, I am going to be too lazy to wait for this to finish processing, I'm afraid. So I'm going to jump over to a small nuance around group templates. If you wanted to deploy out an app to every customer, there is a good chance that actually targeting all users or all devices would do the job. But when you get to this assignment stage, you might think, I don't really want to see, I don't know, 100 tenants' worth of groups showing up in here. That's going to be an absolute nightmare to try and work out which is the right group. Do I have to select the right group for every tenant separately? Bit of a mess. So we came up with a simple alternative to that, which is this idea of group templates. And you simply put in the name of a group that you'd like to have available. And in this case, you see I've just made a few for different departments. This group will be created on each tenant if it doesn't already exist, or if it does exist, we will obviously link to the existing group. And it just means that you can now standardize out how you're targeting groups for apps. The traditional Microsoft best practice is each security group should be for a specific purpose. So now you've got a way to make sure that the next engineer that jumps into that tenant and finds this security group, they'll recognize that it's there to do Intune app management. And, of course, in inforcer, we do already have the ability to jump to a tenant and edit group membership. So you can go and assign the right users or groups to that group as well.

So that's what the group templates is all about. I will now maybe jump to a specific tenant. You see me using Control K a lot because it was actually one of my hackathon projects that I am still obsessed with. Jumping around in inforcer, getting right to where I need to go, and that has taken me to the app list of Round Robins, one of my tenants here. So let's first of all just highlight that when you are looking at a single tenant or deploying to a single tenant, you do still have the option to see all of the groups for assignment. So plenty of freedom there. You also have the ability to view this app in Intune. So we made sure that this link supports, oh, sorry, I've just flash-bombed everyone. We went from dark mode to light mode far too quickly. So if you've got your GDAP set up effectively and you have suitable permission to jump into this tenant, you can, of course, use a Partner Center GDAP relationship to jump straight to that app for the right tenant. So we're not going to be in the business of recreating every possible toggle in the Microsoft UI on the inforcer side, but at least we give you a really fast way to jump across into that tenant to do any overrides you need. And I think at its heart that is the core toolkit, and now naturally there's a lot of great ideas of things that we can expand upon and things we want to add in the not-too-distant future.

I'm only on a single laptop screen, so I'm just going to check out any questions in the chat. How is discovery done? Now, that's a great question. We are not doing app discovery at a device level. We are showing apps at the tenant level of what Win32 apps have already been deployed to a tenant. So I'll just give you a quick view of what I mean by that. So here again we are at a single-tenant level, and we can see that there are some apps that were deployed manually to Intune. Someone stuck in the dark ages still uploading Intune Wins by hand. And so, if we need to, maybe we could remove this 7-Zip, remove that one, and instead go over to the app catalog, find my managed version of 7-Zip, deploy that out to Round Robins, and off we go. So there are definitely some little tweaks that we could do to making adopting apps a little bit easier. That's actually the last thing I was researching before this call kicked off, because there's so many complexities, whether the app was deployed in a user context or system context, whether it was this type of app or that type. But don't worry about the complexities. That's for us to stress about. We just want to deliver an easy-to-use app management toolkit at the end of the day. I should also be super clear about the Devicey-powered catalog here. This is an add-on cost to inforcer. It should be extremely affordable. We are really not here to be nickel-and-diming, or we're not trying to make our millions through giving access to this app catalog. We just want to cover our license cost with Devicey, and we want to make sure we're not losing too much from the ingress and storage costs from Azure. It does actually cost a fair bit to deploy, say, 10 GB worth of apps from one Azure region to a different Azure region. So we do have a small add-on cost, but it is just a one-monthly cost for you as an inforcer client. And you can use Intune app management with that catalog across as many devices, as many tenants as you like. You should also be able to go to the licenses page and self-serve that license. So I already have it, of course, but click the add license button here. The pricing is in that drawer. So you hopefully agree with me that it's going to be a very affordable add-on.

Let's see if any more questions have come in. A couple I can read them out to you, George. We got a top one here from Ryan. For apps using the red carpet PSADT experience, can PSADT be customized? Branding, deferrals, restart behavior, different tools, white labeling, PSADT have different levels of capabilities here. Sure. So at the moment, no. It is something we want to explore, but at the moment it is, I think, just very neutral branding and very default stock options. So that would be a cool one to do, but we need to plan that one out a little bit before I can commit to how much customization we can offer on it.

Tim's asked a lot of questions, so thank you very much, Tim. Great involvement. Does inforcer currently support Intune Windows patching policies, such as the Autopatch rings and other similar features? If so, are there reporting elements that can help track patching alignment to the baseline from within inforcer? Actually right now we do support Windows patching policies, and there is a little guide somewhere, I believe, about how to get the most out of things like Hotpatch, which is that ability to update devices without restart, which is not technically an Intune exclusive but, again, one of those that is best done with Intune. So that's a yes, but we can definitely do more on the device-level reporting. We are about to kick off a bit of a reporting overhaul inside inforcer. So watch this space is probably the safe answer for now. But we do expect to have an ability to really break down who's up to which versions and feature versions, as well as quality update versions and things.

Next one from Tim, definitely one we saw earlier in the questions as well. How are the apps in the inforcer catalog tested ahead of being added to the catalog? Is there any documentation on the testing validation process which each app and new version goes through prior to being added or updated in the catalog? Absolutely. So here is where I am just currently waiting on a nice talk from the team that did the hard work on the Devicey side so that we can put that in our documentation too. I think I broadly described it earlier in that it's automation on checking if new versions are available, obviously relative to that particular app source. Then vulnerability scans on the executables that are downloaded, packaging up and automated install and uninstall testing. So yes, there is a whole beautiful pipeline of automated testing. I don't know, Dave, if you can speak any more to your colleagues' work on that one. I think you captured it pretty well. And documentation-wise, I think we've given you something, and you'll be able to pass that along. Kind of in the simplest way, though, every app gets the same treatment initially, which is as described, where we're checking provenance, signatures, there's a bunch of heuristics on where upstreams come from, etc. And then during the testing phase, we actually deploy to, we spin up Windows machines, run it, do a series of validation and extractions to verify that things are consistent version to version. And so that's part of how we'll detect when versions might have significant behavioral changes. For more complicated applications, we add layers into that that do additional checks during that deployment of the app to ensure that all of the things that we expect to be done are done, followed by all of the security validation and everything else. And we do have an audit log of that, by the way, George. So it's something we were talking about this morning. I think we can throw that in there and make that available.

Awesome stuff. Another question here. When you upload a custom Intune Win, does it get the PSADT wrapping today? No. If you upload an Intune Win file, it is just treated like a regular Intune Win as if you had done it directly in Intune. However, we are still exploring the possibility of using a packaging service directly in inforcer such that you'd be able to just upload an executable, or preferably still an MSI, and allow that to get the full wrapped PSADT experience. So I don't want to commit too much on that one because obviously that's a big piece of work, but that is definitely the intention.

Couple more questions. I'm just trying to keep in mind the time as well. Seven minutes. All right. Plenty of time. Nice. Do app install command variables use the same variables existing in inforcer per tenant? It is a separate collection of variables. We definitely do have a job to do to simplify down how you manage variables in inforcer. So we already have the variables that you can use to tweak a policy before deployment. We have the variables that are available as you alert out of inforcer. And now we have variables for inputting into app catalog apps. We can bring those into one place for sure. They still are going to have a little bit of different behavior. So it'll probably be different types of variable in a single screen as we simplify that down.

Can a unique group be used per tenant if our groupings don't lend themselves to templatization? Great word. Yes, but you will need to deploy that app one tenant at a time to be able to select the right groups for that tenant.

Can you speak more to auto-updates? There is often a shell game of adding new packages, removing assignments from prior packages, sometimes using supersedence, lots of ways to skin that. This person knows their stuff. We are fortunate to be building our products after the advent of the supersede feature in Intune. So we are deploying the new version, leaving the old Intune version in place. So in Intune you will see two line items. In the inforcer UI, we actually roll that up into a single item with a dropdown. The old version's assignments will get copied over to the new version. Even if you'd manually tweaked those assignments and edited them in Intune or something, however they were just before the upgrade happened will copy over. Then the old version will be set to a supersede relationship to the new version, and I believe the old assignments are cleared out of the old version. So, all in all, that should allow devices, when they check in, to see, ah, here's my upgrade path. I'm now pointing at the new app version, even if they've been offline for a while.

We actually have done a lot of edge-case documentation. So if ever you've got these nuances that you're just not quite sure on, please do go into our support chat here and ask them because our AI agent Finn will be trained on everything in our docs. So, how many old versions of an Intune app are kept? When do they get auto-removed? And if my brain dump and my exploration with the engineers was comprehensive enough, pretty much every question you might have is answered here. But if there is a question that doesn't have an answer, we're constantly monitoring the log that is kept by the AI agent of questions that it didn't have enough data to answer. So we can just go and backfill those answers. We'll reach out to you and tell you what the answer was, but also it will be that much better for the next person. So there we go. That's a pretty comprehensive answer of at least three versions, maximum 10 versions. Here's when the retirement process happens or when a new version is published. So, super-comprehensive docs there, and I think that should answer a lot of those questions.

You got a last two questions, I think, George, maybe before we finish up here. This one might be more for Dave as well. The Devicey catalog that is publicly available shows a little less than 500 apps as of May. You showed 1,300 currently. Where can we view the up-to-date catalog and roadmap for new apps? Great question. I'll do a follow-up on this one because that should be up to date and syncing off the catalog. So that might be a pruning. We're migrating our documentation system as we speak to a different platform. So we'll send out an update. I think it's worth, we had a chat with Alex earlier, the Devicey CEO, and I think he mentioned you guys were adding about 200 apps a month on good months as well. So that number is trending up pretty regularly as well. Yep. And just a quick point, even if you haven't bought the catalog add-on, you can still open that side drawer and check out the apps that are available. So feel free to open that up, have a search, double-check that your top 10 apps that you might want to deploy are in there. So you can use inforcer as a view of the latest and greatest as well. That's a great call out, George. Great call out.

And then the final question, will this remain Windows apps only or will mobile apps be added? That's a punchy question. So, today, yes, we're Windows only at the moment. There are rumblings of a macOS catalog being worked on by the Devicey team. Shifty eyebrows from Dave. So we'd definitely love to expand to macOS. And from there, yes, it does make a lot of sense to also cover off iOS and Android. By far and away the most feedback has been Windows is the biggest heartache and is the right place to start. But keep upvoting mobile app device management if that's a core use case for you.

And with that, I think we've hit time. We've hit time and you've hit all the questions as well, George. Guys, thank you very much for joining us today. George, Dave, thank you very much for delivering some phenomenal content and just being the absolute superstars that you guys are, getting this built together and put together and out there for our partners. That work, a lot of it happens behind the scenes, but we can't do what inforcer does without the work you guys put in. So thank you very much. Thank you. Thanks so much. Thanks everyone for joining too. We'll call it there. If anybody has any questions, feel free to reach out. And just a reminder, this is now live in platform, so feel free to go play about. Thank you, guys.