Conditional Access for Education

I’m very excited about heading to the WATSSA education conference in Perth, Australia in a couple of months to deliver a workshop around identity security in the Microsoft world. This is important since let’s face it, most schools (and indeed businesses) using Microsoft 365 aren’t using half of the security features they’re licensed for and those they have managed to deploy are often inconsistent and unenforced. I’ve ’lived in interesting times’ with it for more than a decade, deploying, managing and auditing it in schools, governments and businesses, so I have a pretty clear idea of what good looks like and honestly it’s not that easy to get there. While there’s certainly been some good progress on mandatory baselines and templates that make it easier to deploy best-practice policies, these aren’t yet presented in a cohesive way or one that takes the organisation’s environment into account, so that’s what I’m setting out to do here.

This is not a general security guide for M365; books have been written on that subject by greater minds than mine. This is a reference for using Conditional Access to build a good-enough set of protections against the majority of prevalent threats and it’s for anyone in education with responsibility for managing M365 in a school or university environment. Most academic orgs running the Microsoft stack have at least an Entra Plan 1 license (part of A3) so that’s what I’ve targeted this at. Finally, while this is based on what I’ve found useful over the years, it is all grounded in Microsoft’s own advice.

If you want to get ahead, get a CAP 🧢

So why focus on Conditional Access when there’s a bunch of other security stuff going on in M365? Quite simply, CA is the nexus of every access decision. It’s a big if-this-then-that machine that stands between each user and the resource they’re trying to access once they’ve logged in and it knows who they are. It refers to a set of policies (CAPs) that define its decisions. They say things like ‘if Russia then nope’ or ‘if work device then yes’ or ‘if risky then do an MFA challenge’. It’s the core protective mechanism of M365 and your best friend when it comes to keeping your cloud estate secure. However, CAPs can only make a difference if they are CRUD 😜:

• Complete: Covering every user across every means of connection to every available resource. As a rule this means ’every exclude should have a follow-up include’.
• Robust: They should push for the strongest, most secure means of authentication for the most valuable resources. As a rule this means ‘don’t wuss out’, like excluding office locations from MFA because they’re considered more secure (they’re not) or cutting back on the breadth and depth of policies (if you cut corners, adversaries will too).
• Uncompromising: Sometimes you need to raise the bar and sometimes you need to shut them out. If you’re doing it right, eventually someone will be inconvenienced - but better that than the alternative. As a rule this means ‘don’t fear the block’.
• Demonstrable: We need to test our policies to be sure they’re complete and working as intended since it’s easy to make a small mistake that leaves something unprotected. As a rule this means ‘simulate to validate’.

On the latter point, I recommend the excellent (and free, since we’re talking to edu!) Maester tool, the brainchild of Microsoft PM Merill Fernando. This lightweight Powershell module will audit every nook and cranny of your tenant within a matter of minutes and provide a clear and actionable report against a variety of security standards. The degree of support it has gathered from industry contributors in the short time it’s been around is remarkable, so it’s well-used and vetted. It does depend on a level of read access but this can be set up on a temporary basis and revoked once the report is complete. I could easily fill a few more excited pages on it but will contain myself to including links to its docs against my relevant policies because it has some of the clearest guidance around.

Emergency Exit 🏃‍♂️‍➡️

Deploying CAPs is simple; just browse to https://enca.cmd.ms with the correct admin rights (global admin, security admin or conditional access admin) and policies can be created and deployed from there. With great power comes great responsibility though; it’s entirely possible to block access to your entire tenant with a single erroneous policy. Please don’t let this scare you away though! If you have responsibility for your organisation’s M365 tenant, there is no better investment you can make in your security. I have personally seen this fear make IT admins shy away from commitment, particularly in education where teams are often small and stretched, since they see it as too risky or posing too great a potential for disruption or assuming that it’s designed for businesses and would not align well with education requirements. No wonder that nearly half of authentications in M365 are still not using MFA!

Let me reassure you that you need not be an M365 expert to manage Conditional Access; this is within reach of a competent IT generalist with the time to do some research. If deployed and managed correctly it does not pose any risks to your school and it could – and more likely will – save your bacon some day soon.

There are three rules to avoiding friendly fire with a CAP:

• Report-Only: Any new policies should first be deployed in report-only state so that their potential effects may be passively monitored. The recently-launched policy impact report is a game-changing aid for this as it presents successes and failures graphically, allowing quick estimation of impact and an easy drop-off for deeper investigation.
• Breakglass: Every tenant should have an emergency access (or ‘breakglass’) account which is excluded from all CAPs. Microsoft recommend you secure this account with a passkey for maximum protection.
• Document: Policies should be documented to keep track of changes and so that unanticipated outcomes can be reverted to a known-good state quickly. idPowerApp is great for this and will compile all of your policies into slides with graphical representations of their function.

What’s in a name?

My reference for policy nomenclature is Microsoft’s Conditional Access for Zero Trust - this hasn’t been updated in quite a while but I still think it’s pretty great. The aim is to get enough information in the name of the policy that when you see it in the logs you can easily figure out what it’s doing. CA policies don’t have descriptions so you need to cram a lot in. My preference is:

<prefix>-<ref>-<persona>-<app>-<platform>-<desc>

• Prefix: This is optional but can be handy when there are multiple tenants involved; if needed I’d go for a 3 or 4-letter acronym for the school which indicates the specific tenant.
• Reference: This is the numeric reference for the policies and given that they’re all sorted by name, this governs their order of display in the console. Microsoft’s template sorts these by persona but I prefer having the policies sorted by purpose, so my scheme is:
  • 0xx - Catch-all policies for MFA and session limits
  • 1xx - Policies that have a block action
  • 2xx - Policies that have a grant action
  • 3xx - Auth Contexts for PIM and Protected Actions
• Persona:
  • Global - Policies that apply to ‘all users’.
  • Admins - Policies that apply to admins via role or group.
  • Internals - Policies that apply to internal users by group or all users minus guests.
  • Externals - Policies that apply to external users. I don’t distinguish between types in this policy set, though Microsoft’s reference includes guest as a subcategory of externals.
• Resources:
  • AllResources - Policies that apply to all apps.
  • O365 - Policies that apply to all of Office365.
  • Others as needed, e.g. Sharepoint, Teams, etc (I don’t include any others in this policy set)
• Platform:
  • AnyPlatform - Policies that include all platforms.
  • LegacyPlatforms - Policies that include Exchange Activesync and other.
  • Unknown - Policies that inverse-match on known user agents (Windows, Linux, MacOS, iOS and Android).
  • Other combinations as needed.
• Description: The short-text explanation of the policy’s purpose.

This means when I see the policy ABC-CA101-Global-AllApps-LegacyPlatforms-LegacyAuth I can immediately see it’s a block, it applies globally to all apps and the purpose is blocking legacy authentication.

Quick Wins

I’m now going to make a liar of myself since I opened this blog by saying that this stuff is hard, but it’s important to head off despair before I launch into the full list of policies. If you can only do two things, do these two things. If you have capacity for more, and I hope you do, by all means continue on to the rest, but this will put you on a sound footing.

1. Demand non-crappy MFA globally (see CA001). This shuts attackers out of credential stuffing and other easy routes for account compromise which somehow remains a massive risk in the year 2025. Get rid of any old per-user MFA while you’re at it to simplify both the end-user and admin experience.
2. Go passwordless for admins, ensuring the strongest possible means of authentication to areas with the greatest potential for impact (see CA204). It’s a fact that not all MFA is created equal; just recently we’ve seen Microsoft’s widely-used TOTP topple with a trivial bypass. By far the simplest way to protect an M365 tenant is to ensure that all users who hold or can request privileged roles are registered for phishing-resistant methods. The Microsoft Authenticator app can now be used to register passkeys with no additional configuration and given that the number of users with admin access to any given tenant should be small, this really should be an attainable goal.

Core Policies

CA001-Global-AllResources-AnyPlatform-GlobalMFA

Users: Include all, exclude staff, guests and students
Target resources: All resources
Access controls / Grant: Grant access, require multifactor auth strength
Access controls / Session / Sign-in frequency: 14 days

It’s best practice to have one policy that targets all users for MFA and its aim is to set a floor of basic MFA applied to anything that might not be covered by a subsequent policy (a ‘catch-all’). Students have historically been excluded since they usually don’t have access to a phone to run the Microsoft Authenticator app, though Windows Hello is increasingly viable, if potentially a little rough around the edges. Other groups that have a follow-up include at this level should also be excluded here; for me this is staff and guests. This policy can therefore have a shorter sign-in frequency since it will only apply to accounts that sit outside of normal use.

Since this is a basic catch-all it can be set to either the generic MFA strength or a custom ‘global auth strength’ which we would use as our most generous, supporting the widest number of methods in order to avoid unexpected lockouts. Over the years I got into the habit of not excluding my breakglass account from this policy in order to have a basic requirement for its MFA, although this is no longer strictly necessary as Microsoft enforces basic MFA at the application level for admin portal access (see MT.1005).

Ref: MT.1007, MT.1004

CA002-Internals-AllResources-AnyPlatform-StaffMFA

Users: Include staff, exclude breakglass
Target resources: All resources
Access controls / Grant: Grant access, require staff auth strength
Access controls / Session / Sign-in frequency: 30 days

This policy targets our specific internal user groups with our staff auth strength policy. This will look different for every organisation but the aim in having a custom auth strength for staff is that we can support only the methods we have in use and exclude any less secure ones. For most this will likely involve a mix of Microsoft Authenticator app push notifications and some passwordless methods. We may end up with more than one policy and auth strength for internals, for example where we are transitioning to passwordless with some groups needing to have newer methods enforced while others are still reliant on older methods. Typically a sign-in frequency of 30 days is acceptable; this is significantly shorter than the default of 90 days which limits risk in the case of token theft, while posing little additional auth-burden.

CA003-Externals-AllResources-AnyPlatform-GuestMFA

Users / Include guest or external users: all except service provider users
Target resources: All resources
Access controls / Grant: Grant access, require multifactor auth strength
Access controls / Session / Sign-in frequency: 7 days

As with our catch-all global policy, we again use the default MFA auth strength so as not to prevent guests from accessing resources, since we don’t have control over their devices or capabilities. We can usually deploy the most restrictive sign-in frequency here, since guest access is usually ad-hoc rather than continuous. Where we have arrangements for long-term guest access (e.g. another school whose students are enrolled in one of our classes), we would target these users with an exclusion and a follow-up include in another policy with more stringent MFA and more lenient sign-in frequency to maintain that balance.

Ref: MT.1016

CA004-Externals-AllResources-AnyPlatform-PartnerMFA

Users / Include guest or external users: service provider users only
Target resources: All resources
Access controls / Grant: Grant access, require partner auth strength

The partner auth strength policy is a concession on two fronts. Firstly, in my experience most partners aren’t ready for passwordless, or at least not when it comes to connecting to customer tenants, so we can’t hold them to our staff auth strength but nor should we let them away with the more lenient guest policy. Secondly, even when partners do use passwordless methods they may be using different AAGUIDs, so we can include those in this auth strength in order to support the most secure possible method of connection.

CA101-Global-AllResources-LegacyPlatforms-LegacyAuth

Users: Include all
Target resources: All resources
Conditions / Client Apps: Exchange Activesync clients & other clients
Access controls / Grant: Block access

This policy is critical for mitigating against exposure from vulnerabilities in legacy authentication protocols (e.g. POP, SMTP, IMAP) and is the only other policy I don’t have my breakglass account excluded from. It prevents attacks that circumvent MFA to perform credential stuffing and password spraying and actually has a notable impact on log sizes if you’re using Sentinel since it cuts out a substantial amount of unauthorised login attempts from ‘Internet background radiation’.

Ref: MT.1033, MT.1009, MT.1010

CA102-Global-AllResources-AnyPlatform-DeviceCode

Users: Include all, exclude breakglass
Target resources: All resources
Conditions / Authentication flow: Device code flow
Access controls / Grant: Block access

Device Code is designed for logging into devices that don’t have a keyboard such as a smart tv or VOIP phone. The user is presented with a simple code on the screen, they visit https://microsoft.com/devicelogin on their phone and key it in to authenticate the device to their account. This is super convenient but it presents a substantial risk of abuse since all an attacker needs to do is convince a user to type in their code and they gain complete control. It’s rapidly gaining popularity amongst attackers as a result of this simplicity. It circumvents other MFA and CA requirements since the resulting access and refresh tokens can be used indefinitely without needing to reauthenticate. I’d suggest that if there is legitimate need for the feature, it should be heavily restricted to specific users, devices and locations.

Ref: MT.1051

CA103-Global-AllResources-Unknown-UnapprovedDevices

Users: Include all, exclude breakglass
Target resources: All resources
Conditions / Device platforms: Include all, exclude supported
Access controls / Grant: Block access

A security control that merely prunes some low-hanging fruit can still be worth its weight in gold. Limiting users’ options for device types to the ones we actually give them (e.g. Windows and iOS) is an easy win since we know it won’t cause any problems, while unknown or unsupported devices often present security risks (e.g. from a data breach or malware infection). This won’t slow a determined attacker since they can merely spoof a user agent, but it will reduce the attack surface. Even if you never actually turn the policy on, it’s really interesting to run in report-only and then view the impact report after a week or two. You will likely catch a few logs in the failed category that you weren’t expecting, such as from unmanaged devices and service principals.

Ref: MT.1015

CA104-Global-AllResources-AnyPlatform-UntrustedLocations

Users: Include all, exclude breakglass
Target resources: All resources
Network: Include any network or location, exclude supported
Access controls / Grant: Block access

This is in some ways a dumb control - circumventing a geo-block is child’s play for any skilled attacker after all - and yet the stats in any tenant I’ve worked on consistently show it blocking an astounding amount of illegitimate access. You must understand your organisation’s expected access locations before applying it in order to ensure that no outliers are blocked, so don’t skip a period in report-only even if you think you know where your users are. While an outright block is recommended, where that’s not possible (such as with a subset of highly mobile globe-trotters) a close second is granting access with increased restrictions such as a higher level of MFA and reduced session length. Ideally this would take the form of an exclusion from this policy with a follow-up include to a subsequent one.

A more tightly-scoped version of this policy can be used for students; for example where we know that only senior students are allowed to take their devices home, we can create a policy that blocks junior students from access at any external location. I have used this to effectively offset the increased risk from students not having MFA.

CA105-Externals-AllResources-AnyPlatform-GuestAllowlist

Users / Include guest or external users: all except service provider users, exclude breakglass
Target resources: Include all, exclude supported
Access controls / Grant: Block access

When we invite guest users to our tenant, we want to ensure that they only have access to the apps we want to make accessible to them and that they can’t go poking around in other areas. This reduces risk, especially if an account is compromised. The resources would likely include Teams and Sharepoint. I usually exclude service providers since they typically need broader access than guests. They could be included in the scope of a followup-include policy with slightly broader access, though I haven’t felt the need for this as yet.

CA106-Global-Actions-AnyPlatform-SecurityRegistration

Users: Include all, exclude breakglass and NewStaff group
Target resources / User Actions: Register security information
Network: Include any network or location, exclude supported
Conditions: Filter for devices, devices matching the rule, 'device.isCompliant -eq True'
Access controls / Grant: Block access

This policy bolsters the strength of our MFA by ensuring that it’s only possible to register a new MFA method or reset a password under controlled circumstances; either from a trusted location or a trusted device. This prevents an attacker gaining post-exploitation persistence after stealing a session token by registering their own method – a prevalent and growing risk. It’s also interesting to monitor failures against this specific policy, since it’s a low-noise indication of compromise. I exclude a dynamic group called ‘NewStaff’ which is set based on employeeHireDate plus 30 days; this allows some leeway for new users to register their MFA method and get a device into compliance before they are restricted.

Ref: MT.1011

CA107-Global-AllResources-AnyPlatform-HighRiskSignIns (P2)

Users: Include all, exclude breakglass
Target resources: All resources
Conditions / Sign-in risk: High
Access controls / Grant: Block access

In my experience high-risk sign-ins have an extremely low false positive rate and can safely be blocked outright which has the advantage of immediate protection and low complexity. However, the traditional recommendation is to require MFA which is less disruptive in the case of a false positive. Take your choice depending on risk appetite, or split this into two policies; one which blocks privileged and at-risk users outright and another that allows MFA remediation for standard users similar to CA201.

CA108-Global-AllResources-AnyPlatform-HighRiskUsers (P2)

Users: Include all, exclude breakglass
Target resources: All resources
Conditions / User risk: High
Access controls / Grant: Block access

Again I prefer an outright block for high risk users, accepting the potential disruption to end users and the admin overhead required to investigate and restore access when this is triggered since in my experience this event happens only on rare occasions. The traditional recommendation is requiring a password change, which is aimed at taking any compromised credentials out of circulation, however this is largely redundant in a passwordless environment where passwords are absent or deprecated. Sign in risk and user risk should always be configured in separate policies, since conditions are cumulative.

Ref: MT.1049

CA201-Internals-AllResources-AnyPlatform-MedRiskSignIns (P2)

Users: Include staff, exclude breakglass
Target resources: All resources
Conditions / Sign-in risk: Medium
Access controls / Grant: Grant access, require staff auth strength
Access controls / Session / Sign-in frequency: every time

For the medium-risk events, I adopt the traditional recommendation for high risk which requires a completely new sign-in with MFA using the sign-in frequency of ’every time’. This is a strong control and could be a real pain for users if it’s overused since it forces a completely fresh sign-in including an MFA challenge. If a risk event is triggered though, we may have an attacker in possession of a stolen token which could include a valid MFA claim, so this is the only way to be sure that we’re excluding any chance of replay. Once the user signs in successfully, their risk is dismissed so that ’every time’ is in actuality ‘just once’ - and then they’re back to the standard session length. This can only be targeted at users with P2 licenses who can fulfil MFA requirements, which is pretty much just staff for me; other users will just remain blocked until an admin intervenes.

Ref: MT.1012

CA202-Global-Actions-AnyPlatform-DeviceRegistration

Users: Include all, exclude breakglass
Target resources / User Actions: Register or join devices
Access controls / Grant: Grant access, require phishing-resistant auth strength

Ideally we want to have a high bar for adding new devices into Entra since if not sufficiently secured this can allow an avenue for an attacker to maintain persistence and expand their access. In the case where we have a user-driven Autopilot deployment and users who don’t yet have phishing-resistant MFA we may want to create a less restrictive policy for them so end users can register them at OOBE. If you’re doing this you’ll likely already have a group for Autopilot devices based on the device.physicalIds property, so they can be excluded here and added as a follow-up inclusion.

Ref: MT.1011

CA203-Global-O365-iOSAndroid-AppProtection

Users: Include all, exclude breakglass
Target resources: all resources
Conditions / Device platforms: iOS, Android
Access controls / Grant: Grant access, require approved client app, require app protection policy

This policy limits all corporate mobile access to apps that are compliant with app protection policies and then it links to those policies in Intune. This forces any devices with corporate info (Outlook, OneDrive, etc) to comply with these policies which can be used to enforce additional password and storage protection, block personal backups and data export, etc. I’m still using require approved client app, but that’s going away soon so I’ll update this one shortly.

Ref: MT.1019

CA204-Global-AdminPortals-AnyPlatform-AdminMFA

Users: Include all, exclude breakglass
Target resources / Include: Microsoft Admin Portals
Access controls / Grant: Grant access, require phishing-resistant auth strength, require device to be marked as compliant
Access controls / Session / Sign-in frequency: 12 hours

Targeting top-level MFA requirements at admin portals is a quick win since it’s a high-impact area with (hopefully) a limited number of valid users; even if they don’t currently have phishing-resistant MFA it shouldn’t be hard to get them there, and our admins should already be using compliant corporate devices anyway so requiring them for access isn’t a burden.

Microsoft’s version of this policy is more specific in that it’s scoped to a small subset of privileged roles but I’m happier having this apply globally for two reasons:

1. There are roles not traditionally considered to be privileged but that nonetheless have wide-ranging access to systems or data (see if you can spot some on this list). If we don’t secure those roles, that makes them a soft target for attackers who will absolutely be interested in developing novel attacks using non-traditional routes from accounts less likely to be protected.
2. The Admin Portals resource is an ’easy button’; it’s a perfect way of targeting a policy right at the heart of the thing that attackers would need to use to cause damage to an organisation in a way that limits the collateral auth-burden to non-privileged users. Narrowing its application works against its essential utility whereas applied globally it ensures that even accounts with minimal access cannot be easily compromised and used as an entry point for further attacks.

A potential drawback of this approach is that end users can use the ‘portal.office.com’ site (which is technically an admin portal) in order to download the Office desktop apps installer onto a new device. If they don’t comply with this policy, they will be blocked from access.

If a partner cannot comply with phishing-resistant auth requirements, per CA004, service provider users should be excluded from this policy and a follow-up include created for admin portals with the partner auth strength.

Ref: MT.1014

Optional Policies

CA005-Admins-AllResources-AnyPlatform-AdminMFA

Users: Include admin roles, exclude breakglass
Target resources: All resources
Access controls / Grant: Grant access, require admin auth strength, require device to be marked as compliant
Access controls / Session / Sign-in frequency: 12 hours

It is best practice to ensure that any users with admin roles are forced to authenticate with MFA and use a short session. I would absolutely recommend deploying this policy if there are no other protections targeting admin accounts, with the admin auth strength targeting the strongest practical methods. However I consider it to be optional in the following circumstances:

1. Users that have or can request admin roles are already in scope of CA002 so have reasonable MFA requirements.
2. Users that have or can request admin roles have phishing-resistant MFA methods registered.
3. System-preferred MFA is enabled.
4. No high-level admin roles (e.g. Global Admin) have standing privileges.
5. Policy CA301 is deployed along with Privileged Identity Management which requires a reauthentication with phishing-resistant MFA when grabbing an admin role.
6. Policy CA208 is deployed which requires phishing-resistant MFA and a short session life when accessing an admin portal.

Treating this policy as optional is helpful because it reduces burden. Consider a user who is a helpdesk admin because they need it daily for their job. Forcing a role-based requirement for a short session means that this is a global requirement across all of their devices. If they have a phone then they must sign in to that every day, even if they only use it to read their email and respond to Teams messages. If instead we secure the role with PIM and control access to the admin portals with a short session policy, then they get a normal 30-day session on their phone and only need to use a short 12-hour session on their admin device which is a much more manageable balance.

Ref: MT.1006

CA205-Internals-O365-Win-TokenProtection

Users: Include staff and students, exclude breakglass
Target resources / Include: Office 365 Exchange Online, Office 365 Sharepoint Online
Conditions / Device platforms: Windows
Conditions / Client apps: Mobile apps and desktop clients
Access controls / Session: Require token protection for sign-in sessions

Token protection is a relatively new feature that links tokens to registered devices using a cryptographic binding, preventing tokens from being reused elsewhere if stolen by an attacker. Having this in play basically phish-proofs the session. Unfortunately it depends on some hefty undergirding; the device needs to be Entra-registered or joined and it needs application support, which exists only in Windows with desktop clients at present. I’ve got this policy in play but because it’s so niche it barely protects more than 5% of sessions. It’s the shape of things to come though; broader support is in the pipeline and I recently noticed that Microsoft is doing it opportunistically even in the absence of a CAP where there’s device and app support in place.

CA301-Global-Passkey-AnyPlatform-Reauth

Users: Include all, exclude breakglass
Target resources / Include: Auth Context
Access controls / Grant: Grant access, require admin auth strength, require device to be marked as compliant
Access controls / Session / Sign-in frequency: Every time

Authentication Contexts are a handy way of embedding Conditional Access within applications. This is particularly useful for two key security features:

• Privileged Identity Management - This is an immensely cool P2 feature that provides just-in-time admin access, with the aim of avoiding standing admin privileges. When someone needs to perform a task that requires an admin role, they request access through an elevation process. That process can be tied to a CAP via an auth context, so we can apply this CAP to a role activation meaning that if I want to promote myself to a Global Admin I cannot replay an existing token since I must sign in every time, and I need to use a compliant device and strong MFA. This is a high bar and negates the risk of token theft.
• Protected Actions - This does not require P2 but actually gets pretty close to PIM in terms of utility. It allows a CAP to be tied to an action within Entra, such as deleting or modifying an object, and can pose an additional challenge before that action can be completed. It’s actually most useful when tied back to the modification or removal of CAPs themselves, since if an attacker can remove or edit CAPs then they can remove the restrictions placed on their own access. Adding a protected action means that even if they have the correct role and thus sufficient access, they must still complete an additional auth challenge. Given that these actions occur rarely, this has great return on investment.

Parting Thoughts

Nothing stands still in this industry. This reference is valid right now, in mid-2025, but by next year we’ll have a bunch of better controls and the way current ones work will be revised and changed. We need to keep up with these changes if we are to understand how best to protect our schools.

While I’ve maintained a focus on Conditional Access in this blog, there are other supporting security controls in M365 that are just as important. For example, since CAPs only kick in after logon, they’re not doing anything to block an adversary from guessing passwords or users from using dumb passwords that can be easily guessed. It’s crucial to enable password protection and smart lockout which counteract this at the authentication level.

I wish you well on your journey and if you find something I haven’t mentioned, message me on my socials; I’m always up for a chat!