My laptop sits at 90°C while idle, drawing about 10 W, with both fans close to full speed. Recently it has also started shutting down in the middle of a file copy. That’s a hardware fault, so the laptop has to go to a service centre, and they’ll need to log in to run their load tests.

They need a working Windows session. They don’t need my tax documents, my client notes, or even a list of the folders I keep them in. This post covers how I prepared the laptop so they get the first and none of the second.

The threat model, in two lines Link to heading

It helps to be clear about what each control actually protects:

  • BitLocker protects the disk when it’s outside Windows: the drive pulled and put in another machine, or the laptop booted from a USB stick.
  • NTFS permissions protect the data inside a running Windows session, from whoever is signed in.

Once Windows boots, BitLocker is transparent. A technician signed into a working session sees decrypted drives like any other user. Encryption on its own does nothing about the person at the keyboard, which is why you need both.

Problem one: an account that isn’t mine Link to heading

The rule is simple: never hand over your own login. The technician gets a standard local account, not an administrator and not a Microsoft account. A standard user can’t take ownership of files, can’t change permissions on data that isn’t theirs, and can’t turn off BitLocker.

My first choice of name was Service. Windows rejected it, because that name is reserved. I went with Technician instead, which is arguably clearer anyway.

There was also a second, rarely used family account on the laptop. I disabled it for the duration. It had no reason to be available, and a dormant account with a weak password is exactly what you don’t want sitting on a machine you’re handing to a stranger.

Problem two: BitLocker, and the recovery loop before it Link to heading

All three drives were already BitLocker-encrypted with protection on. Checking takes one command:

manage-bde -status

The more interesting part came earlier. The same unexpected shutdowns that are sending the laptop in had corrupted the AMD firmware TPM. At boot I got an “fTPM NV corrupted” prompt, and after that BitLocker kept asking for the recovery key on every start. I resolved that, and afterwards I replaced the system drive’s recovery key rather than trust one that had been through the incident.

As a result:

  • All three recovery keys are in my password manager and nowhere on the laptop.
  • The service request states in writing: don’t clear the fTPM or change security settings in the BIOS without telling me. If they reset the TPM, the next boot asks for a recovery key. They don’t have it, so they’d call me, and I’d rather they called before doing it than after.
  • If the laptop asks for a recovery key during the repair, I enter it myself.

One caveat for anyone following along: this laptop runs Windows Home, so some tooling you might reach for, such as Group Policy Editor and manage-bde -wipefreespace, isn’t available. For wiping free space after deleting sensitive files, cipher /w does the job on Home. It leaves an empty temporary folder at the root of the drive afterwards, which you can delete.

Problem three: data drives are open to everyone by default Link to heading

This is the gotcha that prompted this post.

Profile folders on C: are private by default. A standard user can’t browse another user’s Documents. Secondary NTFS drives are not. On a freshly formatted data volume, the default ACL gives Authenticated Users modify rights and the local Users group read access. That means any account you create, including the technician’s, can browse your D: and E: drives, read everything on them, and in most cases change things too.

I didn’t want to strip those default grants from the whole drive, because apps and scheduled tasks depend on them. Instead I added an explicit deny for the one account that needed locking out:

icacls D:\ /deny "Technician:(OI)(CI)F" /T /C /Q
icacls E:\ /deny "Technician:(OI)(CI)F" /T /C /Q

In NTFS, a deny entry overrides an allow, so this wins over the broad default grants without touching them. Because it’s applied at the drive root, the technician can’t even list the drive. Opening D: or E: returns Access denied, so the folder names themselves aren’t visible, not just their contents. Everything else keeps working exactly as before.

I tested it by signing in as Technician and opening each drive. Both were denied.

Two cautions if you copy this pattern:

  • Only deny a specific account, never a group you belong to. A deny on Users would lock you out as well, because deny overrides allow for you too.
  • Write the undo before you need it. /T stamps the entry on every file, so the removal has to be recursive as well:
icacls D:\ /remove:d Technician /T /C /Q
icacls E:\ /remove:d Technician /T /C /Q
Remove-LocalUser -Name "Technician"
manage-bde -status   # confirm protection is still On for every drive

After that, delete the leftover profile folder under C:\Users.

To be honest about where this stands: I also have a separate, tighter lock planned for my most sensitive folder. It’s inheritance removed, with access for only my account and SYSTEM, so no other Windows account can open it even after the technician account is gone. That lock is still on my to-do list. For the service visit the drive-level deny covers it, but it’s not done yet.

Belt and braces: a backup before it leaves the house Link to heading

A repair can go wrong in ways no permission prevents, such as a failed board or a technician who “helpfully” reinstalls Windows despite a note saying not to. So before the hand-over I took a full copy of the data drives and my profile to the NAS: about 112 GB across roughly 39,000 files, with zero failures in the robocopy logs.

The sensitive documents didn’t go to the NAS as plain files. They went into a single AES-256 encrypted 7z archive, with the password kept in the password manager. One small trap: open that archive with 7-Zip itself, not Windows’ built-in “Extract all,” which won’t handle the encrypted archive. And yes, I still need to test-open it with the password. A backup you haven’t restored from is only an assumption.

What this doesn’t cover Link to heading

A determined technician with the laptop for a week could still pull the drive. BitLocker makes that useless without the recovery key. They could also try booting other media, but a firmware change triggers a recovery prompt, so that ends up with a phone call to me. What this setup does is close the easy paths: the logged-in session and casual browsing. That’s the realistic risk at a service counter.

The consulting angle Link to heading

None of this is exotic. It’s one account, two icacls lines, and BitLocker, which was already on. The value was in knowing which layer protects against what, spotting the one default (open data drives) that would have made the rest pointless, and writing the undo steps before handing the machine over. Small offices send laptops out for repair all the time, usually with the owner’s own login on a sticky note. Setting up a repeatable, reversible hand-over procedure like this is exactly the kind of practical work I do for small-business clients.

Next up: the service report itself, and how HWiNFO, nvidia-smi and the Windows event log turned “it runs hot” into a diagnosis a technician can act on.