When a key does not work: diagnose the symptom first

“The key does not work” is a customer’s description, not a diagnosis. It may mean a blade will not turn, an unlock button gives no response, passive entry is intermittent, or the engine will not start. A useful first task is to translate that sentence into observable behavior. The quality of this translation determines whether the next test teaches you something or merely adds another attempt to the job history.

Define the complaint without naming a cause

Ask what the customer did, what they expected, and what happened instead. Record when the issue began, whether it is consistent, which keys are affected, and any recent battery service, damage, or repair. “No crank with either presented key; instrument display illuminates” is more useful than “immobilizer broken.” “Starts normally; unlock button fails on Key B” describes a different problem.

Cranking means the starter turns an internal-combustion engine. A no-crank condition differs from an engine that cranks but does not run. For a hybrid or electric vehicle, use the manufacturer’s applicable ready-to-drive terminology. Do not impose an engine-start checklist on a vehicle with a different operating sequence.

Build a function-by-function symptom matrix

Label the customer’s keys temporarily as A, B, and so on. Record pass, fail, not equipped, or not tested for each function. These labels prevent an unperformed check from becoming an accidental success. Keep the vehicle state and test conditions consistent, and follow the manufacturer’s directions for handling other keys during testing.

These questions organize investigation. For example, Ford’s referenced owner information lists several conditions that inhibit remote start, including an open hood, an unsuitable transmission state, and a discharged vehicle battery. A failed remote-start request can therefore have a cause other than a failed key. Check the manual for the actual vehicle. Ford: Remote Control.

Use codes as evidence with a defined scope

A diagnostic trouble code, or DTC, records that a monitored condition met defined criteria. Its description is a starting point for a documented test, not an instruction to replace whichever component appears in the wording. Retain the reporting module, full code, status, and associated data where available. The meaning of statuses and the next test must come from the applicable service information.

Snap-on notes that code functions and terminology vary by vehicle manufacturer and that clearing can erase useful diagnostic records. Save relevant information before any authorized clearing operation. Erasing a code is not evidence that its cause was repaired. Snap-on: Working with Trouble Codes.

Also record what the tool actually checked. Snap-on describes generic OBD-II/EOBD data as limited to emissions-related diagnostics. “No codes in a generic engine scan” therefore cannot establish that every body, access, or security-related module has been examined. Coverage must be verified for the selected tool, software, vehicle, and function. Snap-on: OBD-II/EOBD.

Choose tests that distinguish competing explanations

Write two or three plausible explanations, then identify the least disruptive authorized observation that separates them. If one key consistently works and another fails under equivalent conditions, the difference is useful. If neither works and the vehicle supply is outside the manufacturer’s permitted conditions, key enrollment may not be an appropriate next step. Restore valid test conditions or refer the underlying fault according to scope.

Change one relevant variable at a time and record the result. Replacing a battery, changing location, and attempting enrollment simultaneously makes it difficult to know which action mattered. Keep “observed,” “suspected,” and “confirmed” distinct in notes and customer explanations.

Hypothetical case: an unnecessary programming request

A customer asks for reprogramming because Key B’s buttons stopped working after the case was damaged. Key A’s buttons work; both keys still support normal starting. The technician verifies the complaint and documents the damage. This narrows the investigation toward Key B’s remote function, including its battery installation and physical condition, while retaining other explanations until tested.

The evidence does not justify erasing enrolled keys. It also does not prove that the battery alone is responsible. The useful next step is the documented inspection and test for that remote, followed by repetition of the original functional checks after an approved remedy.

Common mistakes

• Turning a customer’s proposed remedy into the diagnosis.
• Testing several keys together and attributing recognition to the wrong one.
• Clearing codes before saving the baseline.
• Interpreting “not supported” as “no fault.”
• Ignoring vehicle power because the complaint mentions a key.

Practice: what does the evidence establish?

Both remotes fail to unlock. A generic OBD scan reports no codes. Does this prove both remotes require programming?

Continue your learning

• Electrical fundamentals for automotive key technicians
• Automotive key compatibility: build an evidence chain
• Documenting a key-programming job from intake to handover