The thing everybody had learned to live with

Reboot a Mac. FileVault asks for your password. Fine, that’s expected — that’s the disk unlocking.

Then the Entra ID login window comes up and asks you to sign in again.

Two unlocks, every single reboot. Nobody filed a ticket about it, which is the part that stuck with me. It had been like that long enough that people just decided that’s how work laptops are. You only hear about the stuff that stops people working — everything else becomes background noise, and background noise is where this kind of thing sits for years.

It should be one password. So I went looking for why it wasn’t.

Why it happens

The FileVault pre-boot screen is not optional. That’s Apple. Your disk is encrypted, so something has to unlock it before macOS is meaningfully running, and no MDM is skipping that.

What normally happens next is that macOS takes the credential you just typed and passes it through to the login window, logging you straight in. One password, one login, even though two separate things authenticated you.

That passthrough is the whole trick. And it can be switched off:

Domain: com.apple.loginwindow
Key:    DisableFDEAutoLogin
Value:  true

That’s what was set. It lives in com.apple.loginwindow as a custom settings payload, not in the Jamf Connect profile itself, which is part of why it isn’t the first place you look.

With it on, FileVault unlocks the disk and then hands you to the login window with nothing carried over. Jamf Connect throws up its own window and makes you authenticate against Entra from scratch. That’s prompt number two. Nothing was broken — it was doing exactly what it had been told to do.

Here’s the part I got wrong at first

My initial read was that somebody had set this by accident and it had never been revisited.

That’s not what happened. Jamf explicitly recommends setting DisableFDEAutoLogin to true. Their reasoning is sound: FileVault passthrough bypasses Jamf Connect entirely, which means it skips your identity provider. If passthrough is on, a user can boot and be sitting at their desktop without Entra ever being consulted. For a lot of shops that’s genuinely unacceptable.

So this wasn’t a mistake left lying around. It was the vendor-recommended configuration, and turning it off meant deliberately overriding it.

Which is a different conversation, and a more interesting one.

The tradeoff, stated honestly

Restoring passthrough is not a free win, and I don’t want to describe it like one.

What you give up: Entra is no longer consulted on reboot. The login is trusted on the strength of the FileVault unlock. There’s also a keychain and password-sync angle — the Jamf Connect login window is what reconciles the local account password and login keychain against the IdP. Skip that window on reboot and the reconciliation doesn’t happen there. Users still hit the Jamf Connect window on logout, so it isn’t gone, it just isn’t on every restart.

What you get: every person on the fleet stops typing their password twice, every day, forever.

I think that’s the right call in this environment, and I can say why. The FileVault password is the account password. The disk was already encrypted. The device was already managed and enrolled. The login is happening on hardware we control. The extra Entra check on reboot was buying a fairly thin slice of assurance and charging every user in the company for it, daily.

But I’d concede immediately that this is environment-dependent. Somewhere with conditional access requirements that need the IdP evaluated on every single login should absolutely eat the second prompt — that’s exactly what Jamf’s recommendation is protecting. Somewhere with frequent IdP password changes might care more about that reconciliation happening on every restart.

The honest version is: I overrode a vendor recommendation for user experience, and I can defend the specific reasons it was safe here. Not “I found a bug and fixed it.”

The other double login (not the same thing)

This trips people up constantly, so if you’re googling this on a Tuesday afternoon:

There are two different “Jamf Connect makes me log in twice” problems.

  1. After a reboot — FileVault, then the login window. That’s this post. DisableFDEAutoLogin and passthrough.
  2. During account creation — you authenticate to the IdP in a browser window, then it asks for your password again locally. Different problem entirely. That one’s OIDCUsePassthroughAuth in Jamf Connect Login (2.5+ for Google, 2.6+ for Azure), and it needs OIDCNewPassword set to false.

Passthrough Authentication does not fix the reboot one. I’ve watched people try it and get confused when the second prompt survives a restart. Similar symptom, different layer, different fix.

What I took from it

Nobody reports friction, they just absorb it. No ticket. No complaint. A whole fleet of people typing their password twice a day, quietly assuming that was the deal. If I hadn’t rebooted my own machine and gotten annoyed, it’d still be that way. Some of the best endpoint wins aren’t in the queue at all — they’re in what people stopped bothering to mention.

Find out whether a setting is deliberate before you call it a mistake. I walked in assuming sloppiness and found a documented vendor recommendation. That reframed the whole thing from “fix a misconfiguration” to “make a posture decision and own it” — and those need very different conversations with your security team.

“Why is it like this” beats “how do I turn this off.” I could have flipped a key, watched the prompt disappear, and moved on. Knowing that the FileVault screen is unskippable, that passthrough is what collapses two authentications into one password, and that switching it on costs you an IdP check and a keychain reconciliation — that’s the difference between having fixed something and being able to defend it when someone asks why the security posture changed.