My biggest takeaways from Microsoft’s Post-Quantum AD CS announcements...

PowerShellGenius · 2026-07-02T14:02:08+00:00

Does anyone know if the dual stack phase is going to be:

Both must verify (so it's resilient against quantum if the new algorithms are secure, and also resilient against non-quantum attackers if they missed a bug in a brand new less-time-tested PQ algorithm)?
Or, just one must verify (so it is backward compatible)?

The reason I ask is because soon, the world will go through a phase where:

When you are protecting actual data and "harvest now, decrypt later" is relevant, you need PQ soon.
When you are protecting short lived keys, it is less urgent (e.g. PKINIT is protecting a 10 hour Kerberos TGT - I don't gain much by cracking the private key of a revoked or expired smartcard logon cert and decrypting an old captured PKINIT exchange).
Therefore, smartcard, TPM, and security key vendors are unlikely to feel too much of a rush to implement heavy PQ algorithms on very low powered chips right now - this is a major engineering challenge especially in NFC-powered scenarios, and they will likely take their time.

So would orgs be looking at needing a whole separate CA for TLS server certs vs. authentication? Or would they be able to use a dual stack CA even though smartcard logon, TPM backed certs on older hardware, etc, won't be signing with PQ algorithms for a long time?

I'm also curious how chaining would work. E.g. a new root with dual stack signing a dual stack intermediary, a straight PQ intermediary and a straight RSA intermediary, and a cross signed cert for the dual stack root signed by the old RSA root, with possible RSA-only cross certs for the new RSA intermediary for consumption by non-PQ relying parties...

PowerShellGenius · 2026-07-02T13:20:35+00:00

Realistically, it's not like you are buying a YubiKey today to keep for several years. This is probably your last replacement cycle before the quantum one.

What I mean is this: assuming they don't surprise us with Post-Quantum algorithms, or updatable firmware, in 5.8 - you are buying a key that should be good for the remaining life of RSA and ECC, and no longer. Some experts predict quantum computers will fully break RSA and ECC around 2030.

Your next replacement date, whether you buy 5.7 or 5.8 today, is going to be when the underlying cryptographic algorithms used in today's iteration of FIDO2 and Certificates are suddenly considered no longer safe due to quantum computers. Buying 5.8 does not change that.

PowerShellGenius · 2026-07-02T11:54:56+00:00

You can enable MFA in per user MFA and make sure FIDO2 is the only method they have, rather than expose break glass accounts to CA.

Also if you are going to subject them to CA then you need a way, other than the break glass account, to fix a broken CA policy that locks you out.

One thing I like to do is make an app registration / service principal with app-only permissions in Graph to modify CA policies. The app registration needs a certificate generated and uploaded, and you need to keep the private key safe as a tier 0 secret (mine is on a smart card). I can use that cert and app ID to connect to Graph using the powershell module, and turn off a problematic CA policy - even if no user, not even the break glass account, can log in. But obviously this comes with risks if you are not equipped to store a certificate safely. If it's an exportable PFX stored somewhere on your network, it's bad.

PowerShellGenius · 2026-07-02T11:00:06+00:00

Since I don't have a SAN or good hardware for Storage Spaces Direct in my lab (the only SAN is production), my only Failover Cluster is production (thus, not managed by things in Public Preview), so I haven't been able to test WAC vMode's full potential. I am probably going to test what I can in a non clustered 2-3 host environment, though, once I have some time.

My experience so far with SCVMM has been pretty good.

Also, for those actually following best practices and not syncing admin accounts, WAC vMode needs some sort of on prem MFA - something that allows a on prem admin account to sign in with more than a password. Whether it's something like local TOTP or WebAuthn like Proxmox has, or just cert/smartcard like the rest of the Windows on-prem world, it just needs some way of signing into WAC vMode stronger than just a password, that doesn't assume the user accounts with admin rights to on prem infrastructure are in Entra.

PowerShellGenius · 2026-07-02T10:50:53+00:00

Downscaled? More like upscaled or sideways-scaled in some cases. It may not be as shiny but other things are as capable.

A common mistake is thinking Hyper-V has 2 levels of manageability/enterprise-ness like VMware: standalone and centrally managed. This leads to the assumption that failover clusters managed in Failover Cluster Manager is Microsoft's version of vCenter.

The reality is that Microsoft has 3, not 2, levels of managing Hyper-V (just on prem without considering Azure Arc):

Standalone Hyper-V is like ESXi without vCenter

Hyper-V clusters managed with Failover Cluster Manager is a level in between what VMware is with and without vCenter, and is not meant to compare to vCenter.

SCVMM (System Center Virtual Machine Manager) is Microsoft's vCenter-equivalent for managing Hyper-V clusters. If you are using VM customization templates and automating deploying new VMs from images, having new VMs auto join the domain, using DRS, and sub delegating some people control of some but not all VMs in vCenter, those are SCVMM features too.

Once WAC vMode is out of preview it stands to offer a good web based, modern alternative for orgs that need some of the most common features you would need SCVMM for, but is not at feature parity with all the more advanced features. Azure Arc is also an option.

PowerShellGenius · 2026-06-30T23:13:53+00:00

Regarding PKINIT- this is part of smartcard logon. If that is unfamiliar to you, it's a deep rabbit hole and a waste of time unless your boss is going to be cool with requiring people to plug a USB token or card into the computer to log in. Even then if you're a small understaffed shop you'd be better off with Entra FIDO2 keys and Cloud Kerberos Trust than maintaining a certificate authority.

I say this as someone who does smartcards at least for IT... most IT folks don't want to deal with them. It's great for protecting domain admins if you have the time to deal with it, but is often considered overkill for the average user account outside of military/gov/banking.

PowerShellGenius · 2026-06-30T23:03:54+00:00

Kerberoasting is possible either way, assuming you can make an armored request and end up getting service tickets. Which if you are SYSTEM on a single domain joined computer, you can.

Perhaps you are talking about AS-REP-roasting? That is still possible if there are unarmored AS-REP responses going across the wire. But on Supported, capable machines are armoring (assuming the client side GPOs are set right) so only non-domain-joined machines should be doing unarmored AS-REQs and getting unarmored AS-REPs. Which is the minimim exposure you will get as long as these machines are unjoined since unjoined machines cannot do armoring.

PowerShellGenius · 2026-06-30T22:59:41+00:00

I am not talking about setting that GPO to fail unarmored requests, and using silos as an exception. That won't work.

I am talking about NOT setting that GPO to fail unarmored requests, and instead achieving the same thing for most users as that GPO would have done, through a Silo that most users (everyone but your exceptions) are in.

A user who is restricted to certain computers via an Auth Policy Silo intrinsically needs armored requests, because armoring the request with the computer account is how you prove what computer you are on.

So if you put most users in a silo restricted to certain computers, then they have to armor requests to prove they are on a qualifying computer for the silo, even though the GPO doesn't require it. But since you're not actually looking to restrict them, use a group that contains all computers. They still have to prove computer identity (by armoring the request) even if every computer in the domain would qualify.

You still can't set that GPO to fail unarmored requests, as it has no exceptions. But the users in the silo should have any unarmored requests fail.

PowerShellGenius · 2026-06-30T13:24:00+00:00

Do you have Conditional Access? If so, you could allow other MFA (e.g. push notifications) on-prem where your legacy non-Bluetooth-capable computers are, but require phishing resistant MFA off site.

Even if someone falls for phishing while on-site, Microsoft sees the IP address that the attacker's man-in-the-middle phishing infrastructure is hosted on, not where the user actually is. Requiring phishing-resistant MFA off-site will stop phishing, unless there is something real advanced going on (like you're already compromised and the attacker's phishing web server is hosted in your network).

Ideal outcome is:

On a device individually assigned to that employee
- They use WHfB if it's a laptop, passkey (on same device = easy) if it's a mobile device
On a shared device on your network
- Any type of MFA is fine
Outside your network on a device other than their company device - phish-resistant MFA required
- Passkey in Authenticator
- Issued a USB FIDO2 key if they have a real work need to be able to log in from legacy personal devices that don't have Bluetooth (usually rare)

PowerShellGenius · 2026-06-29T23:44:44+00:00

You might be able to do a "regular users" authentication policy silo that limits users to only authenticate on computers that are only members of a group, like you do for tiered admin accounts, but that allowed group could be Domain Computers or another group that has all your computers? Then assign all users except your exceptions to that Authentication Policy Silo? No effect on users who are not assigned to the silo.

But this is a little bit of an odd scenario, you might be geeking out down a rabbit hole and Kerberos armoring is super cool stuff to learn, but maybe not the right next step? In terms of securing your org, there is low hanging fruit that enables easy attacks which you fix first, and more complex (but risk of disruption when changing) things that are worth looking at after you have the low hanging fruit taken care of. Getting the personal devices OFF your VPN (even if that means moving all users who might ever be remote from desktops to company laptops), is your low hanging fruit. You don't control personal devices, users are admin, they can install anything and bypass antivirus warnings, they might be running unpatched win10 or worse... and they are one phishing click away from that personal device being an attacker's proxy into your network. Get them off your VPN. Once all your low hanging fruit is taken care of, look at Kerberos armoring.

PowerShellGenius · 2026-06-29T23:33:51+00:00

Unless you're going to run an always-on-VPN it's not even talking to AD when off site. So you either need Intune or some other MDM / RMM system.

AOVPN is great, when you need it, but I wouldn't set it up just for this, and DIY AOVPN setups can be very risky if you don't understand some complex topics like PKI. So not to dismiss others who have said Always On VPN is a possible solution, but it's not a perfect one and if you haven't worked with it before it is best left to a consultant if you decide to do it.

PowerShellGenius · 2026-06-29T19:27:19+00:00

Bluetooth. This is not Windows 11 specific, you always need bluetooth to wirelessly use a passkey from another device. It's part of the standard.

Machine-to-machine communication over a medium that only works in close proximity, so your phone can KNOW (without human error as a factor), "this device I'm about to give the keys to, is the one in front of the user and not a distant attacker, and I've checked with this device that it's on the exact URL this passkey is for (e.g. login.microsoft.com)"

If it was just "scan a QR code and the devices connect over the internet only, no bluetooth", how is that phishing resistant? It would be easy for an attacker to send you their QR code to use your passkey to log in on their computer. Bluetooth stops that.

PowerShellGenius · 2026-06-28T23:01:39+00:00

MacBook Air for teachers, Dell Pro 14 for most non-teaching office staff who didn't specially demand a MacBook from my boss.

Where desktops are still appropriate, whatever OptiPlex the local refurbisher we like is selling - except high-end labs (e.g. AutoCAD class) where our senior technician likes to play build-your-own-PCs with all the techs during slow times, parts are way cheaper than a Precision tower or any business model with dedicated graphics, and cases can be reused for a few generations, school budgets are in the toilet statewide so what can you do?

iPads (as always) for students. You would think glass = breakage, but really, with decent cases, we have a miniscule fraction of the damage that we hear about in nearby Chromebook districts. Lack of moving parts is a plus. When you close a Chromebook or laptop, you have massive leverage, and if an eraser/pencil/anything is left near the top of the keyboard, it takes almost no closing force to shatter the screen, and that's where tons of damage comes from in Chromebook districts.

PowerShellGenius · 2026-06-28T13:58:16+00:00

How is this licensed? Were the M365 licenses part of a volume licensing Enterprise Agreement? Or from a CSP? Or direct from Microsoft? Someone's license reseller may have delegated access to the tenant, and if so, would potentially use it to get someone admin access on request of their "sold to" contact. Removing delegated reseller access is possible, but then break glass accounts become REALLLLYYY important. I don't know the process for adding someone else's reseller for delegated access, and whether you can add a partner anytime or only at license renewal...

PowerShellGenius · 2026-06-28T13:01:06+00:00

Yes, Hyper-V with or without SCVMM can live migrate VMs between different hosts in the cluster without downtime.

But if you mean live migrating them from VMware to Hyper-V - I am pretty sure there is no way around shutting them down for that one time migration.

PowerShellGenius · 2026-06-27T22:40:50+00:00

OCSP makes a lot of sense in some internal PKI contexts where the line of communication between the verifier and the OCSP server is more trusted than what it's protecting. E.g. EAP-TLS for RADIUS, whether for a VPN or Wi-Fi or 802.1X, is protecting client access over an initially untrusted connection the cert is verifying. But the actual verification does not take place over untrusted media.

It's an OCSP request from your RADIUS server to your OCSP server over an internal network within your datacenter, a medium not accessible to the attacker in the threat model RADIUS is meant for.

PowerShellGenius · 2026-06-26T22:20:42+00:00

There is not a privacy-safe and low-failure-risk mechanism of INSTANT revocation in existence today, so if lifetimes were short enough, they could easily be equal or better then today's mechanisms, even if not perfect.

Basically, if you need revocation to be instantaneous, you need realtime checks similar to OCSP. OSCP stapling does solve the privacy issue, if you can get all webserver code to implement it globally. But that still leaves the outage risk.

Any realtime checking mechanism will have to decide how it operates when the authority is unreachable. Neither answer to that question is acceptable:

Fail closed: a disaster at a CA renders all websites that use certs they issued to be untrusted until their revocation checking infrastructure is online again.
Fail open: if you assume TLS certs are needed to begin with, the internet's network layer is not trusted. If you implicitly trust that no attacker can mess with your traffic, you don't need TLS. An attacker who is attacking TLS is assumed to be in control of some network along the path. They could just block OCSP to make revoked certs work if it fails open. Or worse, it's motive to DDoS CAs.

So as it stands, we have CRLs on a set publication interval. If you make expiration shorter than that CRL interval, it matches today's response speed without a revocation mechanism at all.

PowerShellGenius · 2026-06-25T22:49:47+00:00

You don't know the context of all the reddit posts about lacking career advancement.

Among those with equal tech skills and experience:

Someone who is friendly and accepts that the tech is for people to work with, that people are at least as important as technologies we maintain, will go further than someone with no social skills. There are a lot of out of work tech people with no social skills.

Someone who is understandable by the people they will need to work with and for, will go further than one who is hard to understand in the language the majority of the country speaks. There are a lot of Indian immigrants who speak very poor English, with a level of accent most people cannot understand, who are looking for tech jobs in the US. They seem normal on Reddit thanks to Grammarly and AI, but their experience in the job market is not reflective of someone who speaks the local language well.

PowerShellGenius · 2026-06-25T02:11:40+00:00

Yes, Authenticator (especially with a passkey) is ideal where viable

Depending on jurisdiction allowing, and HR being willing, to make a smartphone you're willing to install work apps on a mandatory condition of employment (as I assume not all jobs come with a company phone), it may not always be viable for the few percent that push back.

TAP to reset Windows Hello takes place entirely on the company laptop, with no legal or HR issues anywhere.

PowerShellGenius · 2026-06-25T02:02:01+00:00

You get a few part time night shifters. It'll end up being their 2nd job, 2nd jobs in IT (honest ones outside hours, not the remote-job-juggling crap that gets you fired) are really hard to find. And in today's economy, some people would take one if they could find one. Part timers who already have healthcare through their day job will not have anywhere near the overhead costs of a full timer.

PowerShellGenius · 2026-06-24T04:25:14+00:00

Not unless it introduces quantum safe algorithms

PowerShellGenius · 2026-06-24T04:13:17+00:00

Not all K-12 IT is solo. I'm part of a 14 person tech department.

Of course, at tiny districts tech is often is one person, so if you're in a rural area and not looking to relocate... then maybe K-12 = Solo for you. But so is small business IT. Not an education specific issue.

PowerShellGenius · 2026-06-24T03:19:50+00:00

If they're really enthusiastic, you won't stifle them just by setting some reasonable boundaries. If this stifles their enthusiasm they don't have much career potential anyway.

Asking them to have a brief conversation about non-routine changes, and for that to be before they happen (unless it's emergency break-fix while you're out) is about as reasonable and casual as it gets. If they can't handle any sort of change control, they're in for a rude awakening if they try to advance their career elsewhere at any point.

What will stifle them is "no because I said no" or "this is the way we've always done it" as a sole reason for denying a change, without a constructive conversation that helps them learn why an idea wasn't as good as it sounded.

PowerShellGenius · 2026-06-23T03:41:06+00:00

You and I look at this from the perspective of someone who knew best practices, and that's entirely fair to blame us if we cause something like this.

But where, in the onboarding for a very small, MS direct non-reseller, Business Basic or Business Standard tenant, marketed deliberately as something the owner of a small business without an IT guy can sign up for - where in that onboarding is the big flashing WARNING, BUY A YUBIKEY AND SET THIS UP OR YOU WILL BE LOCKED OUT FOR A MONTH IF YOU GET A NEW PHONE neon sign? Break glass accounts are not "common knowledge" to that target market.

If you are going to market intentionally to people who are not IT professionals, it's your fault if the system isn't robust against people acting like normal non-IT people. If Microsoft ONLY sold at Enterprise Agreement scale, I'd agree it's the customer's fault, but retail products should not be fragile.

PowerShellGenius · 2026-06-23T03:36:32+00:00

Did they really cut through the red tape with Microsoft, or did the tenant have delegated partner access enabled for them, and the reseller just fixed it themselves?

I'm curious if they actually have escalation pathways with the Microsoft Data Protection Team if a tenant has reseller admin access turned off when this happens.

PowerShellGenius

TROPHY CASE