Microsoft
MicrosoftThere's one major shortcoming in both Intune and ConfigMgr based BitLocker management, as I understand them: Non-repudiation. With MBAM, the check-in status of each device is stored indefinitely (unless you manually run the cleanup tool). This means that a device that is lost, but not reported for a long time, can still be proven to have been encrypted last time it was online.
As I understand it (and I know more about ConfigMgr than Intune on this topic).. with both ConfigMgr and Intune, when the device record ages out for inactivity, the history data goes with it. So you cannot prove that a device that was lost but last checked in many months before it was reported lost was encrypted when it last checked in. This leaves you open to extra fines or legal issues in some environments (HIPAA and some gov sectors). Is there a solution for this in Intune or ConfigMgr now?
The solution some of my clients need is exactly as above:
Step 1: A device is offline for a long time, and ages out of ConfigMgr/Intune/AD (through manual or automatic processes, many clients want to expunge stale ConfigMgr clients to prevent them from impacting patch compliance #s)
Step 2: The user reports the device lost
Step 3: To ensure that sensitive data (for example: HIPAA health records/PII) cannot be accessed by an unauthorized user, the Data at Rest encryption must be proven to have been in place
Step 4: Currently, we can pull the MBAM report for this device, regardless of how long it has been since it checked in, but the ConfigMgr based reports and the Intune based reports don't have this data if there is no longer a computer record for the system in question.
