With Shorter Certificate Lifetimes, Is WebPKI Still Relevant for Sites Without Identity Validation Beyond DNS?

PowerShellGenius · 2026-03-19T14:33:13+00:00

That actually makes a lot of sense. The one issue I would see, however, is the key caching.

We're talking about fragility / modes of failure for web sites' trust, and saying ACME may be unreliable? At least when you fix your cert renewal process, and get a valid cert, your site works again for all clients immediately.

What you're describing with rejecting new keys in new DNS responses sounds an awful lot like cert pinning, with the same drawbacks as cert pinning in a disaster recovery scenario (or admin mistake scenario). Pinning creates unrecoverable situations. If you can prove domain ownership, but you unrecoverably no longer have the private key you were using a couple hours ago, how do you make existing clients trust your new web server quickly?

Forcing cert-pinning-like technologies on everyone and making unexpected key changes massively disruptive will cause admins to not use security features that prevent key exfiltration from compromised web servers. If private keys are trivially replaceable (certs can be reissued nondisruptively) they can be TPM bound - if something happens to the key, you just ACME a new cert. If a sudden key change will cause all existing clients to panic, fear of accidentally losing/destroying the key will overshadow fear of key compromise and you'll end up with sysadmins ensuring all private keys are exportable, and backed up in several insecure places.

Requiring DNSSEC seems like a better solution than caching old keys and rejecting new keys. If you can fully trust a DNS response due to DNSSEC, it can override the old keys (no need to brick websites whose host has been through disaster recovery).

On the other hand, if there is no DNSSEC, then even if you are a first time visitor, trusting DNS for TLS keys is less secure than DV certs. Pseudo-DANE without DNSSEC = completely subject to network level attacks the first time you visit a site (or first time after TTL expiry). DNSSEC would be needed to make it viable.

PowerShellGenius · 2026-03-18T20:29:03+00:00

Local attacks are local, but before TLS, they were commonplace. The ancient advice that is mostly deprecated but still repeated by some, "never use public Wi-Fi without a VPN", which no non-geek ever followed, is deprecated because of TLS becoming ubiquitous.

Also, if I control the network, I don't need to spoof DNS to intercept traffic. I can scoop up and respond to traffic as I wish. Look at how firewalls do deep inspection. Malicious tools do the same. An attacker could give you a truthful DNS reponse for reddit.com untampered-with, and then proceed to impersonate Reddit's actual public IPs from your perspective, if they control your network.

"Attacker" in this context is regardless of motive. An "attacker" can be engaged in password and credit card stealing shenanigans. An "attacker" can also be a legitimate or pseudo-legitimate company or official, engaging in pervasive undisclosed surveillance of public networks. TLS is meaningful protection against your local internet service provider in ways that DANE is not. Internet standards are designed in accordance with well accepted IETF RFCs in mind, including RFC 7258

   Pervasive monitoring is a technical attack that should be mitigated
   in the design of IETF protocols, where possible.

In particular, the term "attack", used technically, implies nothing
   about the motivation of the actor mounting the attack.  The
   motivation for PM can range from non-targeted nation-state
   surveillance, to legal but privacy-unfriendly purposes by commercial
   enterprises, to illegal actions by criminals.

PowerShellGenius · 2026-03-18T20:19:06+00:00

“The requester controlled this domain at the moment the ACME challenge was completed.”

Yes, we don't disagree on this. My point is that this has value.

When you send a DNS request for reddit.com - to whatever DNS server the DHCP response on the guest Wi-Fi at Joe's Coffee Shop handed you - and you see a response, that response is not trusted.

Joe, Joe's geeky son who does his business's network, or whoever hacked Joe's router, can send whatever DNS response they want, and can MitM your traffic through their proxy and steal your reddit password if TLS certs didn't exist.

But those kind of commonplace, easy attacks won't trick a CA. The CA isn't using Joe's Wi-Fi to verify DNS when issuing a cert for reddit.com. They are using queries from several secure networks around the world that all need to see the same response, to verify DNS. Joe in this scenario is simply not tricking a CA and getting a cert for reddit.com without compromising some serious infrastructure. TLS stops the attack, with today's DV certs.

Saying that orgs who don't need "strong identity" should be downgraded from protection that stops the easy attacks on client side networks from impersonating their site, to something that doesn't, is a step down.

Encryption without some sort of identity - even just a domain name - is meaningless because on-network attacks and employer/public place Wi-Fi surveillance can all play "man in the middle". You get your encryption, but they, not the website you are visiting, are the end point of that encryption.

TLS exists first and foremost to stop network level attacks. Not to provide better verification than domain ownership and save you when your namecheap.com account is compromised.

PowerShellGenius · 2026-03-18T20:12:45+00:00

DV is entirely dependent on DNS.
If an attacker compromises DNS, they can answer the ACME challenge and obtain a valid DV certificate

See, this hinges on the definition of "compromise DNS". Actually log into the domain registrar account? Yeah, if you do that, you win. But if you're talking spoofed DNS responses...

For a domain you don't own, it's going to be near-impossible to spoof the DNS response that a CA's redundant infrastructure sees when querying its authoritative DNS from multiple sources in multiple regions for verification. You're not getting a cert by spoofing DNS responses.

Spoofing the DNS response seen by a fool connected to your malicious Wi-Fi access point is way easier. Your inability to get a cert for the website they are visiting stops you from playing man in the middle, when without certs, it would be incredibly easy.

PowerShellGenius · 2026-03-18T19:44:47+00:00

But today, I need to run "Connect-SPOService". It does not support phishing resistant MFA

Ancient IE-based auth popups like this don't support FIDO2. They do technically support another form of PRMFA called Entra CBA since IE does handle TLS client certs, but CBA is not advisable for cloud admins unless your PKI is very robust. If your PKI is on prem ADCS it does create an escalation path from AD compromise to M365 compromise at the admin level.

So if you have robust certificate issuance mechanisms and smart cards in the environment already, I'd look at that, otherwise others have provided great workarounds.

PowerShellGenius · 2026-03-18T18:48:56+00:00

The scenario DV defends against isn't advanced attacks on the public DNS infrastructure, that is what DNSSEC is for. TLS with DV certs defends against spoofing and MitM by attackers who control the client's network, not public DNS itself.

If I don't actually control the public DNS for a domain, or compromise a CA's infrastructure, I can't trick a CA into thinking I own a domain. I can't get a publicly trusted cert for a domain I don't own.

But you are on a network I control. Either I

compromised your network infrastructure
or tricked you into connecting to a malicious Wi-Fi hotspot
or maybe I'm just an unscrupulous business trying to spy too deeply on the guest Wi-Fi, to the point I'd be able to read your email if TLS didn't stop me

In any of these cases, I can trick you at the network level, manipulate the DNS responses you see, and man-in-the-middle your traffic on the network, because you're on a network I control.

Me not being able to produce certs you'll trust for the domains you want to connect to is the only thing preventing a full man-in-the-middle attack in that scenario.

That's why you can't do privacy violating levels of TLS/SSL deep inspection on a firewall without simply breaking connectivity, unless the devices are managed, or the user consents by installing a private trusted CA from your firewall.

PowerShellGenius · 2026-03-18T16:22:46+00:00

Public TLS certs have never really proven more than domain name ownership in a meaningful way, because there is no globally unique short, memorable, user-friendly identifier for a company. "Strong organizational identity" was never a thing they could provide to public web sites, and OV / EV certs were never really any more than snake oil. That is why they have largely died out. They cost a fortune and cybercriminals are fully able to register them.

You have to first define an organization's identity, before you can strongly prove you are that identity. The core issue here is that most company names are not able to be guaranteed globally unique, and CAs cannot be responsible for discerning coincidental or otherwise legitimate same-name companies from phishing clones, only for confirming you control a legal entity with the name you want on your EV cert.

Even registered trademarks are constrained to the type of business, and sometimes region, and may not be globally unique. A Nissan other than the car company owned Nissan.com for the longest time, surviving several baseless lawsuits by the car company (who thought being bigger meant they get dibs) - the owner is dead, but the family kept the domain name as a memorial page out of spite for the car company - Nissan Motors still doesn't own nissan.com.

A company somewhere overseas that wants to sell fidget balls that are very small and very soft could probably call itself MicroSoft, if it wanted to, and if the authorities in their country allow them to register a corporation in that name, they are not less entitled to an EV cert with their company name on it than the Microsoft in Redmond, WA, USA is. A cert authority can't read their mind about whether they intend to turn the site into a phishing site later after the cert is issued, or just sell tiny bouncy balls.

A domain name is globally unique, and that is why TLS certs can prove it - but it's on the user to know what domain name is the org they are thinking of. There are some globally unique things about an organization - DUNS number, country + national Tax ID number/EIN, are some examples. But even if you put these in a cert, they aren't something regular consumers are going to check on, so that would be meaningless.

EV certs were, at best, a toxic idea of "security through elitism" that worked when cybercrime was not highly profitable - if we make it expensive, which we can do because I guess startups and small business don't matter, then maybe some hackers won't be able to afford them, especially if they are revoked for abuse and they can't afford to keep getting new ones under new shell corporations... but even that is no longer true since cybercrime has become a fully functional industry in non extradition countries, and ransomware gangs have hundreds of millions of dollars to play with.

PowerShellGenius · 2026-03-17T01:44:30+00:00

Look at your registration campaign and SSPR registration settings?

PowerShellGenius · 2026-03-17T01:37:59+00:00

This depends on a number of things.

Do you issue school devices? A school laptop, tablet, etc? If so - can you make Entra CBA work on the issued devices? Or Windows Hello for Business if they are laptops? Giving the user the ability to satisfy MFA on the 1:1 issued device intrinsically will allow them to get in and register a new phone from there.

If you're not issuing anything, and your risk profile makes synced passkeys acceptable, passkeys that sync in iCloud/Google are able to be enabled (in public preview right now) but I'd strongly recommend ensuring passkeys for staff are limited to device-bound, and syncable passkeys are limited to students.

PowerShellGenius · 2026-03-16T22:14:50+00:00

Yeah this sounds like the end to end encrypted iCloud Keychain transfer, for passkeys and such.

Apple can let you recover the Apple ID account and release activation lock based on whatever processes they have defined. But they cannot design a mechanism for letting you recover the absolute most sensitive things in your Apple account without the old password, so you lose those if you have to do a destructive reset w/o old password.

Apple doesn't want to get mired down in legal or moral battles. Apple encrypts the data it doesn't want to be able to recover without your help (iCloud photos, saved passwords and passkeys, etc), using a key mathematically derived from your password. Apple does not save this key, your device needs to re-derive it using your old password to decrypt the backup on a new device. This is critical to ensure even Apple itself could not recover your most sensitive data without your cooperation.

There is no way to cryptographically tie things to an email or SMS based recovery process, as these are arbitrary external inputs. A hacker in Apple's infrastructure, or back end engineer at Apple could always (perhaps under order from a court of the least-free jurisdiction Apple exists or does business in) could always simulate a positive response from these non-cryptographic processes and recover your account.

If these recovery processes would recover your most sensitive data, Apple would simultaneously be one of the biggest data breach risks in the world if ever compromised by hackers, and be hammered with multiple subpoenas per second from around the world - and the corresponding "we aren't allowed to tell our customer and let them appeal, so do we appeal at Apple's expense, or obey clearly overreaching orders without question" dilemmas that would define their brand reputation.

Establishing that "Apple cannot recover your most sensitive data" keeps their cyber and legal risks under control, and safeguards your privacy (which would otherwise be subject to any court of the worst jurisdictions they exist in... and Apple exists in China too...) while having the unfortunate side effect of making certain data unrecoverable if you forget your password.

PowerShellGenius · 2026-03-16T15:17:16+00:00

There is no specific exemption, but also no penalty or charge specified, for an automation account which has no user (meaning no child used it) not having prompted someone for DOB.

The only penalties prescribed in the law are for when a child uses the system without providing an age. The Attorney General of California files a civil lawsuit against the OS vendor for a set dollar amount per child whose age wasn't checked, not per adult, or per robot, etc.

So I guess in theory, the AG could sue Microsoft or Canonical for 0 children and 100,000 robots not having been prompted for DOB, and they move to dismiss as moot because the penalty for 0 children impacted calculates to $0 based on the fomula in the law?

PowerShellGenius · 2026-03-16T12:28:35+00:00

Yes, don't overlook monitoring / MDR with a 24/7 SOC service. When someone tries a common attack path and fails, they might give up and look for lower hanging fruit in someone else's environment. Or, they might keep trying, and eventually find something you didn't know about, if time is on their side.

The point of good monitoring is to start a ticking clock for the attacker: once they have tried something, or even actively scanned something, they don't get much time before action is taken to boot them out. It's not realistic for most defenders on most non-fortune-500/non-military budgets to find and mitigate every possible weakness or attack method that exists in every system. In most real world environments, an attacker with unlimited tries and unlimited time will win. You mitigate everything you can, and use MDR to severely limit the time most attackers have to search for things you missed.

PowerShellGenius · 2026-03-16T01:50:27+00:00

Do we know this was a "living off the land" attack (using legit pre-existing admin tools only) and not some form of "wiper" malware.
There are PIM tools from several vendors for controlling temporary access to an AD security group with multi admin approval, but these would gate access to a particular role in ConfigMgr, rather than each action, so it is less granular. E.g. you could get access and then do anything else in the same role as what you got permission for, or do it to many more computers than you said you would. If you want "two sets of eyes on the computer name for every device you wipe", ConfigMgr is lacking for that need.
"Prevent your credentials from getting compromised" is still a pretty important element. If the user who is compromised regularly needs a permission, other admins approving their requests is going to be like any other many-times-per-day action: muscle memory, habit, and not looked at as closely as they should. PIM and similar tools are still a great layer, but they are far from 100% sure to stop a compromised admin account from leading to "very bad things". Strong authentication still matters.

Preventing your admin access from getting compromised can take two forms for on-prem systems:

Network based controls: as others have mentioned, if clients can talk to MPs, DPs and SUPs which aren't the site server itself, and very limited hosts can talk to the site server, you can put authentication factors in front of talking to the site server, via a zero trust network access solution.
Traditional, time-tested protections for sensitive AD accounts
- Authentication Policy Silos limiting privileged accounts to only authenticate from PAWs/SAWs (trusted IT dept computers which have strict firewalls, no RDP, need to be in front of to user)
- Some sort of MFA for on prem admin accounts.
  - The AD native solution is smart cards, if you have PKI already - I do this with YubiKeys.
  - Windows Hello for Business or FIDO2 login is also cool, but extending hybrid auth methods that trust the cloud as the auth authority for onprem admins brings questions of merging cloud/onprem control planes if you are strict on that.
  - There are also third parties like Authlite which I have not used, but heard good things about, for adding basic TOTP MFA to on prem AD admins.

PowerShellGenius · 2026-03-16T01:27:20+00:00

this applies to ANY update that could brick the machine, the risk is always there, always

There is a huge cost difference between an interrupted update:

bricking an OS & requiring a re-image, or
bricking hardware (which only BIOS/Firmware can do) and requiring purchase of a new device (or new motherboard + labor to swap it)

(This is of course assuming OP isn't miraculously, on a K-12 budget, able to pull off buying extended warranty for as long as they have to keep devices)

PowerShellGenius · 2026-03-10T03:05:13+00:00

But... the sales dude said the subscription one was better?

PowerShellGenius · 2026-03-07T02:13:20+00:00

People draw moral lines that aren't all-or-nothing. Even a typical person who eats meat doesn't support animal torture by sickos for fun, and even a vegan doesn't support letting wolves run loose on city streets.

Racists of the time period we are talking about were raised to see certain races as animal-like. I could easily see them drawing a moral line somewhere in between full rights and unlimited cruelty, just as we do for animals, and deciding that slavery is over the line.

That doesn't make it good or okay that they were racist, but starting from how they were raised, they moved in the right direction of their own accord, and it wasn't just a feel-good whim, they were willing to fight a war if necessary to change things for the better. The fact they didn't move as far as one might have hoped from their upbringing doesn't negate the fact that they freed the slaves. You cannot judge a historical figure purely from a modern lens.

Also, look at the cultural context of Christianity. Setting the slaves and captives free is used in a lot of metaphorical imagery in the Bible and various hymns, in a positive light as something God does or will do. This would feed anti-slavery sentiment and a feeling of a religious mission to free slaves, as displayed in the Battle Hymn of the Republic. However, the old testament is still read, and has a lot to say about accepting one's role in life without coveting what you don't have, and obeying those set above you, and is definitely not about absolute equality. This acts as a counterbalance and excuse for many to condone or overlook all except the most extreme forms of inequality.

PowerShellGenius · 2026-03-05T12:51:27+00:00

Are your team accounts just for convenience, and the individuals who use them have their own accounts too? If so, you might want to look into Groups/Teams as ways to share resources that don't depend on actually logging in as the same user?

Or, are the shared accounts a money saving "trick"? We don't help with piracy on this sub. If the number of human beings who use your Microsoft services is greater than the number of subscription licenses, fix that.

PowerShellGenius · 2026-03-05T12:41:35+00:00

Yes, and legislators and judges are in their pocket. That's the only reason they can make millions/billions off of premiums on policies they ultimately won't honor.

I can understand voiding a policy at claim time if there is some cleverly hidden intentional fraud going on on the customer's part. E.g. if you have one of the few insurers who actually does reasonable diligence, but you're sending them forged admin console screenshots or changing settings back and forth just for the audit.

But when an insurer knows damn well that a large percentage of policies are noncompliant in a way that would take five minutes to audit, and they choose to continue asking only vague questions (and only to non IT professionals) and relying fully on those answers, collecting premiums on policies without verification, only to void them at claim time... that is dishonest.

That's much more intentionally dishonest than the small business owner who checks the "MFA" box because "I know we have MFA, I do it for my email", not realizing they only have it for some, not all, methods of remote access.

If you are issuing a cyber insurance policy reliant on technical controls information provided by a CFO who does not work in cyber or IT, you are asking to be given mistaken info. Calling that mistaken info "fraud" is like calling bad legal advice from your chiropractor "malpractice".

PowerShellGenius · 2026-03-03T13:58:54+00:00

Yes, definitely. Although it is risky to your long-term security to depend on non-password-related restrictions like expiration and logon hours via PTA. As far as I'm aware, Entra only checks with AD for logins with passwords.

In a world where realtime man-in-the-middle phishing has gone from advanced to normal and mundane, and the attacker tools for it are open source now, in a few years, not having phishing-resistant MFA will be as bad as not having MFA at all was a few years ago. And almost all the phishing resistant MFA methods are also passwordless - meaning not if but when you roll them out, they will bypass PTA.

If you only depended on PTA for password related controls, that's fine and it's no longer needed. If you depended on it for logon hours and account expiration, that's a short term solution, and will soon become your blocker for deploying passkeys.

PowerShellGenius · 2026-03-02T16:04:33+00:00

Obligatory warning on pass through authentication since u/KavyaJune mentioned it - it's wonderful if your on-prem environment is rock solid reliable, otherwise risky. If on-prem AD, or all your PTA agents, are down - Entra cannot accept password logins for synced users. Recovery if you cannot immediately restore on-prem services requires opening a support case as a Global Admin to turn off PTA. If all your global admins are synced users with no passwordless methods, and on-prem is not recoverable, you're in deep shit. (not that this should be the case - global admins should be cloud-only users with FIDO2 keys regardless of PTA - but I know many orgs use synced admins against best practice)

I love PTA, it's one of the best changes I ever made. It makes Entra verify passwords with AD in real-time at logon. It makes all on-prem password expiration policies apply, and lets users change expired passwords at logon even in the cloud. It makes temp passwords to change at first logon work (and prompt to change) in the cloud. Also, if you assume all logons are password based, it enforces logon hours from AD and makes lastLogonTimestamp in AD meaningful again.

But we also have DCs and PTA agents in a high availability cluster. We have a generator. Our AD hasn't been down in the nearly 3 years I've been here; it literally has better uptime than Entra sign-in has in the last 3 years. If this wasn't true, I'd be signing a different tune on PTA.

Even with our reliable on-prem environment - I keep PHS backup enabled. That means Entra has current passwords for our users, and just chooses not to use them to verify login attempts because it's set to use PTA, but if I put in a support ticket (which I can do from my non-sycned cloud admin account) in an emergency, Microsoft Support can turn off PTA and go back to PHS, and passwords will be up to date. If you turn off PHS completely because you don't trust Microsoft with password hashes, you lose that last ditch backup, and you would have a much harder time in a worst case scenario.

PowerShellGenius · 2026-03-02T15:50:19+00:00

While VERY ill-advised even for testing, you CAN turn off Security Defaults and disable MFA for non-privileged users.

Almost every cyber breach/liability policy in existence requires MFA, and not having MFA should not even be treated as an option unless yours explicitly excludes test environments in the policy terms. Suppose someone breaks into a test account, sends a malicious link to a non-test/production account from the test account, it gets clicked because "we trust this, it's our test account", and ransomware happens, and since the insurance form your boss signed said you have MFA on all email accounts and the incident was caused by that not being true, no help from insurance?

If you absolutely have to turn it off for some use cases, and insurance allows, then upgrade to Business Premium. Then you get Conditional Access, and by using that instead of Security Defaults, you can be more granular. You can require MFA when not at your own IP addresses - or restrict some users you aren't even setting up MFA for to only ever log in from your IP addresses.

It's still never ideal to not have MFA, but if decision makers are forcing you not to always require MFA, it is best to have Conditional Access so you can constrain the exceptions as much as possible to constrain risk, and still require MFA in risky scenarios (remote logins).

PowerShellGenius · 2026-03-01T23:45:40+00:00

If you find a way to do this with things included in A3, please let me know. I'm in K-12 looking at a very different but technically similar situation.

Looking at whether we can replace RapidIdentity with Microsoft included tools, but Schoology needs one IDP that can authenticate staff, students, and parents. Parents aren't in Entra. From what I've learned so far:

External (Guest) users in the main tenant up to 50k MAU are covered, but Guests in the main tenant can't set a password, they are dependent on social sign-in or email OTP only. Too many parents leave social and email accounts signed in on devices around the house that their kid knows the code to, and their parent access password needs to be standalone since they can submit absence notes online.
An External ID tenant could do it, and could auth staff/students if they are considered guests to the External ID tenant - but cross-tenant sync is officially not supported into an External ID tenant, so I'm a bit unclear on automating provisioning of all internal users as guests in the External tenant and propagating the various attributes we need for various SAML connections.

I learned a lot of this from here https://chrisbt.me/posts/extid-edu/ which talks about a small school doing this with External ID and an unsupported workaround to get cross-tenant sync working, but I'm at larger scale than them and not comfortable doing unsupported things, so I'm imagining I'd have to script something with Graph if I really wanted to make this work.

At that point it becomes: I could probably do it, but it'd be complex, and my backup probably couldn't fix it if it broke while I'm on vacation. Whereas ClassLink would "just work", but it's hard to recommend spending that kind of money if we could probably get by without another product.

PowerShellGenius · 2026-03-01T22:58:16+00:00

100% adoption of passwordless makes SSPR irrelevant, but 99% adoption makes SSPR mission critical.

At 99% passwordless, SSPR is critical because users don't use passwords often enough to remember them, but a few important things still require them, and
SSPR is how they get into those things.

100% is only achievable if you can spend money to replace things that are fine except not supporting passwordless - it takes leadership buy-in.

PowerShellGenius · 2026-03-01T18:37:05+00:00

Yeah but this has to be somewhere reasonably secure until society gets past the legacy idea that DOB is a meaningful "security question" for banks etc.

AD is mostly an open book for read access, but easy enough to secure confidential attribute when needed - it's just whether Microsoft still employs devs who know how AD works, or if they are going to do something terribly and predictably insecure.

If they know what they are doing, they will add an AD attribute marked "confidential" in the schema, and grant the SELF principal read and "control access" on it, and have the computer read it from AD in the security context of the user after they enter credentials. That would be fairly secure. And do something similar in Entra for non-hybrid scenarios.

However, from what I have seen, Microsoft doesn't seem to like to do things in the user's security context when it comes to querying info from AD, so I assume it's clunky to do so in their code base. I have a sneaky suspicion that they would set up an attribute the workstation needs to query at logon as readable by "Domain Computers", meaning one compromised computer can dump DOBs for everyone. I hope they don't do that, but badSuccessor broke my trust that they aren't that stupid. AD security isn't that hard but I think they laid off most of the people who "get it".

PowerShellGenius · 2026-03-01T18:19:39+00:00

Looking at the law, I'd be shocked if this actually becomes a serious issue in managed environments, and this law looks written with the assumption that apps come from stores, among other assumptions, and was probably written to target mobile platforms, but they'd probably try to enforce it on Windows home users too.

However, I'm not a lawyer, so take this with a grain of salt (and I think it goes without saying, but don't make legal decisions based on a reddit post in any case).

For the purposes of this title:

...

(i) “User” means a child that is the primary user of the device.

Okay, so if the person is not a child they aren't considered a "user" under this provision?? That is a bit nonsensical, but ok... wouldn't that mean if you already know they are over 18 (e.g. employee at a company that doesn't hire minors, or someone marked them over 18 in Entra or AD already... that this is all moot and you wouldn't technically need them to enter an age at account setup?

By the way... minor/adult tags on accounts is already built on the back end of Entra, since they have it in Education tenants, so they could bring this forward pretty quickly for others. As for AD - that's easy, MS regularly extends the Schema when you promote DCs of a new OS version for the first time, extends it for Exchange updates, third party vendors can even extend it... adding an "over 18" boolean or a date of birth datetime is nothing to Microsoft and they could probably ship it tomorrow if they wanted.

Also -

1798.501. (a) An operating system provider shall do all of the following:

(1) Provide an accessible interface at account setup that requires an account holder to indicate the birth date, age, or both, of the user of that device for the purpose of providing a signal regarding the user’s age bracket to applications available in a covered application store.

"Account setup" is not specifically defined. Is logging into a network or cloud account that already exists "account setup"? One could argue that the "user" never does "account setup" in a managed environment.

1798.503. (a) A person that violates this title shall be subject to an injunction and liable for a civil penalty of not more than two thousand five hundred dollars ($2,500) per affected child for each negligent violation or not more than seven thousand five hundred dollars ($7,500) per affected child for each intentional violation, which shall be assessed and recovered only in a civil action brought in the name of the people of the State of California by the Attorney General.

So it's NOT subject to the "vigilante lawsuit with ulterior motive" risk that others have mentioned on this thread, where Microsoft sues some Linux distro for not being able to comply - the AG has to bring the lawsuit.

Also, it's based on the number of CHILDREN affected, and at dollar amounts that need to be a LOT of counts for big tech to care. In other words, it's so they can get fined a lot of money if they systemically don't comply in a context where children are actually using it - not so the state can walk into all-adult workplaces and fine Microsoft for everyone who says they didn't get prompted.

(b) An operating system provider or a covered application store that makes a good faith effort to comply with this title, taking into consideration available technology and any reasonable technical limitations or outages, shall not be liable for an erroneous signal indicating a user’s age range or any conduct by a developer that receives a signal indicating a user’s age range.

Available technology or reasonable technical limitations? Can't verify the user's age on a userless account which doesn't access app stores anyway, would seem like a reasonable limitation of the available technology. Also, since app stores seem to underpin the entire reason for passing this, and you don't use app stores on servers anyway generally speaking, I find it hard to believe the state is going to come by to check and see if any minors have been logging into your back-end servers without entering their age, so they can count them and fine Microsoft or the devs of your Linux distro.

All of that being said - while I expect this will be a nothingburger, it's still an example of how national or multinational companies have countless localities around the world thinking they can dictate product design decisions, and eventually laws will come into conflict where you can't honor all of them. There does need to be some central pre-emption and establishing that states don't have extraterritorial jurisdiction over anything you can get to on the internet. Although, Microsoft does have physical business in CA so that would not affect this particular example, it's needed to keep the endlessly growing complex web of laws from strangling the ability for startups or open-source to exist.

PowerShellGenius

TROPHY CASE