FileVault state ENABLED on new machines?

Is this a 2018 Device??

Sounds like you've got some T2 chips. Macs with those chips are indeed encrypted by default out of the box. All that you need to do at that point is enable FileVault 2 so that they can be unlocked with a password, and you'll also get the recovery key. It's pretty awesome, no more long waits for computers to encrypt - just enable the functionality and away you go!

What does this mean? It's encrypted by default, but not enabled.
Without an unlock password, it's still not safe I guess (related to security)? So this reported encryption state of JAMF is misleading.
We also have some smart groups based on this state.

Will the command "fdesetup status" always report the correct state of FileVault2 activation? (We have still some Sierra devices with HFS+, but also High Sierra and even some Mojave with APFS and some of them with T2 chip, so we need a way to know the correct state of FV2)

@hansjoerg.watzl It means the disk is encrypted out of the box and unlocks automatically when booted, and if the HD is removed from the system, the data will not be accessible. Once FV2 is enabled, it no longer unlocks until a FV2 enabled user enters their password.

APFS handles encryption natively whereas FileVault was bolted on top of HFS to provide encryption. On T2 hardware, Apple has decided to encrypt the drives at the factory (known as "Encrypted at rest"). If you were to remove the drive from the system, the data would be unreadable when connected to another system. Not that it's likely now with storage chips soldered to the motherboard.

On this new hardware, enabling FileVault simply means limiting which users are authorized to boot/unlock the system.

Jamf needs to get on the ball and make computer inventory clear as to the true state of T2 hardware. I've written an Extension Attribute to do this in the meantime.

--Ben

So the unlocking is done just by the device (T2 chip and only on this specific device) and not by any (user) password? (if not FV2 enabled)
What happens when you boot from an external medium and try to access the (encrypted) internal disk? I guess it will not be unlocked in this case? (and same when using target mode, if this still will be supported)

So the main difference between FV2 enabled on these T2 Macs is you can't unlock it manually, if not started from the internal boot disk, correct?

Does this also mean, you don't really need to enable FV2 on these T2 Macs anymore? (Only if you need to access the internal disk from external booting) So it would be more convenient for multiuser devices, where you don't' need to FV2 enable each local account first. (and that's the reason you don't need a recovery key too.)

@analog_kid

On this new hardware, enabling FileVault simply means limiting which users are authorized to boot/unlock the system.

Thanks, that was the missing link for me. ;-)

And yes, I hope too Jamf will enhance the encryption state (T2 encrypted only and/or FV2 enabled).
(We also have a T2 EA, but it's just an additional info which can be overlooked quickly.)

@kerouak yes, the affected devices are 2018

ok thanks - i understand now whats happening - we are running JAMF PRO 10.6, it seems that the state of the out of box protection of the T2 chip is therefore misleading the check the JSS is doing, the drive IS encrypted but FV2 is not on. need to be able to test for those conditions independently, is this something we can do in the native JSS or is it only via additional attributes (as per @analog_kid )

thanks @nick.pierce i got a couple of emails this morning from Jamf as the support team had seen my query and they had advised this was being addressed in the 10.8 release. reading the release notes for the beta i can see that you have patched this which is great news so i will be recommending we update to 10.8 as soon as is practical for us after it is released as a production code.

i do have a follow up query which may be my understanding of the new encryption methods Apple are using for combining the FV2 process with a T2 chip. currently (as i hadn't previously had the work around from the team) i have been modifying the scope of my FV2 JSS policy to force show it to the affected machines - thankfully we haven't had too many yet!

when i run the policy to enable FV2 using the JSS to store with the institutional key it only takes a fraction of a second and working on battery not mains to have the OS report that the disk is fully encrypted. this is unusual as even on a modern SSD it should take a few minutes - i've tested its not just the quantity of data on the disk (assuming the OS is automatically encrypted or not part of the encryption of FV2) as on a machine with c.900GB of user data it took again a fraction of a second to decrypt the drive to allow me to format it.

my question is: is this normal that with the way the T2 chip works you no longer have to sit and wait (forever) for FV2 to secure the data so as soon as you turn FV2 on thats it, everything is secure?

Hi @rframe, T2 machines (thus far) have been encrypted from the factory which is why turning on FIleVault is so quick. It now amounts to setting up the pre-boot environment and the keys that allow FileVault enabled users to unlock the disk and boot.