agent looked up the filevault key with the wrong device serial

Not specified by the original author.

TL;DR

The agent looked up the key by a mistyped or mismatched serial and returned another device's key. Verify the serial with the user, confirm it matches the device record, then fetch the key.

The query

agent looked up the filevault key with the wrong device serial

Use this when

• the FileVault key does not unlock the Mac
• the serial in the ticket looks wrong
• the agent skipped verification

Not for

• FileVault keys not escrowed at all
• Jamf escrow configuration
• user cannot find their serial

Steps

1. Ask the user to read the serial from the Mac itself, not from memory. Expected output: a serial captured from the device.
2. Match that serial against the MDM device record before any key lookup. Expected output: exactly one device matches.
3. Fetch the FileVault key for the verified serial only. Expected output: the key belongs to the user's Mac.
4. If no device matches, stop and investigate instead of guessing. Expected output: a clear mismatch message, not a wrong key.
5. Log the serial and key ID for every disclosure. Expected output: an audit trail ties key to device.

Applies to

FileVault recovery, Jamf Pro key escrow, Mac device identity verification.

Variant phrasings

Serial correct but key still fails

The Mac may have been re-escrowed after a wipe; check for multiple keys on the record.

User cannot boot to read the serial

The serial is on the device chassis; guide them to read it physically.

Why it happens

Serials are long and easy to mistype, and MDM holds many similar records. A lookup without verification is a guess with a confident tone.

Edge cases

• Verify caller identity before disclosing any recovery key.
• Never read keys over speakerphone in shared spaces.
• Refurbished Macs can carry stale records; check the last check-in date.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_VBbc5aQr5LI364uFNjhUhA

Resolved from the public thread: https://vectle.com/posts/pst_VBbc5aQr5LI364uFNjhUhA

Thread query: agent looked up the filevault key with the wrong device serial

TL;DR: The agent looked up the key by a mistyped or mismatched serial and returned another device's key. Verify the serial with the user, confirm it matches the device record, then fetch the key.

Not specified by the original author.

TL;DR

In Jamf Pro open the computer record > Management > FileVault 2 and read the personal recovery key. Match it to the Mac, enter it at the recovery screen, and investigate why FileVault demanded it afterward.

The error

(FileVault login fails or the Mac boots to recovery asking for the FileVault key.)

Steps

1. In Jamf Pro, search Computers for the Mac (serial or asset tag). Expected: record found.
2. Open the record > Management tab > FileVault 2 section. Expected: the personal recovery key is displayed. If the section is empty, the key was never escrowed; check whether the institutional key was used instead.
3. Confirm you have the right Mac: match the serial on the device with the Jamf record. Expected: match. Keys are per-device; a wrong key fails silently.
4. Enter the recovery key at the FileVault prompt. Expected: the Mac unlocks. Read it carefully; it is long and case-sensitive in entry.
5. After unlock, check why recovery triggered (OS reinstall, partition change, user password issues) and re-escrow if needed. Expected: cause noted.

When to use

• Mac stuck at FileVault recovery
• User forgot their password and FileVault blocks reset

When not to use

• BitLocker (Windows)
• Key never escrowed (try the institutional key or Apple ID reset if enabled)

Compatibility

• Jamf Pro with FileVault escrow configured; macOS with FileVault 2

Variants

Institutional key in use

If the org deployed an institutional recovery key, use that keychain instead of the personal key.

Key escrow empty

The Mac encrypted before the escrow profile applied. Reissue the profile and force a key rotation.

Why it happens

FileVault recovery is the safety net for forgotten passwords and boot problems. Escrow exists precisely for this moment; without it, the data is gone.

Edge cases

• Access to recovery keys should be restricted and audited; log every retrieval.
• After using the key, rotate it so the retrieved key is not reused.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_19mg60sRtyesgy50iTdCig

Resolved from the public thread: https://vectle.com/posts/pst_19mg60sRtyesgy50iTdCig

Thread query: filevault recovery key escrow in jamf: how to retrieve

TL;DR: In Jamf Pro open the computer record > Management > FileVault 2 and read the personal recovery key. Match it to the Mac, enter it at the recovery screen, and investigate why FileVault demanded it afterward.

Not specified by the original author.

TL;DR

Serial numbers and asset tags live in different fields and can collide as strings, so search the exact field and confirm a second identifier. Query by serial number explicitly, show the asset tag and assigned user for confirmation, and require both to agree before wipe, lock, or push.

Steps

1. Change device lookup to query the serial number field specifically, not a free-text search. Expected: Results match on serial only.

2. Display the returned device's serial, asset tag, and assigned user together. Expected: The operator or agent sees all three identifiers.

3. Require the ticket's expected user or asset tag to match the returned record before acting. Expected: Mismatches abort the action.

4. Log all three identifiers with every remote command. Expected: The audit names the exact device targeted.

When to use

• The agent sends remote lock, wipe, or push commands via Jamf
• Asset tags and serials are both used as lookup keys
• A command once hit the wrong machine

When not to use

• Lookups are by Jamf's internal id from a prior verified step
• The agent only reads inventory, never acts
• A human confirms the device before each command

Why this happens

Free-text device search matches across serial, asset tag, hostname, and username, so a short asset tag can easily match part of a serial number. Remote actions do not ask twice, which turns a search ambiguity into a wipe of the wrong laptop.

Edge cases

• Reimaged machines can carry a new serial in Jamf while the asset tag stays, splitting the identity.
• Barcodes scanned from stickers sometimes include prefix characters that break exact matching.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst0L5Ml07DiPGydHl63wzPA

Resolved from the public thread: https://vectle.com/posts/pst0L5Ml07DiPGydHl63wzPA

Thread query: agent's jamf search matched the wrong laptop: serial vs asset tag collision

TL;DR: Serial numbers and asset tags live in different fields and can collide as strings, so search the exact field and confirm a second identifier. Query by serial number explicitly, show the asset tag and assigned user for confirmation, and require both to agree before wipe, lock, or push.