Why a programmed key starts the car but the remote buttons do not work
A replacement key that starts the engine but has dead remote buttons is usually authorised by the immobilizer while its remote-control transmitter has not been learned, is the wrong radio version, or has no usable battery. Starting the car is evidence for one channel, not proof that every key function is paired.
Remote-Control Pairing defined: Remote-control pairing is the vehicle-specific process that links a key-related electronic identity to a function such as engine authorisation, remote locking, or passive entry.
What this symptom proves—and what it does not
The useful starting point is evidence, not a programmer menu. In this case, record a successful engine start, button response at the vehicle, and the transmitter identification. Each observation answers one narrow question. A door lock response proves that a radio command reached a receiver; it does not prove that the transponder was accepted. An engine start proves an authorization path worked at that moment; it does not prove that every remote button, passive-entry antenna, or spare credential is correct.
Ford documents remote-control programming separately from anti-theft key programming; its dealer aid says that stored remote IDs can be erased and then re-entered during one remote procedure. Read the cited manufacturer or equipment documentation before applying any model-specific sequence.
A controlled diagnostic case with numbers
Use two keys if a known-good original is available. Make 3 observations with the original key, then repeat the same 3 observations with the suspect key: door lock or unlock from 1 metre, engine start with the other key moved outside the vehicle, and the relevant proximity or remote function. Write the result as pass or fail rather than relying on memory. This creates 6 comparable results and prevents a nearby valid key from being mistaken for the replacement.
| Check | Result to record | What it narrows |
|---|---|---|
| Remote command at 1 m | lock, unlock, or no response | remote transmitter and receiver path |
| Engine start with other key away | starts, cranks, or no start | immobilizer authorization path |
| Emergency reader or slot | works or fails | wireless detection versus key identity |
| Scan result | exact module and code | vehicle-side diagnosis |
{action}
Check the key identity before changing vehicle data
First review an all-keys-lost programming case. Record the VIN, model year, market, ignition or push-button system, part number, FCC ID where present, button layout, and whether the key is virgin, renewed, or previously used. A matching case colour, blade profile, or battery size is not a compatibility test. Then compare the vehicle-specific key-programming context before choosing a write operation.
Read the key with the appropriate equipment only when the vehicle and key are known to be in scope. If the readout conflicts with the physical marking, stop. Repeated write attempts are not a diagnostic method, and a screen labelled “success” is not evidence that a different electronic family has become compatible.
Common mistakes that create a second problem
- Programming the wrong function: remote pairing, immobilizer learning, and passive-entry registration can be separate operations.
- Leaving a valid key nearby: a push-button car can detect the nearby credential and make a bad replacement appear to work.
- Assuming one observed function proves the whole key: test doors, engine authorization, and proximity separately.
- Choosing a vehicle by a broad name only: year, market, module, and keyless option can change the procedure.
- Ignoring the tool’s erase language: an erase or all-keys-lost path can remove credentials that were not present.
- Changing data before recording the state: preserve screenshots, fault codes, and the key inventory before any write.
When to stop instead of repeating programming
Stop when the menu identifies a different immobilizer platform than the vehicle record, when voltage or communication is unstable, when a key readout is inconsistent, or when the next confirmation says it will erase credentials you have not inventoried. A controlled pause preserves a working original key and makes later diagnosis possible. Do not use a generic procedure copied from another model year as proof that an irreversible operation is safe.
For a practical contrast, see the module-specific CAS3 key case. Keep the conclusion modest: the symptom identifies the next test, not an automatic component replacement.
Function-by-function verification after the change
After any legitimate programming or repair, test the result with every other key moved away. Test lock and unlock once each, confirm engine authorization once, and test passive entry or the emergency reader where equipped. Record the date, vehicle identification, key identifier, selected function, supply voltage if used, and exact result. This short record separates a later battery fault from a programming claim.
Review a documented programmer troubleshooting example as a reminder to preserve exact messages. The boundary is important: this diagnostic framework cannot replace the exact manufacturer procedure, security authorization, or trained service work required for a particular vehicle.
Decision rule for remote-control pairing
Use the smallest next test that can disprove the current theory. If the original key passes the same test, the vehicle-side system is less likely to be the first failure. If both keys fail in the same location, inspect vehicle power, receiver, antenna, configuration, and module faults before touching key data. If only the replacement fails, return to its identity, condition, and the documented learning result.
Why exact platform details matter
The phrase “key programming” covers several architectures. One vehicle can use a blade transponder reader, another can use a passive keyless receiver, and a third can keep remote and immobilizer credentials in different modules. A number such as a maximum of 4 remotes or 8 keys is therefore an example from a documented platform, not a transferable rule. The VIN may help identify a vehicle, but it must be checked against actual module and key information before a write.
Information to preserve
Preserve the original working key, the suspect key, photographs of labels, the module scan report, the exact displayed warning, and the sequence of events. Note whether the engine cranked, whether the indicator flashed, and whether the door response occurred at 1 metre or only at contact range. These are concrete observations that another technician can reproduce. “It was programmed” is not a reproducible diagnosis.
Practical boundary
This article describes diagnosis and verification, not a bypass of vehicle security. A lost credential, security access, module replacement, or data-writing operation can require an authorised procedure and vehicle-specific documentation. If the only working key is at risk, preserve that state and obtain the correct procedure rather than experimenting with a similarly named menu.
Document the result, not an assumption
A reliable record names the vehicle, the exact key, the function tested, the distance or reader position, and the observed response. For example: “replacement key unlocks at 1 metre; it does not start when the original is 10 metres away; emergency reader response is fail.” That statement is more useful than “key bad” because it preserves the distinction between radio, passive detection, and immobilizer authorization. It also gives a later diagnosis a baseline after a battery replacement, software update, or module repair.
Repeat only a documented check after changing one condition. If moving the original key away changes the result, record that fact. If the same result occurs with two known-good keys, stop blaming the replacement key and look at the vehicle-side path. This disciplined sequence reduces unnecessary writes and keeps a working state recoverable. Record the exact time and ambient conditions as well.