UDS SecurityAccess, service 0x27, unlocks restricted functions in a vehicle control unit. The tester asks for a random seed, both sides compute a key from it with a secret algorithm, and the unit grants access if the keys match. It is a gate, and its strength depends on that algorithm and on attempt limits.
What UDS is
Unified Diagnostic Services is the diagnostic protocol defined by ISO 14229. It grew out of ISO 14230, known as KWP2000. It works at the upper OSI layers, so it can run over CAN, LIN, Ethernet, FlexRay and K-Line, and in practice it is most often used over CAN through DoCAN, which is ISO 15765.
Each request has a service identifier. A positive response uses that identifier plus 0x40. Service 0x10 switches diagnostic sessions, 0x19 reads fault codes, 0x14 clears them, and 0x34, 0x36 and 0x37 move data to a unit, which is how firmware can be updated.
The SecurityAccess flow
- The client requests a seed.
- The server returns a random seed.
- Both sides compute a key from the seed using a secret algorithm.
- The client sends its key.
- The server compares the keys and, on a match, grants access for that security level.
Negative responses to know
A refusal comes back as 0x7F, the service identifier and a negative response code. Three matter here. Code 0x33 means security access denied. Code 0x35 means invalid key. Code 0x36 means the allowed number of attempts was exceeded. Code 0x78 means the response is pending, which is normal and not a failure.
Where designs go wrong
The flow looks sound, but it depends on details the protocol does not enforce for you.
- A secret algorithm shared across a whole fleet is one leak away from being public. Per unit or per vehicle secrets limit that.
- Seeds must be unpredictable. A seed that repeats or follows a pattern lets an observer replay a valid key.
- Attempt limits and delays matter. Without them, guessing keys is practical.
- The unlock should guard only what it must. Broad access levels turn one stolen key into full control.
These are design reasoning points rather than findings from a specific vehicle. The protocol article itself describes the flow and error codes but does not evaluate their strength.
How this relates to regulation
UN R155 asks manufacturers to manage cyber risk across the vehicle life cycle, and diagnostic access is part of that surface. A threat analysis should list who can reach 0x27 and what an unlocked session allows. See the posts on TARA and the OBD port for more.
A practical test plan
If you own a control unit, test the unlock like an attacker would. Request seeds many times and look for repeats. Send wrong keys until the lockout triggers and confirm the delay survives a power cycle. Check that each security level opens only the services it should. Write the results into the threat analysis so the next review starts from evidence.
Quick check
Is a seed and key exchange the same as encryption?
No. It is a challenge and response check that proves the tester knows a secret. It does not encrypt the diagnostic traffic.
Sources
Last reviewed: 19 October 2026.
