OnlineTool After a unit replacement, diagnostics may detect the unit while some functions remain unavailable. Component protection is one possible cause: the installed unit may not yet be linked to the vehicle as required. A KDS token may be needed to restore that link.
This guide explains what KDS protects, how a token differs from coding, and how requests and results are used.
What KDS is
KDS is electronic theft protection for certain vehicle components. It links a protected component to the vehicle. If the component is moved to another car, the system detects the mismatch. Depending on the component, functions may be limited or disabled.
It complements protection of the vehicle itself by making stolen components harder to reuse. A working unit that appears in diagnostics is not necessarily ready for full use after installation.
The protected components vary by vehicle. Read the KDS system to identify its participants rather than transferring a list from another car.
Master, Client and Pairing
KDS has a central participant, the Master, and protected components, the Clients. In the system described here, BCP, the vehicle's central electronic unit, performs the central role. The protected components are linked to the vehicle through it. “Client” here means a vehicle unit.
Pairing is the link between the central participant and a protected component. Its state shows whether they are linked correctly. E-Sys can display problems on the Master and Client sides separately.
Participants have KDS-ID identifiers within the protection system. They distinguish participants, while VIN identifies the whole vehicle. These identifiers have different purposes.
After replacing a protected unit, for example, E-Sys may show the central participant as valid and the installed component's pairing state as invalid. This explains why checking settings alone is insufficient: its participation in KDS needs investigation.
Why a KDS token is needed
A repair may require linking a protected component to the vehicle again, after replacing either the component or the central BCP unit. The documentation calls restoration Refurbish and renewed linking Re-Pairing.
A KDS token provides protected authorisation for a particular KDS operation. Restoring the link requires BMW authorisation. The program uses a token when performing the operation.
The system should not accept a new component merely because it is connected. Diagnostics first establish which link needs restoration, then permission is requested for that operation.
Obtaining a token and completing the repair are separate stages. Apply the token in the appropriate procedure, then check the system state and the component's operation.
KDS, coding, SFA and FSC
Coding provides settings for the vehicle and its equipment. It may be part of a replacement job, but settings do not establish correct KDS pairing.
SFA manages permission for protected features. Restoring a feature permission after a repair is a different task from restoring a protected component's link to the vehicle. SFA and KDS requests therefore belong to different operations.
FSC also relates to permissions, and codes have been used in earlier component protection systems. The actual method depends on the vehicle system. A message saying “function unavailable” does not identify FSC, SFA or KDS by itself: diagnostics and the repair procedure identify the mechanism.
One repair may need several actions: configure the unit, restore its link to the vehicle and check feature permissions. Each result is applied at its corresponding stage.
Why the service needs the original request
VIN identifies the vehicle. The original KDS request contains data for the specific operation prepared by the program. VIN alone is therefore insufficient to obtain a KDS response.
Create the request in the procedure that requires the token. Save it without manually changing the data and submit it when ordering. After successful processing, the service result is one token.
Return the result to the procedure that created the request. This keeps the repair task, input data and permission tied to the same operation.
The general sequence is:
- Diagnostics identify a pairing problem involving a protected component.
- The procedure determines the required operation and creates a request.
- Obtain one KDS token for the operation specified in that request.
- Apply the result in the original procedure.
- Read KDS states again and check the component in the vehicle.
Before submitting, check that the request was created for the chosen operation and meets the service's requirements.
Example: reading KDS state in E-Sys
After replacing a protected component, read the KDS participants and check their pairing state. This example uses KDS Extended in E-Sys 25.10.01.
The vehicle connection is already established. These steps read the system; restoring a link is a separate procedure based on the diagnostic results.
1. Read the participants
On Standard actions, select Read KDS. E-Sys reads the KDS system and displays participants under Master and Clients.
This identifies the central unit and protected components in the connected vehicle.
2. Check the state
Open KDS Status and select Quick check. E-Sys checks the system and displays the result.
MASTER_OK_CLIENT_OK reports a normal state on both sides. MASTER_OK_CLIENT_INVALID indicates a Client problem while Master is valid. ERROR_CLIENT_NOT_PAIRED indicates that the component is not paired with the central participant.
These results guide further diagnosis. An invalid state does not describe the whole repair: identify the affected component and the required operation.
Use the read results to establish whether a restoration procedure is needed.
Restoring the link after diagnosis
Choose the restoration procedure from the diagnostic results. It has its own actions and requirements.
For renewed pairing, KDS Extended provides Re-Pairing under Extended actions. Create request file creates a request for selected participants or the whole system. The selection must match the operation identified by diagnosis.
These actions describe the E-Sys procedure. Before obtaining a response through a service, establish that its result is intended for this operation and module.
The same section provides a lower File Name field and Write Secure Token (Set) for writing an appropriate response.
Checking the restoration result
After completing the relevant procedure, read KDS again and run Quick check. Compare the state with the initial result. Then check the component's operation in the vehicle.
The program establishes the pairing state, while the vehicle check shows whether the required operation has been restored. If pairing is valid but the function remains unavailable, continue diagnosis of settings, software, permissions and the unit itself.
Obtain a KDS response for the operation
Keep the original KDS request. Establish the response purpose for the selected procedure before ordering. VIN alone is insufficient; the service result is one token.
Orders are handled through the Telegram bot. Open the bot from the service page, check the selected service and follow its input instructions. Keep the result for the original procedure.