Frequently Asked Questions (FAQ)

To migrate from a third-party encryption tool to Endpoint Central BitLocker Management, follow these steps:

1. Prepare the endpoints
   • Ensure the Endpoint Central agent is installed on all target machines.
   • Confirm that BitLocker Management is enabled on these agents.
2. Verify recovery key backup
   • Navigate to Managed Computers and search for the device.
   • Confirm that a usable recovery password can be retrieved and matched to the drive’s recovery identifier. An identifier alone does not prove successful backup.
3. Remove third-party encryption agent
   • Coordinate removal of the existing encryption-management agent with its administrator. Confirm the supported migration and coexistence procedure before uninstalling it.
4. Deploy Endpoint Central BitLocker policy
   • Create and deploy a BitLocker policy from Endpoint Central.
   • Compare the intended policy with the drive’s current encryption level, method and protectors. Matching settings can be retained; incompatible settings can require decryption and re-encryption.

Important: If the third-party tool supports exporting recovery keys, export and securely store them before starting the migration to prevent data loss.

Before changing encryption management, securely back up a usable recovery password and match it to the drive’s recovery identifier. An identifier alone is not proof that the password was stored. Review the existing encryption method, full/used-space setting and protectors against the intended policy. Matching settings can be retained; incompatible settings can trigger decryption and re-encryption. Do not assume that every pre-encrypted device will always be adopted unchanged, or always be decrypted.

Coordinate the policy transition with the administrator of the existing tool. Confirm the supported coexistence or migration procedure for your product and build. Test it on a pilot computer before applying it broadly.

For a pilot migration, record the current encryption method, full/used-space level, OS-drive protector and a usable recovery-password backup before assigning the new policy. After deployment, verify the same drive’s conversion, protection and retrievable recovery data. Investigate a mismatch before expanding the rollout. Coordinate policy ownership with the other tool’s administrator; a compatible encryption configuration does not by itself establish supported coexistence with every management product.

BitLocker Management License

BitLocker Management is available as part of the Security Edition or as a Security Add-on for the other editions. Before deploying BitLocker, verify your license entitlement and contact endpointcentral-support@manageengine.com for more information.

User Permissions

Verify the BitLocker Manager role or permission is assigned to your user account (Admin → Users → select your user → BitLocker Manager permission). If the BitLocker Management tab is not visible in the console, this is typically due to missing license entitlement or missing role assignment.

Supported Platforms

BitLocker Management is a Windows-only feature and does not extend to Linux, macOS, or other operating systems. For Linux device encryption visibility, refer to standard Inventory reports (Admin > Reports > Inventory Reports > Disk Encryption).

The BitLocker Management module is available as part of the Security Edition or as a Security Add-on for the other editions such as Professional, Enterprise, and UEM Edition. Learn More .

To check your license status, click on the Profile icon on the right top corner of the console and select License and verify the BitLocker Management entitlement.

If not licensed, you can purchase the BitLocker Management module by contacting support. Once purchased, the module will be enabled during the next agent refresh cycle (90 minutes).

Endpoint Security uses a shared add-on enablement workflow. When the console offers a trial, review its license type and expiry details. The activation controls and the managed-computer list serve different purposes. For selected-computer management, also check that the intended computers are in the add-on managed scope.

Use the trial information shown for your account to check expiry. A visible enablement option alone does not establish a new trial period or permanent entitlement. If the displayed trial state conflicts with your expected entitlement, contact endpointcentral-support@manageengine.com.

Any changes to encryption settings create a difference between the new policy and the old policy. This causes all machines under the policy to decrypt and re-encrypt with the new settings. Changes only to advanced settings, such as recovery key rotation or backup in the domain controller, are applied without decryption and re-encryption.

When TPM is not detected, the Endpoint Central agent assumes no TPM and applies encryption settings for machines without TPM. When the failure is resolved and TPM is detected, the machine is decrypted and encryption settings for TPM machines are applied.

For non-TPM machines, encryption requires a passphrase. Only after the password is provided will encryption begin.

A single policy is sufficient for both TPM and non-TPM machines.

BitLocker keys are tied to the TPM (Trusted Platform Module). When you change the motherboard, you will typically change the TPM as well. Review these effects:

1. Windows Auto-Detection: Windows automatically detects the new TPM during startup and re-establishes protection with the new TPM.
2. Agent Reinstallation: If you're changing the motherboard, you should reinstall the Endpoint Central agent on that machine.
3. Other Hardware Changes: For other hardware replacements (RAM, hard drive, etc.), you do not need to reinstall the agent.
4. Recovery Key: After the motherboard change, ensure you retrieve the recovery key from the console and store it securely. This is important if BitLocker protection is interrupted during the TPM transition.
5. Manual Intervention: You don't need to manually add or regenerate a TPM protector unless the existing one fails to bind after the new TPM is detected.

Best Practice: After a motherboard replacement, verify that BitLocker protection is active by checking the protection status in the console.

The policy is removed from the machines but encryption remains. Machines are not decrypted on policy removal.

The last deployed policy takes effect. The active policy can be checked in the managed systems view.

If the new policy’s encryption settings differ from the current settings, the new policy is enforced.

Before changing encryption management, securely back up a usable recovery password and match it to the drive’s recovery identifier. An identifier alone is not proof that the password was stored. Review the existing encryption method, full/used-space setting and protectors against the intended policy. Matching settings can be retained; incompatible settings can trigger decryption and re-encryption. Do not assume that every pre-encrypted device will always be adopted unchanged, or always be decrypted.

BitLocker enforces encryption status changes only on machines where a BitLocker policy is applied.

The policy is revoked but encryption stays. The machine is not decrypted.

To remove a fully decrypted computer and prevent encryption prompts:

• Remove the target machine from the custom group (Admin → Custom Group).
• Modify the existing BitLocker policy by re-attaching the custom group and re-deploying the policy.

Encrypted data drives are decrypted. The computer remains partially encrypted.

Modifying encryption settings triggers re-encryption of the drives.

Endpoint Central will not encrypt drives without a deployed policy. Full encryption can occur due to:

• Windows Device Encryption during a fresh OS install.
• Third-party software.
• Manual encryption.

No. Windows provides native BitLocker commands, while Endpoint Central BitLocker Management uses its policy creation and deployment workflow. A native command alone does not establish that the product has stored a recovery password or applied the intended policy. Use the documented policy and recovery-verification procedure for product-managed encryption. Confirm any proposed script’s support and recovery handling before using it. See policy creation.

Yes. Log in with the recovery key. After login, the user is prompted to reconfigure or modify the password or PIN.

1. TPM and PIN : 6—20 digits, no continuous sequence of 3+ digits, no repetitive 2-digit sequence.
2. TPM and Enhanced PIN : 6—20 characters, must include 1 uppercase, 1 lowercase, 1 digit, 1 special character; no continuous sequence of 3+ characters, no repetitive 2-character sequence.
3. Passphrase : 8—255 characters, same complexity as enhanced PIN.

Yes. You can configure: Passphrase (for non-TPM devices) AND TPM+PIN (for TPM devices) in the same policy. The console will apply the appropriate method based on each device's TPM availability. You cannot set a static/common PIN for all machines via policy — each machine must set its own PIN during setup (unless configured to skip).

Yes. The agent collects a new PIN or passphrase through a dialog inside Windows. That setup is separate from Windows unlocking the OS drive at startup. TPM+PIN requires the configured PIN at boot. Non-TPM passphrase protection uses the configured Windows passphrase unlock. TPM-only protection does not ask for a PIN.

The agent initiates BitLocker processes during its refresh cycle. Execution time depends on the machine. Encryption begins only after the recovery key is successfully stored on the server.

If a decryption process is stuck at a specific percentage (e.g., 49%), follow these troubleshooting steps:

1. Check Decryption Status: On the affected machine, open Command Prompt as Administrator and run:

   manage-bde -status

   This command displays the current encryption/decryption percentage and status. Take a screenshot of the results.
2. Scan Disk for Errors: Run the following command to scan the drive for errors:

   chkdsk C: /scan

   (Replace C: with the affected drive letter if different)
3. Verify Console Status: In the Endpoint Central console, navigate to BitLocker Management → Managed Computers and check the decryption status and summary for the affected machine.
4. Allow Processing Time: Decryption can take extended time depending on drive size and system performance. The process may appear stuck but is actually running in the background.
5. Restart if Necessary: If the process remains stuck after verifying with manage-bde -status, a restart may help resume the decryption process.
6. Contact Support: If decryption remains stuck after these steps, provide the console summary and manage-bde -status screenshot to support for further diagnosis.

Note: Do not interrupt decryption by restarting the machine unless absolutely necessary, as this may cause data integrity issues.

This message appears when a BitLocker policy is deployed but the agent has not yet initiated the deployment process on the device. This is different from deployment failures — the policy simply hasn't started deploying yet. Follow this checklist to diagnose and resolve the issue.

Verification Steps:

1. Confirm agent is online: Check Scope of Management > Computer view > Last Check-in timestamp
2. Run Agent Troubleshooting Tool: C:\Program Files (x86)\ManageEngine\UEMS_Agent\bin\agent_troubleshooting_tool.exe
   - Verify all checks (Server, RDS Gateway, Notification Server, Agent Service, WMI, Agent Identity, Binaries, Active Directory) are green ("Diagnosis Completed")
3. Run manual config update: C:\Program Files (x86)\ManageEngine\UEMS_Agent\bin\cfgupdate.exe
4. Verify static vs. dynamic group: Policy Deployment page > click group name > confirm group type (Static groups are recommended; confirm dynamic group membership includes the device)
5. Check policy refresh timing: Deploy Immediately was used (does not wait for next 90-minute refresh)
6. Verify single policy: If device is in multiple BitLocker groups, last-deployed policy wins; check Policy Deployment > Device computer view shows only one associated policy

If these checks pass and the status still shows 0/X or "Pending after deployment":

• - This may indicate a backend condition requiring support escalation
• - Collect agent logs: C:\Program Files (x86)\ManageEngine\UEMS_Agent\Logs\
• - Contact ManageEngine support with logs for investigation

If the computer was recently added to or moved between custom groups, confirm its current group membership and security add-on scope. For an existing deployment, select Modify and Deploy Immediately where available, then check status and remarks. See the new-member answer below; immediate deployment does not mean encryption has completed.

No. BitLocker can be enabled and policies deployed at any time.

When a drive is in suspend protection mode it is encrypted but not protected. To check, go to the Endpoint Central web console, navigate to BitLocker management, find the computer under Managed Computers, and verify if Protection Status is "Disabled".

If the user manually protects data drives and a BitLocker policy is later deployed, the protector changes to "Auto Unlock".

A restart is not required for every deployment. Encryption can start in the background after the required authentication and recovery-key storage checks succeed. If Windows has not started OS-drive conversion, the agent can show a restart prompt. Follow that prompt and recheck the drive’s encryption status. TPM availability alone does not determine whether a restart is needed.

Applying both simultaneously may cause conflicts. It is not recommended.

The policy defines product-managed encryption behavior. Do not treat a successful deployment as proof that every Windows BitLocker action is blocked. Review the user’s Windows privileges and applicable Windows/MDM/GPO settings separately. For an administrator-requested decryption, use the single-computer decryption procedure and verify the resulting drive status.

To disassociate a BitLocker policy from a machine:

1. Navigate to Admin → Custom Group.
2. Edit the relevant custom group and remove the target computer.

To decrypt drives using BitLocker management:

1. Go to BitLocker Management → Policy Creation → Create Policy. Enter a name (and description, if needed).
2. Ensure the Drive Encryption option is disabled. When disabled, all drives will be decrypted.
3. Save and publish the policy. Deploy it to the target machines.

Create and publish a decryption policy with Drive Encryption disabled. Associate it with a computer group containing only the intended target, check for overlapping policies, and choose Deploy Immediately where available. Confirm the target’s reported conversion status afterward. Immediate deployment requires communication and does not mean decryption finishes immediately. Removing an encryption policy alone does not decrypt the computer.

If BitLocker policy successfully applies to existing devices but newly added or newly imaged machines are not receiving the policy, follow this troubleshooting checklist in order.

1. Confirm that newly imaged laptops are part of the correct Active Directory OUs and groups where the policy is assigned.
2. Search and verify the computer(s) under the Managed Computers view.
3. Check that the Endpoint Central agent on these devices is installed and successfully updating.
4. Ensure that the correct license (Security Edition) is being used.

If the issue persists, contact support .

If the computer was recently added to or moved between custom groups, confirm its current group membership and security add-on scope. For an existing deployment, select Modify and Deploy Immediately where available, then check status and remarks. See the new-member answer below; immediate deployment does not mean encryption has completed.

If a newly added computer has not received the group’s existing policy, confirm its group membership and Endpoint Security managed scope. Open the existing deployment, select Modify, and use Deploy Immediately where available. Check the resulting status and remarks. Normal deployment uses the next agent refresh cycle, normally 90 minutes. Immediate deployment depends on agent communication and applicable batching; it does not guarantee completed encryption.

Check the effective authentication type, whether setup can be postponed, and whether the drive is already protected. TPM-only does not require a PIN. Review password prompt settings and the existing no-policy encryption answer. If a password-based setup remains missing, collect the policy settings, user-session details and diagnostic results for support.

BitLocker supports Windows 7 and above.

The prerequisite-failure view lists computers with reported incompatible prerequisites. It is not a status list of every managed computer. If no records match the selected failure category and scope, the view can be empty. Check the filters and the device’s latest reported status before concluding that every computer passed.

Encryption of portable drives is not supported by Endpoint Central 's BitLocker Management.

BitLocker reports are available in the Reports section of Endpoint Central:

1. Navigate to the Reports tab in the console.
2. Select BitLocker Report or TPM Report.
3. The report displays managed computers, encryption status, protection status, recovery keys, and audit details.
4. To receive automated reports, configure Scheduled Reports to send BitLocker reports via email at regular intervals.

The current status updates during the refresh cycle. On-demand status can be obtained by navigating to Insights → Managed Systems, selecting the machine, and clicking "Update Now" at the top right.

The view does not yet have the corresponding reported data. The normal agent refresh interval is 90 minutes. Update Now requests an on-demand update; successful communication and processing are still required. It does not guarantee a completed scan, component installation or encryption within a fixed number of minutes. If data remains unchanged, record the latest agent contact, component status and remarks before contacting support.

Open BitLocker Management → Insights → Managed Computers and select the computer. The detail view can show BitLocker components are not installed in this system. Data will be available once BitLocker components are installed. This is different from a completed view with no matching rows, or an installed component that has not posted drive data. Check component status and remarks, security add-on scope and agent contact. Follow component troubleshooting. The normal refresh interval is not a guaranteed installation deadline.

Possible reasons:

• License issue: The managed endpoints count mismatch.
• Endpoint Central agent is unavailable, preventing scans.
• Agent-server communication interruptions.
• Server is busy and data is queued; it updates later.
• Windows version is 7 or below.
• BitLocker is disabled via GPO.

Contact support for assistance if these issues occur.

For a limited BitLocker or security add-on license, also check that the computer is included under Admin → Global Settings → Endpoint Security → Manage. Being managed by Endpoint Central or belonging to the policy’s custom group does not by itself establish add-on eligibility. See License Validation.

A page stuck on loading placeholders differs from a completed grid with no matching rows. Reload the page and test another supported browser session. If the failure persists in a fresh session, record the affected page, time, product/build and failed network request or console error. Provide sanitized browser diagnostics to support. Do not treat clearing cache as a guaranteed fix or change encryption policies to repair a display failure.

If the page shows Oops, Something went wrong or a failed blmdrivereports request, record the request time and error. If the failure occurs only in one browser session, clear that session’s cached site data and sign in again. If it also occurs in a fresh session, collect sanitized network/console diagnostics for support. A repeated failure in a fresh session is not explained solely by the browser cache. Do not change drive-encryption policies to repair a display failure.

If the "Encrypt OS Drive Only" option is selected during policy creation, the encryption status is shown as "Partially Encrypted".

Encryption Status and Protection Status are separate. A fully encrypted drive with protection disabled needs a check of suspended protectors, maintenance activity and current Windows state. The field alone does not establish which tool caused the condition. Verify the relevant update workflow and protection state rather than assuming all Endpoint Central operations exclude suspension.

• Windows Device Encryption suspending until the recovery key is backed up.
• Manual suspension.
• Third-party software related to BitLocker.

Deploying the encryption policy through Endpoint Central re-enables BitLocker protection.

To receive automated BitLocker reports, navigate to Scheduled Reports to configure the predefined reports to be sent.

The BitLocker status for Inventory module is only detected through the Inventory scans. The status will only be reflected in the next Inventory scan.

First verify that you are comparing the same computer and drive. Check when that console view last received data and compare it with the current Windows drive status. Review the no-policy encryption answer and whether the agent has communicated since the encryption change. A mismatch can require refreshed data and investigation; it does not prove that manual encryption or a stale inventory scan is the only cause.

Encryption Status and Protection Status are two independent fields in BitLocker reports (Reports -> BitLocker Reports).

Encryption Status shows the encryption completion percentage across all drives on the machine:

• Fully Encrypted (100%): All eligible drives are fully encrypted
• Partially Encrypted (X%): Encryption is in progress; some drives not yet at 100%
• Fully Decrypted (0%): No EC-managed encryption exists, OR no Endpoint Central BitLocker policy has taken ownership yet (drive may still be encrypted via other methods)

Protection Status shows whether BitLocker protection is currently active:

• Enabled: BitLocker protection is active; drive is protected and requires authentication to access
• Disabled: BitLocker protection is not active (administrator suspended it, or protection was never enabled)

These fields are independent — a machine can show any combination:

• Encrypted 100% + Protection Enabled: Normal state — drive is fully encrypted and actively protected
• Encrypted 100% + Protection Disabled: Encryption completed but protection was suspended afterward (may occur during maintenance)
• Decrypted 0% + Protection Disabled: No EC-managed encryption, but the drive may still be encrypted via native Windows BitLocker, Device Encryption, MBAM, or third-party tools. To verify actual encryption: run manage-bde -status (Command Prompt as admin) on the machine. If encrypted, deploy an EC BitLocker policy to bring it under management.

Each row in the BitLocker report represents ONE DRIVE/VOLUME, not one computer. A computer with multiple drives (C:, D:, K:, etc.) will appear as multiple rows in the report. If you have 100 computers with an average of 2-3 drives each, the report may show 200-300rows. To count unique computers, use the Managed Computers grid or filter reports by unique computer names.

Yes. The policy’s Update recovery key to domain controller setting controls AD backup. Verify the backup result for the device and the relevant directory; enabling the option alone does not prove a usable copy is present. See recovery-password backup and retrieval.

If the domain controller is unreachable or permissions prevent updates, the recovery key cannot be stored there.

Yes. BitLocker encrypts drives even if domain controller sync does not occur.

Yes. The Central Server manages all recovery passwords.

See BitLocker Recovery Key Troubleshooting > Recovery Key Not Found in Endpoint Central for step-by-step diagnosis and resolution, including checks for recent asset scans, encryption source verification, and device listing prerequisites.

The classic Inventory → Computer Details → Security → BitLocker view has a separate permission requirement. Its documented recovery-key access requires Full Control on Inventory; Read access alone does not grant access to the secret. For technicians who only need recovery keys, use the BitLocker Management recovery-key permission and the required computer scope instead of granting broad Inventory access. See BitLocker role-based access control.

This message means the server cannot return recovery-password data for the selected record. A recovery identifier may be present while the password is absent. Confirm the computer and volume, use the identifier displayed by Windows, and check the latest agent contact and reported recovery-key state. Request an update and retry after communication succeeds. A locked volume can prevent new endpoint collection; it does not make every previously stored server key unavailable. Follow the recovery-key retrieval checks.

If retrieval still fails, provide the exact error, timestamp, product/build and diagnostic results to support. Do not include the recovery password in screenshots or general logs. See Recovery-key troubleshooting.

For the on-premises password dialog, authenticate as the console user shown in the dialog. Use that account’s password, not the endpoint’s BitLocker PIN, recovery password or an unrelated domain administrator account. Domain-authenticated console users are validated in their login domain; local console users use local console authentication. SAML and cloud sessions use their configured reauthentication flow. Recovery-key permission and access to the selected computer are also required.

Confirm that the displayed username is your current console account and use its password for the applicable login mode. Check the account’s recovery-key permission and computer scope separately. If valid credentials still fail, record the login mode, product/build, timestamp and exact error for support. Do not use a report export to bypass an authentication failure.

Configure a scheduled database backup stored in a safe path. Instructions are here. Recovery keys can be retrieved from the backup files.

See BitLocker Recovery Key Troubleshooting > Device Not Listed in Managed Computers for prerequisites and resolution steps.

If AD is unreachable, BitLocker retries updating the Recovery Key up to five times per day during its refresh cycle until AD becomes reachable.

If the recovery key retention is enabled, the recovery key will be retained in the server up to one year even after the machine is removed. On disabling, the recovery key(s) of the removed will be discarded after 30 days. If the machine's agent was uninstalled, but is viewed as greyed out under Scope of Management (SoM) in Agent tab, its recovery key can be retrieved using the machine's name. But if the machine's agent was uninstalled and also removed under SoM, the recovery key can only be retrieved using the recovery key ID. The recovery key ID can be found in the prompted recovery key dialog box.

The BitLocker-protected drive can be unlocked by providing the PIN or passphrase. If you forget the unlock password, it can be unlocked by entering the recovery key.

Once the recovery key is viewed in the console, a new recovery key is generated, and the agent will change the recovery key on the next startup.

Under the current workflow, when a new recovery key is generated, it is uploaded to the server. After the server successfully stores the new key, the old recovery key is deleted. This sequence occurs during the agent refresh cycle.

If the agent is offline, it cannot upload the newly generated recovery key to the server due to lack of connectivity. As a result, the existing recovery key remains valid and unchanged. Once the agent reconnects, the rotation process continues during the next refresh cycle, generating and uploading the new recovery key to the server.

First identify the same computer, volume and recovery identifier in each view. Record whether the key was accessed or periodic rotation was configured, whether the computer restarted afterward, and the latest successful agent contact. Compare the server’s recovery-password update information with the current device protector. An Inventory scan is not proof that a key-change operation ran or that a new password was stored. If the expected change is still missing, provide these details and sanitized diagnostics to support. See storage and rotation checks.

When viewing the "Retrieve Recovery Key" page, you may see multiple Recovery Key Identifiers listed for the same drive. This occurs because previously rotated recovery keys are also retained and displayed. The identifier currently shown in the Managed Computers view represents the active recovery key for that drive.

A single drive can have multiple recovery keys associated with it. All recovery keys displayed in the Managed Computers view are valid and can be used to unlock the drive.

When unlocking a drive, Windows prompts with the Recovery Key Identifier. This identifier can be used to retrieve the corresponding recovery key in the console.

In standard scenarios, the BitLocker add-on generates one recovery key per drive. Multiple keys may appear if additional keys were created due to manual interruptions during encryption or as a result of third-party software interactions.

If the recovery key is prompted at every boot, this is typically due to an environmental or system-related issue rather than the encryption workflow itself. It is recommended that the customer contact Microsoft Support for further assistance, as this behavior is commonly associated with operating system or hardware configuration factors.

A recovery prompt after a change does not establish which tool or event caused it. Verify the recovery identifier and use the matching recovery password through the approved process. Record the device model, Windows and agent/server builds, recent firmware or OS changes, and whether protection is active afterward. Follow unexpected recovery prompt diagnostics. A new encryption policy is not a guaranteed remedy for recurring prompts.

A locked drive can prevent the agent from collecting its numerical recovery password. Check whether the server already has a usable password for the identifier displayed by Windows. An identifier alone is not proof of stored recovery data. If the matching password was not stored, use your confirmed existing backup and investigate collection/communication. See retrieval checks. Review drive lock status under Managed Computers and select the computer.

Encryption percentage, recovery identifier and stored recovery password are different data. Managed encryption checks server recovery-password storage before starting encryption. A missing identifier in a view does not establish that the drive must reach 100% first. Confirm the computer, volume and last reported data, then check whether a matching recovery password can be retrieved. See recovery data and retrieval checks.

1. Verify that the correct recovery key is being entered. The Recovery Key ID (RKI) displayed on the locked drive must match the key retrieved from the management console.
2. If the correct recovery key still does not work, the issue is not related to Endpoint Central ’s BitLocker management. BitLocker operations rely on Windows APIs to initiate encryption and decryption, so the problem is likely specific to the affected machine.

If the agent has been reinstalled, the machine will be listed under Managed Computers. You can get the recovery key identifier for the specific machine and retrieve the recovery key through Retrieve Recovery Key tab.