Turning on silent BitLocker suppresses the warning that other encryption software is present. The documentation is explicit that this can destroy data.
Silent enablement encrypts a machine without anybody touching it, which is exactly the behavior you want, and getting there means setting a policy that ignores any warning about encryption software already installed. Assessing the estate beforehand is described as critical for avoiding data loss, and that is not marketing caution. The assessment is the project. It runs remotely against your Intune tenant.
- SilentNo user interaction, no local admin rights
- 200 keysEntra ID limit per device, after which it fails
- Self-serviceUsers recover their own keys by default
- AuditedEvery key access logged with the user name
Go and find the other encryption software before deploying any of this.
This is written down as a requirement before deployment rather than as a suggestion, and the risk it names is data loss.
- Find whatever encryption software is already out there, using inventory or discovery, because a silent policy walks straight past the warning that would otherwise have told you. McAfee, Symantec and Check Point are given as examples, and in practice what turns up is usually something inherited from a previous IT provider or acquired along with a company.
- Plan how the existing encryption comes off safely before any BitLocker policy lands. Taking one full disk encryption product away and putting another in its place is a sequence, and the sequence is not negotiable when both products believe they are managing the same volume.
- Pilot it on machines that genuinely represent the estate before going anywhere near a broad rollout, and have the rollback and recovery procedures written before you need them rather than during. All four of these steps are listed explicitly in the documentation, which is unusual, and reflects just how badly this goes when it goes wrong.
- The reason this matters more than usual is that what is being described is data loss, systems becoming unstable and machines failing to boot, on hardware people are using to do their jobs today. A silent policy applied broadly without the assessment first reaches every device simultaneously, and that single property is what makes it both so useful and so dangerous.
Eight things about managing BitLocker that decide whether this rollout is safe or expensive.
The data loss risk in silent enablement, in the documentation own words
Silent BitLocker only works if you disable the warning about other disk encryption, and disabling it means BitLocker carries on even when it can see another product already encrypting the volume. The named consequences are data lost to conflicting encryption methods, systems becoming unstable and failing to boot, and recovery scenarios complicated by two layers of encryption sitting on top of one another. Assessing the estate first is called critical for avoiding data loss, and that is an accurate description.
Silent enablement has six specific prerequisites
Windows 10 build 1803 or later where the person is an administrator, 1809 or later where they are a standard user, or any Windows 11. The device must be joined to Entra either directly or in hybrid, carry a Trusted Platform Module at version 1.2 or above, run in native UEFI mode with Secure Boot on, and have the recovery environment configured and reachable. Miss any single one of those and the device does not encrypt silently, and nothing tells you.
A security baseline can silently block the whole thing
There is a specific warning that the Defender security baseline can switch on a startup PIN and key by default, and because both require somebody to type something, silent enablement is blocked outright. Checking the baselines for that conflict is the step everybody skips, and it produces the most bewildering symptom in this entire subject: the policy applies cleanly, nothing at all encrypts, and no error appears anywhere.
The 200 key limit, which fails encryption entirely
Entra will hold at most two hundred recovery keys for any one device, and once that ceiling is reached silent encryption simply fails, because backing up the key fails before encryption ever begins. A machine rebuilt and re-encrypted many times across several years can genuinely reach that number, and the symptom gives no hint whatsoever that a key count is involved.
Self-service recovery, which is on by default
People can get their own recovery keys through the Company Portal app, through the account portal where the device is joined to Entra, and through Entra itself. The tenant-wide setting that would stop non-administrators seeing their own keys defaults to off, so self-service is permitted unless somebody changed it. That is usually the right position, and it is worth knowing it arrived as a default rather than as a decision anybody made.
Recovery keys are corporate resources under Conditional Access
Recovery keys are treated as company resources and fall under Conditional Access, so a policy demanding a compliant device will stop a non-compliant one retrieving them. Every retrieval is also written to the audit log under key management, recorded as reading a BitLocker key, along with who did it and which key it was.
Key rotation, with its own set of prerequisites
There is a remote action that rotates a device recovery key. It needs Windows 10 build 1909 or later, or Windows 11, with client-driven password rotation enabled in policy, saving recovery information to Entra switched on, and storing that information before BitLocker is enabled set to required. Configuring automatic rotation at the same time is worth the ten minutes.
Personal Data Encryption, which is not a BitLocker replacement
On Windows 11 22H2 and later there is a second mechanism that encrypts individual files rather than whole volumes, and it runs alongside BitLocker rather than replacing it. What distinguishes it is when the keys are released. BitLocker releases its keys at boot. This one holds them until the person signs in with Windows Hello for Business.
Four things that stop an encryption rollout turning into an incident of its own.
We inventory existing encryption before anything is deployed
Because a silent policy walks past the warning about other encryption software, and the named consequences of a conflict are data loss, unstable systems and machines that will not boot. Finding what is actually installed across the estate, and removing it in the correct order, is the bulk of the work in any environment with a history behind it.
We check the six prerequisites across the estate first
The operating system build set against whether the person is an administrator, the Entra join state, the Trusted Platform Module version, native UEFI mode, Secure Boot, and whether the recovery environment is configured. A device short of any one of those simply does not encrypt silently, and it does not tell anybody it has not. Checking first converts a mysterious partial result into a known list of things to fix.
We go looking for the baseline conflict that costs people weeks
The Defender security baseline can enable a startup PIN and key by default, and that blocks silent enablement outright. It produces the single most confusing symptom in this whole area: the policy applies, everything on screen looks correct, and not one machine encrypts. We check for it as a routine step at the start rather than reaching it as a diagnosis three weeks in.
We design recovery before we encrypt anything
Who can see keys, who can rotate them, whether people can retrieve their own, whether Conditional Access gates retrieval at all, and who ever reads the audit log of who accessed what. Encryption without a tested recovery path is precisely how a locked laptop becomes a lost laptop, and the morning it matters is not the morning to start working out who holds the right permission.
Six US situations where disk encryption needs managing properly.
A business asked to evidence device encryption
A SOC 2 auditor, an insurance questionnaire, a security review from a large customer and a HIPAA risk analysis all converge on the same question. What proportion of your devices are encrypted, and can you demonstrate it. The encryption report in Intune answers that across every managed device. Asserting that the laptops came encrypted from the manufacturer is not evidence, and it is accepted as evidence less often every year.
A business that has just lost a laptop
The question is immediate and specific: was that device encrypted, and can we prove it. Most state breach notification laws exempt properly encrypted data, and HIPAA breach notification guidance treats encryption consistent with the published standards as a safe harbor. If the device was encrypted and you can show it, the incident is largely closed. If nobody can say, it becomes a breach assessment with notification questions attached.
A workforce where an instruction to encrypt would simply be ignored
Silent enablement exists for exactly this situation: encryption that happens automatically, with nobody interacting and nobody needing administrative rights on the machine. Any approach depending on people carrying out a step produces partial coverage, and partial coverage is the state that reads perfectly well on a policy document and fails on the one specific laptop that ends up left in an airport.
An estate with encryption software inherited from a previous provider
Some full disk encryption product installed years ago, quite possibly no longer licensed and quite possibly no longer supported by anybody. This is the environment where silent BitLocker is at its most dangerous, because the policy suppresses precisely the warning that would have saved you. Assessing and removing it is the project. The BitLocker half is the easy part.
A contractor handling CUI under NIST 800-171 or CMMC
Defense supply chain contractors have to protect controlled unclassified information on endpoints, and an assessor will ask how encryption is enforced and evidenced rather than whether a policy says it should be. Centrally managed BitLocker with escrowed keys, audited access and an encryption report is an answer an assessor can verify.
A business wanting protection beyond boot
BitLocker releases its keys at boot, which means a running unlocked machine is a running unlocked machine. Personal Data Encryption on Windows 11 22H2 or later encrypts files and does not release keys until the user signs in with Windows Hello for Business, layered alongside BitLocker rather than replacing it. For higher risk populations that difference is meaningful.
How Windows disk encryption is actually managed in US businesses.
| Feature | Managed through Intune | Encrypted, keys uncertain | Not encrypted |
|---|---|---|---|
Devices encrypted consistently | Yes | Partly | No |
Encryption applied without user action | Yes | No | Not applicable |
Recovery keys escrowed centrally | Yes | Uncertain | Not applicable |
Users can self-serve a recovery key | Yes | No | Not applicable |
Key access audited with the user name | Yes | No | Not applicable |
Keys rotatable remotely | Yes | No | Not applicable |
Encryption status reportable | Yes | Partly | No |
Conditional Access protects key retrieval | Possible | No | Not applicable |
Evidence for an auditor or insurer | Strong | Weak | None |
Lost laptop is a closed incident | Usually | Unprovable | No |
Six conditions, and a device failing any one of them will not encrypt at all.
Requirement
Operating system, administrator users
- Detail
- Windows 10 version 1803 or later, or Windows 11
Requirement
Operating system, standard users
- Detail
- Windows 10 version 1809 or later, or Windows 11
Requirement
Device identity
- Detail
- Microsoft Entra joined or Microsoft Entra hybrid joined
Requirement
Trusted Platform Module
- Detail
- Version 1.2 or later
Requirement
Firmware mode
- Detail
- Native UEFI BIOS mode
Requirement
Secure Boot
- Detail
- Enabled
Requirement
Recovery environment
- Detail
- Windows Recovery Environment configured and available
Requirement
TPM startup authentication
- Detail
- Must not demand a startup PIN or key, since both require somebody to be sitting there
Requirement
Policy type
- Detail
- Either endpoint security or device configuration. The settings catalog does not carry the TPM controls this needs.
Five steps, and the assessment is the long one.
- 1
Inventory existing encryption and device readiness
Every device with third-party encryption software installed, and every device against the six silent enablement prerequisites: operating system version, Entra join state, Trusted Platform Module version, UEFI mode, Secure Boot and the Windows Recovery Environment. Both lists determine what is achievable and in what order.
- 2
Remove conflicting encryption in a controlled sequence
Safely, on a schedule, with a rollback path, before any silent policy reaches those devices. Microsoft frames this as critical for avoiding data loss because silent policies suppress the warning that would otherwise stop encryption proceeding on a conflicted device.
- 3
Configure the policy in the right place
Endpoint security disk encryption policy or a device configuration endpoint protection profile, not Settings Catalog, which Microsoft states does not include the TPM startup authentication controls required for reliable silent enablement. Then the TPM settings that prevent a startup PIN or key being required, and a check for the Defender baseline conflict.
- 4
Set up recovery and permissions
Keys escrowed to Entra, self-service retrieval through the Company Portal and the account portal, the Intune permissions needed to rotate a key alongside the separate Entra permissions needed to read one, the rotation policy settings, and a deliberate decision on whether Conditional Access should stand in front of key retrieval at all.
- 5
Pilot, then deploy in waves, then report
A pilot group that genuinely represents the estate first, then widening outward, with the encryption report open throughout. That report is also what you keep afterward, because it answers both the auditor question and the missing laptop question without anybody having to go and investigate anything.
What US businesses ask about BitLocker management.
Fifteen questions worth answering first.
The assessment
- Is any third-party encryption software installed?Silent policies bypass the warning about it.
- Do you have inventory data to answer that reliably?Microsoft suggests device inventory reports.
- Is there a plan to remove it safely?Order matters, and it is not optional.
- Which devices form the pilot group?Representative, not just the IT team.
- Is there a rollback and recovery procedure?Prepared before deployment, not during.
Readiness
- Do devices meet all six silent prerequisites?Missing one means silent enablement will not happen.
- Does a security baseline enable a TPM startup PIN?The Defender baseline can, and it blocks silent enablement.
- Are you using Settings Catalog for this?It lacks the TPM controls silent enablement needs.
- Are users administrators or standard users?It changes the minimum Windows version.
- Are any devices still on Windows 10?End of support was October 14, 2025.
Recovery
- Can users retrieve their own keys?The default tenant setting allows it.
- Who in IT can view and rotate keys?Specific Intune and Entra permissions are required.
- Is key rotation configured?It has its own policy prerequisites.
- Does anybody review the key access audit log?Every access is logged with the user name.
- Does your device deletion process consider BitLocker?Deleting the Intune object suspends BitLocker.
The pages around this one.
Microsoft Intune
The platform all of this is configured from, covering endpoint security policy, device configuration and the reporting.
Endpoint security
The wider endpoint protection stack that encryption is one layer of.
Endpoint DLP
The data-level control that governs what leaves an encrypted device while it is unlocked and in use.
Go and open the encryption report, then look at what is genuinely encrypted.
It sits under devices, then monitor, and it covers every managed machine. The distance between what a company believes is encrypted and what that report actually shows is usually what starts this whole project, and finding it takes about five minutes.
Related Services
Explore more solutions that work great with this service
Microsoft Intune
Device management and endpoint security
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Defender
Advanced endpoint and email threat protection
Learn moreMicrosoft Purview Endpoint DLP
Endpoint data loss prevention for US organizations: device onboarding
Learn moreTenant Security Baseline
Documented controls mapped to CIS
Learn moreIT Compliance
HIPAA, SOC 2, NIST, CMMC, CCPA readiness
Learn more