Juniper Access Assurance (NAC) – Client Onboarding, Always-On Posture, Built-in Profiling

Hi everyone. My name is Slava, and we will not talk about wireless. We'll talk about access assurance or Cloud N.

So, uh, as we are expanding, uh, our footprint, and we are, you know, we are growing, uh, exponentially, we're growing dramatically, we are adding more and more functionalities that would cover, uh, some of the use cases that come from, from our customers. And today we'll talk about three things. And the first thing we will talk about is client onboarding.

This is something we've actually announced on the previous, uh, MFD last year. And, uh, I just wanted to go deeper into it as we are, uh, closing, uh, on, on this and as we are releasing, uh, uh, the functionality. So, client onboarding for us is really about how do you, uh, uh, move a client that's, that's unmanaged to an enterprise network on WPA three or WPA two Enterprise.

How do you push a search? How do you install a wifi profile or wire profile easily, uh, and seamlessly as possible. Now, before we go into, you know, a demo and a and a deep discussion, you know, you've heard the Marvels client, uh, mention couple of times today, and you will hear about it, uh, more and more.

I wanted to kind of, uh, give a brief overview of different Marvis client personas, right? So this is where, uh, one of the persona that we will cover right now is the NA onboarding tool. So, Marvis client could just have different faces.

One of, uh, one of its faces is actually the onboarding one where it'll provision the, uh, end user device with a certificate, with a wifi wire profile connected to the network. And then optionally, on top of that, you can then enable to send telemetry. So you can actually get client level visibility of the network, uh, streaming to the Miss Cloud, and then providing the admin of the missed dashboard of, you know, uh, deeper visibility in, into how the client sees the network.

And then, you know, the other, other use cases we've seen in, uh, in warehouses specifically, is the lo, uh, locationing aspect. That's, uh, that's enabled on the Marvis client just to, to track the, uh, uh, the handheld scanners, uh, in, in those areas. But right now we are focusing on the knock onboarding, and we'll actually start with the demo and the demo.

Uh, we will start, uh, by looking at the, uh, at the admin side of things. So we will, uh, look at how and would actually, you know, start, uh, and create the onboarding process for the end users. And many of you are familiar with our PSK portal concept, where, you know, now, uh, an end user, say a student can, uh, come to the, uh, portal, authenticate through the SSO, grab their personal appreciate key, connect their devices, so that, that process existed for, for a long time.

Now we are, uh, expanding that concept, uh, into a NAC onboarding portal where the similar workflow will work, uh, for, and then, uh, for end user and do the SSO login. And then, uh, they'll be able to provision their device with a, uh, you know, with a certificate and, uh, wifi wire profile. Now, we'll look at the portal config here.

So first, we'll, we'll create a portal. That portal has all the customization options that allow you to, uh, kind of get your own branding colors and backgrounds. The most important thing is that portal will be attached to your single sign on using saml.

So any, uh, identity provider that you work with, whether it's enter id, Okta, or you know, Google, or literally anything in the world, we will work with this once the SSO process is complete. The important part is the onboarding parameters. This is where you define if a user goes through this portal and they're successfully authenticated and authorized, what do we do with the onboarding process?

How do we treat them? So, a, you're gonna specify, uh, which SSAE will eventually connect to. So that can be a portal for your, say, users on, uh, in a higher ed, or that could be, uh, a portal for, you know, a personal employee network in an enterprise.

Y you, you can then say, do you want to also enable wired connection with that one x and certificate authentication? Do you want to send Marcus telemetry back to the S cloud? This way you can actually get that client level visibility.

So that's the optional part that you can, uh, enable as part of that onboarding process. Plus, you know, few, few other things where you could actually say for how long the Google issue will be valid for the end user, the roles, et cetera. So now, uh, this is the admin side, right?

So what's happening on the end user side, uh, is, lemme go to the next slide on the, on the end user side. So first we're gonna look at the mobile device. This is Android, but you know, it, the process is similar for, uh, for iOS as well.

What, what I did here was I just encoded the NAC portal, ERL as a QR code. So, you know, you could just scan it with a camera. It will then redirect you to the onboarding portal.

That onboarding portal will actually redirect you to your SSO provider. In this case, this is ID again, can be anything else. You log in, uh, if you have M-F-A-M-F-A will be completed at this step.

Once you've logged in, you will be redirected back to our onboarding portal. It will say, oh, hey, you're running Android. If you don't have an app, go click here and install.

If you do, click on the link and let me, okay, click on the link. The app will pop up. It will ask you to install the network profile.

Wait, wait, wait. It'll give you one more prompt. You'll hit save at this point, you're connected, you're good to go.

Now, uh, what's important here is, uh, this part, right where based on your SSO login, we will grab your identity. We will, uh, issue a certificate for that, uh, end user device using the identity from the SSL, right? So we can embed, uh, all of that information in the search, and then the client will go through our general, you know, access assurance authentication process.

You can set up your policies, look at, you know, extra checks, like group memberships, things like that. But this is the end user, uh, facing onboarding process, okay? That's mobile device.

Now, the next part is what's gonna happen on, on a, on a desktop, whether it's, you know, windows or, or Mac os. Again, very similar. We will, uh, look at the, uh, SSO login first.

Once you've logged in, it'll detect that you're running, uh, windows. It will ask you to open the app if you already have it. It will then go through the enrollment process.

And as you can see in the bottom or right corner of the screen, the client is already trying to authenticate to that, uh, to that network as it's installing the wifi profile. And it's now on, uh, on that destin, uh, destination associated at this point, right? So that, uh, onboarding process is, you know, you know, very, uh, very simple for, for the end user to follow.

And let me actually stop the video plane, okay? And, uh, whether you're on a mobile device, whether you're on a desktop, that's your typical BYOD flow and primary use case, obviously for that is higher ed as students bring in, uh, all sorts of things and you want them to be on that, your own network, or you want them to be, you know, enabled for, for WPA three, et cetera, et cetera. Yeah, just, uh, curious, are you seeing uptick in, uh, two FA requirements, uh, for the onboarding process?

So, uh, the onboarding process is something you will complete, uh, probably once. Uh, again, let's talk about, let's say higher ed. You'll probably do it once a year or once a semester, depending on, you know, the, the policy requirements of the, of the university, or some, some customers would actually say, well, hey, issue is certificate for five years.

I don't care. I'm gonna check if the, if the user is valid. The MFA is there, uh, usually enabled by the default.

All the IDPs today will enforce you to have MFA enabled when you're going through this kind of, you know, web type of authentication process. But once you've done that onboarding, the way you connect to, to the network is you're presenting your cer, right? That, so that's completely transparent to the end user.

That wifi profile gets embedded in your machine. You have a CER that CER identifies you. And then the n will actually check, you know, are you still active user of which groups you belong to, which level of access you want to have, et cetera, et cetera.

Alright? Okay. Now this is the BYOD portion, right?

So what we are, uh, uh, releasing, and by the way, this is gonna be available this summer, early this summer, right? So what we are releasing is, uh, BYOD portion. That's what, uh, what we've looked at right now.

We will support Windows, Mac, uh, Android, iOS at the start, and Marvis client will be the vehicle that would actually configure the yearend device and, you know, push the cert, push the wifi profile, et cetera. Now, with that, we are also releasing full blown cloud PPI or certificate infrastructure, uh, delivered as part of the this dashboard. What this means is it's not just about BYOD, you can also use it for your managed devices via our existing MDM integrations that, uh, that we currently have.

So that means that if you have your, uh, your managed endpoints via Intune via Champ, again, this is what we, what we'll do at the start, you can actually use our call PKI to let your clients, uh, uh, get their, their certificates from our PKI while, uh, MDM is still managing the client, right? So there is no need to install the amount of client app. The MDM will do the work for you, and we'll just use our, uh, PK endpoint.

Do that, Ava? Yep. I have, I have a question.

If you're running a Marvis client on one of those oss, can that Marvis client also be a Marvis mini agent? Uh, so we've, we've started talking about the, the, uh, persona of the Marvis client that sends telemetry. That's what, uh, that's an option that you will have, uh, when you will, you'll be able to send telemetry from that Marvis client installed, uh, on the device saying basically, you know, uh, which GPS are you hearing in the environment, uh, when you're roaming, why do, why do you actually make these decisions?

Et cetera, et cetera. So you will get that, uh, level of, uh, information optionally. Uh, once, once we get to, to minis, then, you know, uh, Mars client is get another, uh, yet another presence point for us.

So, yes. Mm-hmm. Okay.

All right. Any, any questions on, on the PPI or, or onboarding? Okay, very good.

So, again, as I said, this is available this summer. We are, uh, getting, uh, you know, really close to, to, to get this released. Very excited about it.

There are, you know, lots of, uh, companies out there that are actually, they don't have the PKI or they don't want to keep managing the on-prem PKI anymore. So we want to provide a, you know, a a simple and seamless solution to them. Now, item number two I wanna talk about is, oh, it's a fancy name of saying this.

It's an always on posture or continuous authorization, if you will. Uh, we've been doing, uh, integrations with various MDM providers since, since the start. So we, we do integrations with Intune and Jam Jam, uh, uh, VMware, workspace one, uh, so oti, et cetera, et cetera.

Now, the way these integrations have done, or have actually allowed us to do posture assessment, right? So you're getting the endpoint health or compliance status from that MDM, and you use that compliance status in your policy. So you say, if Intune tells us that the device is compliant, you know, go and, uh, have unrestricted access.

If you're not compliant, go, go into quarantine and have some, uh, some more restrictions. The challenge was the, uh, with most of these is, uh, MDMs are not, you know, very frequent that actually checking with the client themselves, right? So they may check with the client every couple of hours, and within these couple of hours, anything and everything may happen.

So, uh, in addition to what we do today with MDMs actually doing, uh, or, you know, working on, uh, integration with, uh, EDR platforms that are, you know, that have agents on, on your devices, and their only purpose is actually to, uh, determining if, you know, if, if your device is impacted, has malware, if it has some uncompliant, uh, things installed on it. But what they provide to us is really the real timeness of data. So this is the first time when we, uh, you know, add the, uh, an option to do, to ingest data into, uh, into our access assurance live from these providers, right?

So it's, it's not like we have to wait for something to happen or pull periodically or wait for the authentication to repeat. Anytime the client is, for example, uh, detected with a malware, there is a notification sent to us from one of these, uh, EDR providers. We will start with CrowdStrike and Sentinel One.

So they will send us live notification, we'll be able to, uh, immediately change the policy on the client, right? So that's, that's why we call it like an always on posture course. Now, let's look at the demo.

So what we'll look at is it's a, you know, simple scenario. Uh, we will first look at the, just the additional, we'll, uh, we we're, were just looking at Sentinel One as an example here. So we have Sentinel One account linked in our dashboard.

So again, it's a one time process where you link your missed dashboard with your, uh, EDR providers to provide an URL. And, uh, and an API token, easy as that. The second, uh, second point is you need to create a, a list of policies.

So again, here we are just creating three simple policies. We are looking at infected clients that need to drop into quarantine DA and get quarantine role or policy. Healthy clients will get full access into the employee network and get the employee role and unknown.

Maybe they don't have an agent. We will still put them, uh, on a quarantine network. Now, we'll look at one client example.

So we'll pull some, uh, NAC live data coming from one client that's, that's connected. And I'll show you like, what is the, you know, what is the problem we are trying to solve here? So, uh, look at the initial connection of that client.

So at 2 36 here, you see the, uh, there was an event that's saying this client was allowed to connect to the network at 2 36, right? It went through all of these authorization processes. So we did the ETLS authentication.

We did then did a lookup, uh, incent, no one, it was actually deemed healthy at that point, right? Was, okay. So we let them in and the client got full, uh, full access or restrictions.

Now, let's look at what happened to this client. Just a couple of seconds later, we'll move to a Sentinel One dashboard, or the video will move to Sentinel One dashboard, but we did, so now what we see is actually we've detected the malware, uh, for this client 10 seconds later after he joined the network, right? So in a normal world, you would've waited for another couple of hours before you would put them into quarantine.

But in this case, sent, no one says, oh, actually, I'm gonna send a notification webhook back to, uh, uh, back to nac. And this will trigger an action on our site, right? So we're sending the, uh, the webhook, and then once we move back to, uh, the missed dashboard, what you'll see is actually there is a dynamic update event saying, Hey, now this client is infected.

Now rerun the policy. So it'll actually do the, uh, change of authorization, whether it's a wireless or wired client, doesn't really matter. It'll always bounce the connection, rerun the policy, and at that point, uh, with the new status, it will give the more restricted access to, to the client.

Now, the beauty of this is you don't really have to do match in order to con to configure this, right? So you just link your EDR provider into the missed dashboard. You create some policies.

Now, boom, you have your, uh, posture assessment happening in real time. So that's the, uh, the, the beauty of it. I'm pause and save your question.

Can you define what, can you be specific about what triggers that? 'cause I know like some EDR, uh, solutions will, will trigger alerts and like a posture state change when it's just, you know, encryption has been temporarily disabled because an application is loading or something is running. Can you, can you be prescriptive with that?

Right? So you, you can be, so again, depending on the EDR provider, they all have their own metrics, so to speak. So in case of Sentinel one, it's the client is either infected or it's not infected, and the infected, the infected status is defined on Sentinel one.

All these policies are happening there, right? So you are defining what, what it means to be infected. Uh, we are just getting the status, yes or no.

We say, uh, you know, with, with some others. So take CrowdStrike, they would actually give you the risk factor. They will give you like low, medium, high, et cetera.

So you will be able to specify in your insurance policies, like, okay, if it's a low risk, we maybe let it stay connected with less restrictions. If it's high risk, drop it in some debt. Uh, I'm gonna deal with this later.

But the, the compliance logic happens in the source of trust, which for the client, which is your EDI, really the NAC is only getting that, uh, information back from, from the EDR saying, this client is infected. Let us also isolate that, uh, that device on the network side. Okay?

Can I have one more follow up question with that? Um, because so many of the EDR vendors have their own like auto quarantine at the software level, where they can do things on the interface so they can modify the, the firewall. What was the gap that you saw where we needed to be doing this back on the network again?

Uh, so, uh, again, it's, uh, if, if you look at, uh, at the existing EDRs, and most of the time they, they have a very, like yes or no, uh, kind of, uh, kind of triggers. So, uh, you either block all access on the, on the agent itself, or you allow everything, and then, uh, you, you start enforcing some restrictions. But there is no granularity in terms of, uh, in terms of what policy you can assign in this scenarios.

In, in many scenario, in many EDRs that, that we've seen, uh, now what you really want is to actually move that client and, uh, isolate it from the rest of the, uh, let's say unrestricted network at, so to you, so you can actually prohibit these west traffic, right? So if you move into quarantine and only allow outbound connection to the internet, then your, your resources, uh, is safe in that, in that scenario. Does that make sense?

Okay. So, uh, Sentinel one, uh, again, CrowdStrike as well. Let's talk about the third thing.

Third item of the day is profiling or fingerprinting, depending on how you want to, to name it. So, and for the most part, really, we've, we've been very successful doing all, all of our wireless profiling by leveraging the, you know, multi, multi PSK solution where, you know, your key is really the identity for the iot, and then you assign a policy based on which key client is using. But the challenge was always, so, uh, this is, this was coming from customers saying, Hey, uh, I have a bunch of wired devices that are, are, that are iot, obviously, you know, don't even dream about doing that one X on them, so you're only left this map.

So what else do you do? So this is really an attempt for us to, uh, simplify the onboarding of the iot devices. You know, mainly this will be a wired use case, but you can always extend this to wireless as well.

So what you will see now is, uh, you'll see a new capability of, uh, doing, uh, profiling as part of your, uh, access control policy. So in your off policy rules, you will be able to, uh, match on device type or device family. So it's a, an ap, an iot device, gaming console, blah, blah, blah, or device manufacturer or OS or model, want to be that grounder, I hope you don't.

Uh, so, and then you can mix and match all these four, four bucket as as much as you want. So in this scenario, uh, we'll look at just five policies, just, you know, do some basic, uh, basic segmentation. So we have our cameras, we have our AP phones, we have our printers.

So we, we are matching on the device type, which is, say a camera. And maybe we will only want to drop our access cameras to specific, you know, and again, the policy config is super, super simple. Everything is, uh, available again in one place, but what's important is the onboarding flow.

So when it comes to profiling and when it comes to profiling, and n especially on the wired side, the challenges, okay, so how do, how do I profile the device before it's on the network? You know, I, I need, I need that device to send something, some traffic so I can look at it and, and tell you what it is. So what we are doing is really creating that last policy rule here that says, okay, if you don't match any of the policy rules, right, you will drop into that catchall, uh, uh, policy at the bottom.

We'll move you to some staging network or any network with very restrictive access, fairly dead end ellan if you want, as long as the device can send some, some packets out. Once the device is dropped into that staging network, we'll do the fingerprinting in the cloud. We'll then, uh, once we determine what the device is, we'll bounce the port, we'll reapply the policy, and then move that client to the correct, correct.

So we'll look at the example of one access camera that I had in that policy before, and we'll look at the flow. So initially, when the client connects, you'll see that, you know, at, at that point, client is, or not the client, the switches the map, and the only thing we see is really the MAC address of the client. And that doesn't give us much except the macro UI.

Now. So you could see OS is empty, uh, model device type. Uh, everything is, uh, unknown at that point.

Now, you'll see that there is a fingerprint change, uh, event that actually, you know, there is a, there is a microservice in the cloud that actually looks at the, uh, at the packets that are sent, uh, uh, by the client, and they're streamed to the, to the cloud. Once we know what that device is. In this case, it's a, it's a camera, there's a model of it.

It assigns a family to that device. We will then issue COA, or, uh, in this case, uh, since it's a wired device, we are always doing a port bounce to make sure the client gets the, uh, the AP from, from the new vlan. And at that point, we are matching the new authentication policy rule, which is, you know, designed for our cameras.

So that process is fully automated. Again, uh, the, the beauty of this is you don't really need to configure anything else in, in, on the switch side or anywhere else. The only thing you need to do is to configure the policy.

All the COA per bonds thing is all automated and done by us, right? So something that you'd probably spend, um, quite a bit of time with, uh, other net products, uh, that's simplified. And, uh, uh, now, uh, now it'll be available, uh, in, in access assurance.

In fact, it is now in early access, I forgot to say now. Now we'll talk about, and please interrupt if there are questions in between, but I will talk about, uh, some specifics on, actually, this slide is not turning. Now it does.

Okay. So some specifics, right? Uh, on how we are doing and what we are doing, uh, behind the scenes.

So, as I said, this is a fingerprinting or profiling service that runs in our cloud. It, uh, gets data from multiple sources. So it gets, uh, network side metadata that comes from our switches, aps, or, you know, even third party devices that are using, using our a it gets data from, from this client if it's installed on the device or any third parties that we integrate directly.

So all these M-D-M-M-D-M-E-D-R integrations I've spoken about, we actually get fingerprinting involved about the endpoints as well. So all of that gets sent to the fingerprinting service, kinda, uh, does, does its magic. It has, uh, has its own logic on how to prioritize certain information over other, it produces the final fingerprint that it actually sends down to our, uh, npod.

So all the policy can actually be applied and, you know, the proper segmentation, uh, will be done. Now, what it also does is it continuously reevaluates the fingerprint, right? So, uh, some of the things that, uh, that, that you see in, in some products is, you know, the fingerprint is only detected once and then it stays forever.

So we are actually reevaluating it, uh, based on the data that that keeps, uh, coming to that profiling service. And here, what you see is it's completely passive. Right now.

There is no requirement to put any, any tap source sensors or probes or anything like that. We get the information from, uh, from the network in line, right? So that's the, that's the important, the important point, Ava.

Yep, please. So if it's passive, is that just if, is that assuming it missed infrastructure, whether switches ap? Well, Uh, not only.

So today, uh, so for third party, uh, we also, uh, we also get information, uh, in, in radio accounting. So like, there's device sensors in pretty much every, uh, you know, every solution out there. So they would send, send you the metadata that, uh, that we need, and we can parse that as well.

But I assume it's gonna be more accurate. If it's your infrastructure and you've got the full data Flow, it, it'll be, yeah. So, and again, uh, this is what we release right now.

Well, with the passive info collection, uh, I'm sure you know, next year in MFB, you'll, uh, you'll see the slight change a little bit, but, oh, yeah. Quick question. Um, can you put any sort of custom fingerprints in?

So if you've got an unusual device that you know how to identify it, can you, how can, can I tell myths this is what sensor looks like or, Right. So right now, uh, right now, uh, you cannot beat the fingerprint back to us, but what, uh, what you can do, and again, be before this profile, I should have mentioned, uh, the way we've been, uh, doing, uh, and many customers, uh, integrate, uh, uh, with our N points to, uh, through API interface. So, you know, if a customer has CMDB with all the data and they know what their devices are and where they are and what they are, they can actually push this data to, to us, API.

And, you know, we have very, very, very large customers doing that at, at, at high scale. I mean, like millions of endpoints. Now with the profiling, this is an automated way for us to actually, uh, do this for you.

If you want to tag something specifically, you have an unusual device, uh, you can actually create, uh, an endpoint. Like there's a knock endpoint page where you can tag the client with, with certain, uh, certain labels. So you can say, this is, you know, a camera and building one floor, two x, y, z, something like that.

Use these labels in the policies. So that's something you can do today, we are looking at, uh, providing like a feedback loop for the customer to actually say, oh, this profile that you've done automatically, I want this improved because this and that. But we are not there right now.

Okay. Are you seeing a uptick in, uh, profiling, you know, say headless iot devices, sensors, um, what kind of am mid are you seeing there? So the primary, as I said in the beginning, right, the primary use case is really wired iot.

So like, take enterprises, all sorts of things like starting from IP phones and printers to, uh, all sorts of OT sensors or controllers, uh, et cetera, et cetera. So these need need to be profiled and they need to be dropped into a particular, a particular segment on the wireless side. Uh, again, because, uh, prior to that, we've been doing the, uh, multi PSK type, um, IOT deployment where, you know, A PSK is actually, uh, used by certain device type.

So you say, you know, this is a PSK for my hvac, this is a PSK for, for my cameras. And at that point, this is very, uh, deterministic, kind of implicit trust. So I'm, again, seeing more profiling on wire side versus wireless, but, you know, it doesn't mean that you can't combine it.

Okay. Guava, I have a question. Um, I'm just trying to think about this from a higher ED point of view.

'cause there's a lot of BYOD devices. Uh, I could potentially see, uh, a ton of policies, uh, being created and, and tying back to that Marvis client that gets installed, how, uh, one of the questions that was brought online from, uh, Anders was ED room. So how, how are you integrating and, and making that more mainstream with Edge Room SSIDs?

Like, can we push that certificate through the Marvis code? Is that just a marvis? So, So, so let me rewind at the beginning.

So if you look at this, right, so, uh, the Marvis line is what actually allows you to onboard your, uh, your devices to room. So think of a student coming into the, to campus. They're there for the first time.

All they do is they, they log into the portal with your, you know, university credentials, right? It will let them, uh, provision their device by just downloading the Marvis client app. And it will, what, what it, it is going here, this step, it's actually provisioning a certificate for that user, and it's provisioning the wifi profile, right?

Okay. Now, the certificate that you're provisioning here, it ha it has the user identity. So you can actually create a policy, uh, in assurance and say, oh, hey, uh, this is, this is, this user is part of the student group.

I'm gonna drop it in the student vLab. So your policies will be very, very simple. If your policies will say, oh, if it's a student go here, your staff go there.

If you are some somebody special, you know, do something else. But at the, uh, Marvis client will, uh, allow your students to onboard. This is the BYD portion, the PPI solution that I've shown on the, on the next slide.

For, for the MDM integrations, this will help you for your managed devices. Like if, if you have any, like sometimes top devices are managed in higher ed and in, in this scenario, you can actually differentiate between the two by just looking at the certificate and how the certificate looks. So we, we provide that capability in granularity today, but actually, you know, uh, our higher ed customers are using that extensively today.

So, so when you say certificate, you're talking about a missed certificate? Yeah, It's a missed issued certificate, but that's is issued to your, uh, end user end user device. Okay.

But the left of this is, is MiSiS issued, correct? It is MiSiS, yeah. The, The left side is mm-hmm.

The left side and the right side is as well, it's MiSiS issued, it's the cloud PPI that we host, right? That's that cloud PPI will be your PPI or your organization, right? It's not shared with anybody else, but it's gonna be issuing certificates for everything on the left hand side if you're using the app to board.

And if you have MDM integration done, then uh, it'll be issued certificates for your MDM managed clients. So the difference is for MDM clients, you don't need to install a Mars client app, because the MDM is actually the facilitator. The MDM will put the profile and put sort the cloud, PPI and the MIS cloud PK will find that, sir.

Okay. So it's designed to replace Intune Cloud, PKI? Yes.

Oh, but it would only apply to the ones that you onboarded through that portal, through the MIS infrastructure, et cetera, et cetera? Correct. Okay.

Ava may just interrupt. Just I think the point is, so today, uh, you know, first, you know, to support certificates within access assurance, we're using, you know, third party ca, you know, bring your own ca right? What we're saying is, with the MIS cloud, P-K-P-K-I, we can, we can operate in both a sort of a, uh, provision on devices using the Marvis client, uh, or, you know, through a managed type of workflow using, uh, you know, ake type integration.

Yeah. I'm just trying to figure out where, where it would make sense from a managed device scenario to use this platform instead of something that we already have. Yep.

Right. More system. It's an option in route ca, or, right?

Yeah, it's an option. And, uh, there are still a lot of customers who don't have any today, or they're planning to migrate from, you know, the, the legacy windows, uh, windows. That's when, uh, this will be an option.

I have gone. Awesome. S Slava, are You, are you good?

You've I'm good. Alright. Uh, Actually, actually, actually one last thing because, uh, we've, we've digressed and we've, uh, went back to, to mys spine.

So let me go back to the profiling part 'cause I was, so, one last thing before, before we finish. So the reevaluation fingerprint, where this comes handy is actually, oh, it allows us to actually do maximum detection, right? So when we, when we think about the typical scenarios, especially with auditing or say, you know, you, you had a printer connected or you had a, a camera connected, somebody can then splits the mac of that, uh, printer disconnects the printer can actually, you know, Linux device and starts some sort of attack.

So what will, what will happen here is our fingerprint reevaluation will come in handy it first because it's gonna do the enforcement that will say, oh, hey, yeah, you have the same Mac, but you're, you've been printer or you've been a camera and now you're a Linux, uh, a Linux laptop. That's not good. Let us bound.

We will rerun the policy. You will probably end up in some staging or quarantine anyway, but that enforcement is immediate. But what we will do is we'll also generate a Clima Max thing alert saying, Hey, this is happening.

You may wanna look into this. 'cause the same act was seen as two completely different devices and we are being really careful here. Basically, you know, just any dramatic changes.

So obviously if you've changed from Windows 10 to 11, that's not the max thing, but if you've changed from, you know, a printer to, to a laptop, that's cost of concern. Hey, Slava, on, on that, are you tagging that device then with a, Hey, this has been max spoofed so that it can just be blocked until something goes in a manually reevaluate. So potentially, potentially an, uh, an kind of auto, auto action for, for Marvis where you would be able to say, Hey, uh, I want this to be automatically blocked until I otherwise today it's reevaluating the policy.

And if you don't match the previous condition, you'll likely end up in, into, you know, uh, in the default data and vlan. Awesome. Uh, thank, thank, thank you sva.

So let me, uh, close out just to level set on, on nac, um, our history and our industry says NAC and happy customers don't belong in the same sentence. Right? You know, that's been our history where this is, this product in general.

The category has been tainted with very heavy on-prem systems. Uh, we have the happiest customers in the world on nac. If you have, if you, if you don't believe that you have to try access assurance, um, uh, sort of proof in the pudding, uh, the largest customer we are deploying right now has 3 million endpoints deploying on our cloud nac, right?

We have actually, uh, uh, deployed NAC now, uh, these NAC pops for, uh, a cloud driven N system are deployed around the world. So if an employee from a US-based company goes to India or, or China, wherever else they are, they're connecting to a, uh, the closest nack pop, all this kind of stuff, completely cloud native, you know, uh, being able to enable nack to be easy and simple to be deployed. Um, we've achieved, uh, I I I'm really proud of the work that has been done on this thing.

So if you're new to Juniper Mist and new to Access Assurance, you gotta try this to believe this. So, uh, Sam, uh, Any sort of survivability features with missed edge doing caching and things along those lines? Oh, yes.

Yeah, we didn't talk about that. We should stop. I Actually, actually we did Sam last m and d, we showed that.

So, uh, we released site survivability LA uh, late last year. So the way, the way this is done is you have a local side edge that's under normal conditions, does nothing but just caching, right? So your clients are still authenticated through, through the, through the net cloud.

All the heavy lifting is done in the cloud. Misage just learns the cache of all of the clients we have seen in that site for the period that you specify. So you know, up to say, so if we have seen that client on that site in the last month, and then you suddenly lose all of your internet connectivity, so you cannot talk to any of the N pods, aps, and switches will automatically fail over to that local misage, right?

And at that point, Misage will start saying, oh, okay, I know the last fall is for that client. I know that's the last policy for that client. So they will keep authenticating for as long as you want.

So this is designed to survive even, you know, full power outages if, you know the whole building goes down, comes back, and only, you know, only mis are available. So yes. Okay.