BitLocker practical guide — recovery key management से drive encryption

«PC reset किया, अगले boot पर कभी न देखा नीला screen आया और 48 अंकों की key माँगी।» «BIOS update भर किया तो recovery key input screen आ गई। ऐसी key सौंपी नहीं गई।» «नए PC की settings देखी तो «Device encryption» स्वयं on था। Business apps धीमे लगेंगे, काट दें?» — पिछले लगभग एक वर्ष में ग्राहकों से इस तरह परामर्श स्पष्ट बढ़े हैं।

पृष्ठभूमि साफ़ है। Windows 11 version 24H2 के बाद clean-install PCs पर «Device encryption» (BitLocker का अपने आप enable होना) default से चलता है। Hardware आवश्यकताएँ भी ढीली हुईं, पात्र PCs का दायरा बहुत बढ़ा। यानी BitLocker अब «बड़ी कंपनियाँ जान-बूझकर लगाती हैं» नहीं, «SME के PCs पर चुपचाप आ जाता है» बन गया। तब एकमात्र lifeline recovery key है, और वह किसी के management में न हो जबकि encryption अकेले आगे बढ़े — यही सबसे खतरनाक अवस्था है।

यह लेख SMEs के information-systems कर्मियों और managers, तथा business apps और equipment PCs सँभालने वाले developers के लिए है। BitLocker को «काटने की चीज़» नहीं, «सही इस्तेमाल की चीज़» के रूप में व्यवस्थित करता है। Edition-दर अंतर, TPM और key का न्यूनतम mechanism, recovery key store location की decision table, संगठन में enable करना और operations, incident response, और disposal से संबंध तक — अगस्त 2026 तक Microsoft Learn आदि primary sources पर।

1. निष्कर्ष पहले

• BitLocker drive पूरा encrypt करने वाली Windows feature है, खोने-चोरी-अनुचित disposal से data leak रोकती है। Disk निकाल कर दूसरे PC से जोड़ने वाले attack पर भी encrypted हो तो data नहीं पढ़ा जाता।¹
• Full-featured BitLocker Pro/Enterprise/Pro Education/Education पर ही enable होता है। उसका सरल रूप «Device encryption» Home सहित सब editions पर चलता है।¹
• Windows 11 24H2 के बाद automatic Device encryption की आवश्यकताएँ ढीली हुईं। HSTI/Modern Standby और «unauthorized DMA interfaces न हों» हटाए गए; clean install के बाद OOBE (initial setup) पूरा होते TPM+UEFI Secure Boot पूरी कई PCs पर encryption default से आरंभ होता है।²
• Encryption «शुरू» और protection «enable» अलग हैं। Microsoft account, Entra ID, या (recovery policy configure) AD DS में recovery key backup सफल होने तक protection enable (armed) नहीं होती। कहीं backup न होने वाले केवल-local-account PCs encrypted होने पर भी unprotected रहते हैं।¹²
• Recovery key (48 अंकों का recovery password) का store location Entra ID / AD DS / Microsoft account / print-file — चार विकल्प हैं। Entra ID join हो तो Entra ID, AD domain join हो तो AD DS, दोनों न हों तो admin के Microsoft account — यही default flow है।¹³
• Recovery key माँगना केवल असामान्य समय नहीं। Firmware update, Secure Boot settings बदलना, TPM clear करना, motherboard बदलना, drive दूसरी मशीन पर ले जाना — boot environment का कोई भी बदलाव trigger बन सकता है। नियोजित काम से पहले protection suspension (suspend) का नियम है।³
• Default encryption method XTS-AES 128-bit है। Method बाद में बदलने को decrypt→re-encrypt चाहिए, इसलिए पहली बार में तय कर लें। नई drive पर «used space only encrypt» से पहली encryption का समय बहुत घटता है।⁴⁵
• Recovery key माँगी जाए और न दे सकें तो उस PC का data छोड़ना पड़ता है। Microsoft Support भी खोई key नहीं निकाल सकता। इसलिए इस लेख का विषय «encrypt करें या न करें» नहीं, «recovery key कहाँ रखें और कौन निकाले» है।⁶

Diagram में solid line हमेशा लागू रहने वाला relation दिखाती है और dashed line conditional relation दिखाती है (शर्तें detail page पर हर relation के explanation में दी गई हैं)। Relations की पूरी list (कुल 48, evidence और certainty सहित) तथा मुख्य concepts की definitions knowledge map की detail page पर संकलित हैं (जापानी में)। Data: JSON-LD / Turtle

2. BitLocker और Device encryption का अंतर — edition से क्या चलता है

पहले शब्द साफ़ करें। «BitLocker» और «Device encryption» एक ही encryption तकनीक के दो चेहरे हैं।

• BitLocker (full feature): Drive-दर enable, TPM+PIN और startup key जैसी authentication methods, Group Policy/Intune से control, manage-bde.exe और PowerShell से management तक — admin-oriented रूप।
• Device encryption: आवश्यकताएँ पूरी PC पर BitLocker अपने आप enable करने का mechanism। Settings app में «Device encryption» switch आता है, केवल OS drive और internal fixed drives encrypt करता है (external/USB drives बाहर)।¹

Edition-दर support इस प्रकार है।¹

Windows 11 24H2 में क्या बदला

Automatic Device encryption पहले से था, पर लक्ष्य «Modern Standby या HSTI compliant», «बाहर से DMA-access ports न हों» जैसी शर्तें पूरी अपेक्षाकृत नई mobile PCs केंद्रित थीं। Windows 11 version 24H2 ने ये दो आवश्यकताएँ हटाईं, बची मुख्य शर्तें «TPM (1.2 या 2.0) लगा», «UEFI Secure Boot enable» आदि रह गईं। OEM का unauthorized DMA bus registry (AllowedBuses) में दर्ज करना भी अनावश्यक, यह key 24H2 के बाद ignore होती है। यह ढील Windows IoT editions पर लागू नहीं।²

फलस्वरूप clean install (reset-re-setup सहित) के बाद OOBE पूरा होते सामान्य desktop PCs पर भी encryption default से आरंभ होता है। यहाँ «आरंभ» और «protection enable» का अंतर महत्वपूर्ण है।

• OOBE पूरा होते drive clear key (unprotected temporary key) से encrypted है। Explorer warning icon दिखाता है।¹
• Microsoft account या Entra ID account से sign-in, या domain-joined PC पर (recovery policy configure) AD DS backup सफल हो तो TPM protector बनता है और clear key हटती है। तभी protection active होती है।¹²
• केवल local account से चला PC encrypted होने पर भी unprotected रहता है।¹

यह flow diagram में इस प्रकार है।

flowchart TB
    A["Clean install / reset<br/>(Windows 11 24H2 के बाद)"] --> B{"TPM+UEFI Secure Boot आदि<br/>आवश्यकताएँ पूरी हैं?"}
    B -- "नहीं" --> Z["Encrypt नहीं होता"]
    B -- "हाँ" --> C["OOBE पूरा होते encryption आरंभ<br/>(Clear key = unprotected temporary key)"]
    C --> D{"Recovery key का<br/>backup location?"}
    D -- "Microsoft account / Entra ID /<br/>AD DS (recovery policy configure)" --> E["Recovery key backup सफल"]
    E --> F["TPM protector बनता · clear key हटती<br/>= Protection enable (armed) होती है"]
    D -- "केवल local account<br/>(backup location नहीं)" --> G["Encrypted रहते protection disable<br/>(warning icon दिखता है)"]

«पता चला encrypted था» का असली रूप यही mechanism है। Windows 10 support समाप्ति के लिए Windows 11 PCs बदल रहे संगठन (Windows 10 support समाप्ति का निर्णय) नए PCs शुरू से इसी अवस्था में आने मानकर recovery key management kitting प्रक्रिया में बाँधें।

अपनी मशीन की स्थिति System Information (msinfo32.exe) admin के रूप में खोलकर «Device Encryption Support» पंक्ति से जाँचें। «Meets prerequisites» हो तो पात्र है।¹

3. Mechanism का न्यूनतम — TPM और key का संबंध

BitLocker की key बचाता TPM (Trusted Platform Module) है। TPM OS offline रहते device छेड़ा न गया पुष्टि करता है, boot-time check पास हो तभी encryption key प्रयोग योग्य बनाता है। इसलिए valid Windows सामान्य boot हो तो user कुछ न डाले, disk अकेली निकालें तो न पढ़े — यह दोनों साथ चलते हैं।¹ TPM स्वयं का mechanism (key बाहर न निकालने की structure, PCR, measured boot) «Windows TPM क्या है» में illustrated है।

हर boot पर क्या होता है, diagram में इस प्रकार।

flowchart TB
    ON["Power on"] --> M["TPM boot environment मापता है<br/>(Firmware, boot config आदि)"]
    M --> Q{"माप परिणाम<br/>हमेशा जैसा है?"}
    Q -- "समान" --> UN["TPM encryption key छोड़ता है"]
    UN --> BOOT["सामान्य boot<br/>(User कुछ नहीं डालता)"]
    Q -- "भिन्न" --> REC["Recovery mode<br/>48 अंकों की recovery key माँग"]
    REC --> K1["Recovery key डाल सकें तो boot"]
    REC --> K2["न डाल सकें तो<br/>Data नहीं निकलता"]

TPM के साथ boot पर PIN डालना या startup key (USB में key फ़ाइल) लगाना अनिवार्य multi-factor config भी चुन सकते हैं। TPM-रहित PC पर भी startup-key method से OS drive encrypt हो सकता है, पर password method में lockout नहीं और brute-force कमज़ोर, इसलिए default से disable है।¹

Recovery key कब माँगी जाती है

TPM «boot environment हमेशा जैसा है?» देखता है, इसलिए environment बदले तो valid owner भी recovery mode में जाता है। Microsoft के प्रतिनिधि triggers ये हैं।³

• BIOS/UEFI firmware update जैसे early boot component का update
• TPM बंद-disable-clear किया, या TPM self-test विफल
• TPM validation profile के PCR (Platform Configuration Registers) बदलना — Secure Boot settings बदलना यहाँ लगता है
• Motherboard बदलना (नए TPM से बदलना)
• BitLocker-protected drive दूसरे PC पर ले जाना
• Docking station लगाना-उतारना, NTFS partition table बदलना, boot manager बदलना, PXE boot
• PIN बार-बार गलत, (TPM 1.2 मशीन पर) boot device क्रम बदलना

यानी «BIOS update पर recovery key माँगी» खराबी या attack नहीं, design के अनुसार व्यवहार है। नियोजित काम (firmware update या hardware बदलना) से पहले protection suspend करें — suspension में भी drive encrypted रहता है, काम बाद recovery key बिना फिर चला सकते हैं। Default से reboot पर protection अपने आप फिर चलती है (reboot संख्या निर्दिष्ट भी हो सकती है)।³

# Firmware update से पहले suspend करें। Default से एक reboot पर protection अपने आप फिर चलती है,
# इसलिए कई बार reboot करने वाले updates में दूसरा और बाद के reboots recovery screen पर
# रुक सकते हैं।
# -RebootCount 0 अपने आप फिर चलाना रोकता है; काम पूरा होने के बाद फिर चलाना प्रक्रिया में बाँधें
Suspend-BitLocker -MountPoint C: -RebootCount 0
# काम बाद अवश्य फिर चलाएँ (-RebootCount 0 में अपने आप फिर नहीं चलती, इसलिए यह चरण अनिवार्य)
Resume-BitLocker -MountPoint C:

शब्दावली पर। Technical documents 48 अंकों को «recovery password», USB पर .bek फ़ाइल को «recovery key» अलग कहते हैं³, पर सामान्य screen और इस लेख में व्यापक प्रचलित नाम के अनुसार 48 अंकों को «recovery key» कहते हैं।

4. Recovery key store location की decision table — चार विकल्प कैसे चुनें

यह लेख का केंद्र है। Recovery key का store location practical रूप से चार विकल्प, PC के sign-in रूप से लगभग अपने आप तय होता है। पहले decision table।

Hybrid join (AD और Entra ID दोनों) devices पर recovery password दोनों में backup होता है।⁴

संगठन के रूप में तीन points।

1. «संगठन का store location» एक तय करें। Entra ID join आगे हो तो Entra ID, on-premises AD हो तो AD DS। कंपनी PC की recovery key कर्मी के व्यक्तिगत Microsoft account में हो तो इस्तीफ़ा-स्थानांतरण पर तुरंत टूट जाता है।
2. AD DS «अपने आप चला आता है» न मानें। AD DS backup को policy configuration (बाद में) पूर्वापेक्षा है। Active Directory recovery password इतिहास रखता रहता है, पुरानी key computer object हटाए बिना अपने आप नहीं मिटती।³
3. फ़ाइल संग्रह चुनें तो स्थान कठोर रखें। Recovery key फ़ाइल उसी PC के अलावा (network folder आदि) रखनी चाहिए।⁵ Key रखने वाला drive का पूरा data पढ़ सकता है, इसलिए protected PC से अलग रखें और access control करना अनिवार्य है।³

अभी अपना PC कैसा है, जाँचें

Admin rights वाले terminal से इनमें से एक चलाएँ।⁵

# PowerShell: Encryption अवस्था और protector के types जाँचें
Get-BitLockerVolume C: | Format-List
# Recovery password (48 अंक) और उसकी ID जाँचें
(Get-BitLockerVolume -MountPoint C).KeyProtector

:: Command Prompt: Status जाँच
manage-bde -status
:: Protectors (TPM, recovery password आदि) की list और 48 अंकों का मान
manage-bde -protectors -get C:

manage-bde -protectors -get C: output में «Numerical Password» के रूप में दिखने वाले 48 अंक recovery key हैं; साथ दिखती ID के पहले 8 अंक recovery screen पर «कौन सी key» मिलाते संकेत हैं।⁶

पहले से encrypted PC का recovery password बाद में Entra ID या AD DS में backup भी कर सकते हैं।⁵

# पहले recovery password की ID जाँचकर फिर चलाएँ
# Entra ID में backup
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"
# AD DS में backup
Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId "{ID}"

:: manage-bde के मामले में
manage-bde -protectors -aadbackup C: -id {ID}
manage-bde -protectors -adbackup C: -id {ID}

«सब PCs की recovery key संगठन के संग्रह में हैं?» की list IPA के SME guideline वाली information security मूल कार्रवाई जैसी है — एक बार कर खत्म नहीं, inventory operations पर चढ़ाने वाली («SME security, कहाँ से शुरू करें»)।

5. संगठन में enable करना और operations — policy, commands, encryption method

5.1. Policy से «recovery key बिना enable» मना करें

BitLocker settings Group Policy (GPO) और MDM (Intune आदि का BitLocker CSP) दोनों से configure हो सकती है।⁴ Recovery key management की दृष्टि से सबसे महत्वपूर्ण policy «Choose how BitLocker-protected operating system drives can be recovered» है। यहाँ ये configure करें।⁴³

• Save BitLocker recovery information to AD DS (केवल recovery password, या key package सहित)
• «Do not enable BitLocker until recovery information is stored in AD DS» सक्षम करें — backup सफल न हो तो encryption शुरू न होने दें, incident रोक का केंद्र। इस config में recovery password अपने आप बनता है

Entra ID-joined devices Intune से manage हों तो सोच वही: recovery key backup अनिवार्य कर फिर encryption enable करें। Entra ID पर recovery key Entra admin center, Intune admin center, PowerShell, Microsoft Graph से मिलती हैं, helpdesk को सौंपी भी जा सकती हैं।³

5.2. Encryption method — default XTS-AES 128

Method configure न करें तो BitLocker default XTS-AES 128-bit use करता है। Device encryption भी default XTS-AES 128। Policy «Choose drive encryption method and cipher strength» से XTS-AES 256 आदि बदल सकते हैं, पर Microsoft की recommendation सब drives XTS-AES रखकर key length device performance (और industry regulatory requirement) के अनुसार 128/256 चुनना है।⁴¹

सावधान रहें: पहले से encrypted drive की method बाद में नहीं बदलती। Method या key length बदलने को एक बार decrypt कर re-encrypt चाहिए।¹ «Regulatory requirement से 256-bit चाहिए» जैसी बात हो तो deployment की पहली बार में तय कर लें।

5.3. Used space only encrypt बनाम पूरा drive

Enable करते एक और चुनाव encryption दायरा है। Microsoft का विभाजन स्पष्ट है।⁵

• Used space only encrypt: Data कभी न रखी नई drive के लिए। पहली encryption तेज़
• Encrypt entire drive: पहले से चली drive — data रखा है, हटाई फ़ाइलें रह सकती हैं

कारण: हटाई फ़ाइलों का क्षेत्र file system पर «free space» दिखता है, इसलिए «used space only» उसे encrypt नहीं करता, overwrite होने तक forensic tools से restore हो सकता है।⁵ Kitting तुरंत बाद नई PC पर «used space only» ठीक, चली PC पर बाद में लगाएँ तो पूरा encrypt — practical रूप से इतना याद रखें।

5.4. PowerShell से enable करना

Script deployment का मूल रूप इस प्रकार है।⁵

# 1. पहले recovery password (48 अंक) protector जोड़ें (इस समय encryption शुरू नहीं होती)।
#    Retry से कई recovery passwords रह गए हों तो भी अभी जोड़ी एक को
#    जोड़ने से पहले-बाद की ID अंतर से चुनें
$before = (Get-BitLockerVolume -MountPoint C).KeyProtector.KeyProtectorId
Add-BitLockerKeyProtector -MountPoint C: -RecoveryPasswordProtector | Out-Null
$rpId = (Get-BitLockerVolume -MountPoint C).KeyProtector |
    Where-Object { $_.KeyProtectorType -eq 'RecoveryPassword' -and $_.KeyProtectorId -notin $before } |
    Select-Object -ExpandProperty KeyProtectorId

# 2. जोड़ा recovery password संगठन के store location पर backup करें। असफल हो तो
#    encryption पर न बढ़ें, इसलिए -ErrorAction Stop error पर प्रक्रिया रोकता है
#    (Entra admin center / AD में key दिखने की पुष्टि तक यही चरण)
BackupToAAD-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop
# AD DS हो तो: Backup-BitLockerKeyProtector -MountPoint C: -KeyProtectorId $rpId -ErrorAction Stop

# 3. Backup सफल होने के बाद encryption शुरू करें। 3a और 3b परस्पर exclusive —
#    इनमें से केवल एक चलाएँ (method और दायरा भी यहीं तय करें)

# 3a. Standard config: केवल TPM (unattended reboot आवश्यक terminals के लिए)
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

# 3b. TPM+PIN config (स्थिर, high-security terminals के लिए)। 3a की जगह चलाएँ।
#     PIN terminal-दर अलग मान मौके पर डालें। Script में plaintext गाड़ें तो
#     सब terminals एक ही PIN हो जाते, script स्वयं leak बिंदु बन जाती
$Pin = Read-Host -AsSecureString -Prompt "इस device का PIN"
Enable-BitLocker C: -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $Pin -TPMandPinProtector

«Recovery password सौंपकर फिर encryption शुरू» यही क्रम महत्वपूर्ण है। उलटा Enable-BitLocker -TpmProtector से शुरू करें तो प्रक्रिया बीच रुकते recovery means की copy बिना केवल TPM protection लगी PC रह जाती है, अगले firmware update या hardware बदलाव पर data समेत खो सकता है। ऊपर के क्रम में बीच रुकें तो encryption अभी शुरू नहीं, दोहराना भर काफी। संगठन deployment में 5.1 की «recovery जानकारी सहेजे जाने तक BitLocker enable न करें» policy पहले लागू रखें तो यह अधूरी अवस्था policy पक्ष से भी रुकती है। «Backup सफल पुष्टि से पहले encryption शुरू न करें» संगठन deployment का लोह नियम है।

6. Incident response — «recovery key माँगी», «न मिली»

6.1. Recovery screen आए तो पहले key ID के पहले 8 अंक

नीले recovery screen पर recovery key ID दिखती है। कई copies हों तो भी ID के पहले 8 अंक मिलाकर सही key पहचानें।⁶ खोज स्थान अध्याय 4 की तालिका के अनुसार, क्रम से।

1. संगठन का संग्रह (Entra ID admin center / Intune, या AD DS) — admin-helpdesk से
2. User का अपना account — work account हो तो aka.ms/aadrecoverykey, व्यक्तिगत Microsoft account हो तो aka.ms/myrecoverykey⁶
3. Enable करते की copy — छपी कागज़, USB में फ़ाइल, सहेजी text फ़ाइल⁶

flowchart TB
    REC["नीला recovery screen<br/>Recovery key ID दिखती है"] --> ID["Key ID के पहले 8 अंक नोट करें"]
    ID --> ORG["1. संगठन का संग्रह<br/>(Entra ID admin center · Intune / AD DS)"]
    ORG -- "ID मिलती key है" --> INPUT["48 अंक डालकर boot"]
    ORG -- "न मिली" --> SELF["2. User का अपना account<br/>aka.ms/aadrecoverykey / aka.ms/myrecoverykey"]
    SELF -- "मिलती key है" --> INPUT
    SELF -- "न मिली" --> PAPER["3. Enable करते की copy<br/>(छपी कागज़ · USB · फ़ाइल)"]
    PAPER -- "मिलती key है" --> INPUT
    PAPER -- "न मिली" --> LOST["Reset (पूरा data नष्ट) ही बचता है<br/>Microsoft भी नहीं निकाल सकता"]
    INPUT --> AFTER["कारण जाँचें, प्रयुक्त recovery key<br/>Invalidate कर reissue (अध्याय 6.3)"]

साथ «recovery mode क्यों आया» कारण जाँच आदत बनाएँ। कल BIOS update किया, Secure Boot छुआ — याद हो तो design के अनुसार व्यवहार। याद न हो बार-बार आए तो hardware खराबी या भौतिक access से छेड़ तक जाँचने योग्य है।³

6.2. फिर भी न मिले

कठोर बात: Recovery key न मिले तो उस encrypted drive का data निकालने का तरीका नहीं। Organization-managed PC पर IT department पूछना आखिरी किला, तब भी न हो तो device reset (पूरा data नष्ट) ही। Microsoft Support खोई recovery key दे या पुनः बना नहीं सकता।⁶

इसे «encryption से data गया» समझना कारण-प्रभाव उलटा है। Recovery key management mechanism न बनाना कारण था; वही management कमी चोरी पर information leak के रूप में सामने आती।

6.3. प्रयुक्त recovery key एक-बार की — मरम्मत, खो जाना, इस्तीफ़ा

• मरम्मत पर भेजते: Repairer को recovery key दी (या देने की संभावना) हो तो लौटने पर पहले नई recovery password जोड़ें, Entra ID / AD DS backup सफल पुष्टि करें, तब दी हुई recovery password हटाएँ। पहले हटाएँ तो जोड़ या backup विफल होते उस drive के पास recovery means नहीं रह जाता, क्रम महत्वपूर्ण है। Microsoft भी use बाद recovery password invalidate करने की recommendation करता है; जोड़→backup→हटाना commands से पूरा होता है।⁵ Entra ID-joined devices पर प्रयुक्त recovery password अपने आप rotate करने की policy भी है। Default Entra ID-joined devices पर enable, पर recovery जानकारी backup अनिवार्य policy (5.1) configure हो तभी चलती है। Automatic rotation पर भरोसा करने से पहले यह पूर्वापेक्षा और वास्तव में key बदलती है, जाँचें।⁴
• PC खोए: Protection enable थी (TPM protector बना, clear key हटी) अध्याय 4 के command output record या management tool से जाँचें; encrypted था तो «disk पर data नहीं पढ़ा जा सकता» समझा सकने की अवस्था बनती है। शांतिकाल में inventory बनाने का यही सबसे बड़ा कारण है।
• इस्तीफ़ा / PC वापसी: लौटे PC की recovery key इस्तीफ़ा देने वाले के व्यक्तिगत Microsoft account में ही हो — यह अवस्था न बनाना पहला काम। संगठन संग्रह पर एकत्र (अध्याय 4) हो तो वापसी का काम पुनः kitting और recovery password reissue भर रह जाता है।

उदाहरण के लिए मरम्मत का flow इस प्रकार।

flowchart LR
    S["मरम्मत पर भेजना<br/>(Recovery key दी होने की संभावना)"] --> B["PC लौटता है"]
    B --> N["नई recovery password जोड़ें"]
    N --> BK["Entra ID / AD DS backup<br/>सफल पुष्टि करें"]
    BK --> D["दी हुई recovery password<br/>Invalidate (हटाएँ)"]
    D --> OK["Inventory update कर पूरा"]

7. Disposal से संबंध — encrypted disk disposal आसान बनाती है

BitLocker का लाभ चलते समय तक सीमित नहीं। Drive शुरू से encrypted हो तो disposal पर disk पर बचा केवल ciphertext है। BitLocker मूलतः खोने-चोरी के साथ «अनुचित निपटाए devices» से data leak रोकने के लिए design है; सुरक्षित device के disposal-recycle पर data न पढ़ा जाना उद्देश्य में शामिल है।¹

पर encrypted होने से disposal की wipe प्रक्रिया (reset, समर्पित wipe tools, भौतिक विनाश) छोड़ना ठीक नहीं। Encryption «wipe से पहले या न मिटा सकें तो disk से plaintext पढ़े जाने का जोखिम घटाने» का बीमा है, verifiable wipe का विकल्प नहीं। उसके ऊपर encryption चला संगठन के लिए एक काम और जुड़ता है — recovery key की copy (कागज़, फ़ाइल, AD या Entra ID inventory) साफ़ करना। Disk मिटाएँ, copy की key बची हो तो inventory पर disposal पूरा नहीं। पुरानी key हटाना तक disposal प्रक्रिया का भाग बनाएँ।

PC disposal में encryption के अलावा account-license हटाना, asset inventory, साक्ष्य भी हैं। पूरी प्रक्रिया «Windows PC फेंकने से पहले» checklist में है; encryption मानकर disposal flow बनाने को वह साथ use करें।

8. Business app developers की दृष्टि — performance, equipment PCs, clone deployment

अंत में business apps या equipment control PCs सँभालने वाले के लिए सावधानियाँ।

• Performance प्रभाव «पहले default 128-bit पर मापें» मूल है। Microsoft स्वयं key length चुनने का मापदंड «device performance पर» रखता है; उच्च performance drive-CPU हो तो 256-bit, नहीं तो 128-bit।⁴ उलटा, आधुनिक PCs पर default XTS-AES 128 business apps के अनुभव को शायद ही हिलाए; हमारी कंपनी में file I/O विशेष भारी apps के अलावा समस्या लगभग नहीं। संदेह हो तो production-समान data मात्रा पर encryption पहले-बाद I/O मापकर तय करें; «धीमा लगेगा इसलिए काटें» अनुभव से उलटा है।
• Encryption app से transparent है। BitLocker volume-level encryption है, file API व्यवहार नहीं बदलता। उलटा चलती मशीन पर app के secrets (connection string, API keys) BitLocker नहीं बचाता। Sign-in मशीन पर drive decrypted दिखता है। वह DPAPI आदि का काम है («Windows apps के secrets कहाँ रखें»)।
• Equipment PC / kiosk PC «unattended reboot हो सकता है?» से config तय करें। केवल TPM हो तो बिजली कटने से लौटना भी बिना व्यक्ति के उठता है; TPM+PIN या startup key हर boot पर हाथ चाहिए, unattended equipment के लिए नहीं। दूसरी ओर केवल-TPM config अध्याय 3 के triggers (firmware update आदि) पर recovery screen पर रुकने का जोखिम रखता है, इसलिए स्थल से दूर स्थान (ताला+inventory) पर recovery key रखें, equipment maintenance प्रक्रिया में «काम से पहले Suspend-BitLocker» लिखें — operations की कुंजी। Unattended terminals मज़बूत करने का पूरा चित्र «Kiosk mode से business terminals मज़बूत करें» में है। 24H2 automatic Device encryption की आवश्यकता ढील Windows IoT editions पर लागू नहीं², पर इसका अर्थ «IoT पर अपने आप encryption नहीं» नहीं। ढील से पहले की आवश्यकताएँ (HSTI/Modern Standby आदि) पूरी मशीन पर पहले जैसा automatic encryption हो सकता है; equipment PCs पर भी manage-bde -status से स्थिति जाँच kitting प्रक्रिया में डालें।
• Clone deployment में «encrypt कर image न बनाएँ»। Recovery password बनाई device के लिए unique है।³ Protection enable master image की copy न लें; deployment बाद PC-दर enable (या OOBE automatic encryption) → recovery key backup क्रम रखें। Kitting script हो तो («winget + PowerShell से PC kitting automate») अध्याय 5.4 का enable और backup पुष्टि अंतिम चरण में जोड़ें।

9. सारांश

• Windows 11 24H2 के बाद clean install पर TPM+UEFI Secure Boot पूरी PCs पर Device encryption default से आरंभ होता है। HSTI/Modern Standby और DMA आवश्यकताएँ हटीं, लक्ष्य सामान्य desktop PCs तक फैला।
• «अपने आप encrypt हुआ» का सही उत्तर disable करना नहीं, recovery key का स्थान जाँचना है। काटें तो खोने-चोरी-disposal की security जाती है, एक बार काटें तो अपने आप फिर enable नहीं।
• Recovery key संग्रह Entra ID / AD DS / Microsoft account / print-file चार विकल्प, sign-in रूप से लगभग तय। संगठन का संग्रह एक तय करें, सब PCs वहाँ हैं inventory बनाएँ।
• जाँच manage-bde -protectors -get C: या (Get-BitLockerVolume -MountPoint C).KeyProtector, बाद का backup BackupToAAD-BitLockerKeyProtector / Backup-BitLockerKeyProtector से पूरा होता है।
• Recovery key firmware update, Secure Boot settings बदलना, hardware बदलना आदि पर valid owner से भी माँगी जाती है। नियोजित काम से पहले Suspend-BitLocker प्रक्रिया में लिखें।
• Default method XTS-AES 128, बाद में बदलने को decrypt→re-encrypt चाहिए। नई drive पर used space only encrypt काफी।
• प्रयुक्त recovery key invalidate कर reissue करें, इस्तीफ़ा देने वाले के account में key न छोड़ें, disposal पर key की copy तक समाप्त करें — recovery key «जारी कर खत्म» नहीं, lifecycle से managed वस्तु है।
• Encryption disposal का बीमा भी है, पर wipe प्रक्रिया (reset, wipe tools, भौतिक विनाश) का विकल्प नहीं। BitLocker काटना नहीं, recovery key management के साथ इस्तेमाल SME का यथार्थ उत्तर है।

संबंधित लेख

• Windows TPM क्या है — «key बाहर न निकालने वाला vault» और measured boot
• Windows PC फेंकने से पहले — data wipe, account हटाना, backup की practical checklist
• Windows 10 support समाप्ति के बाद यथार्थ उत्तर — ESU, LTSC, खरीदने का decision table
• SME security, कहाँ से शुरू करें — IPA «SME information security guideline» version 4.0
• Kiosk mode से business terminals मज़बूत करें — Assigned Access, Shell Launcher चुनाव और operations design
• winget + PowerShell से PC kitting automate करना — प्रक्रिया को executable बनाना
• Windows apps के secrets कहाँ रखें — DPAPI धुरी best practices

संबंधित परामर्श क्षेत्र

KomuraSoft LLC business apps और equipment PCs सहित Windows वातावरण के encryption operations design (recovery key संग्रह design, kitting में जोड़ना, equipment PCs पर BitLocker config) तथा encrypted वातावरण में business apps performance verification और समस्या जाँच सँभालता है। «Equipment PC encrypt करना ठीक है?» जाँचने से शुरू करना ठीक है।

• तकनीकी परामर्श और डिज़ाइन समीक्षा
• Windows ऐप विकास
• त्रुटियों की जाँच और मूल कारण विश्लेषण
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

पता चला «Device encryption» स्वयं चालू हो गया। क्या बंद कर दें?

Disable करना recommended नहीं। Windows 11 version 24H2 के बाद के clean install पर TPM और Secure Boot जैसी शर्तें पूरी PC पर Device encryption default से initialize होता है, इसलिए «अपने आप on हो गया» लगता है। यह खोने-चोरी पर data बचाने का mechanism है; काटने से security जाती है, और एक बार बंद करने पर अपने आप फिर enable नहीं होता। करना यह है कि disable न करें, manage-bde -protectors -get C: जैसे से recovery key जाँचें, और Microsoft account, Entra ID, AD जैसे संगठन ने तय स्थान पर stored अवस्था बनाएँ।

BitLocker recovery key कहाँ है?

Store location PC के sign-in रूप से तय होता है। व्यक्तिगत Microsoft account से set PC हो तो https://aka.ms/myrecoverykey पर उसी account से sign-in कर list मिलती है। कंपनी के Entra ID (work account) join PC पर https://aka.ms/aadrecoverykey के «View BitLocker keys» से जाँचें। On-premises AD domain join PC पर policy configure हो तो admin computer object के नीचे से निकाल सकता है। छपी कागज़, USB drive, फ़ाइल की copy भी हो सकती है। Recovery screen की recovery key ID के पहले 8 अंक मिलाकर सही key पहचानें।

Windows 11 Home PC पर BitLocker चलता है?

Edition से उपलब्ध features अलग हैं। PIN जोड़ने और policy management समेत full-featured BitLocker Pro/Enterprise/Education परिवार पर ही enable होता है; Home पर नहीं। सरल version Device encryption Home सहित सब editions पर चलता है, TPM और UEFI Secure Boot जैसी आवश्यकताएँ पूरी हों तो अपने आप enable होता है। पर protection activate करने को admin rights वाले Microsoft account से sign-in चाहिए; केवल local account से protection नहीं लगती। कंपनी PC के रूप में manage करें तो Pro मानकर Entra ID या AD से recovery keys centrally manage करने की recommendation है।

BIOS (UEFI firmware) update के बाद recovery key माँगी गई। क्यों?

BitLocker TPM से boot environment छेड़ा न गया जाँचता है; firmware update, Secure Boot settings बदलना, TPM clear करना, motherboard बदलना आदि से boot-time measurements बदलें तो «हमेशा जैसा environment नहीं» मानकर recovery mode में जाता है। यह खराबी नहीं, design के अनुसार व्यवहार है। नियोजित update से पहले Suspend-BitLocker (या manage-bde -protectors -disable C:) से protection suspend कर काम करें तो recovery key बिना काम हो जाता है। Suspension में भी drive encrypted रहता है, और default से अगले reboot पर protection अपने आप फिर चलती है।

Recovery key न मिले तो data निकाला जा सकता है?

सही recovery key (48 अंकों का recovery password) या अन्य unlock means न हों तो encrypted drive का data निकालने का कोई तरीका नहीं। Microsoft Support स्वयं कहता है कि खोई recovery key reissue या retrieve नहीं कर सकता। Organization-managed PC हो तो पहले IT से पूछें; व्यक्तिगत PC हो तो Microsoft account recovery key page, छपी copy, USB पर .bek/.txt फ़ाइल देखें। तब भी न मिले तो PC reset (reinstall) ही बचता है, data जाता है। इसलिए encryption काटने पर बहस से पहले सब PCs की recovery key संगठन के control में है, यही पहले जाँचें।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।