# SID (Service Identifier)

> The service identifier (SID) is the first byte of every UDS request and tells the ECU which service is being called: 0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier, 0x27 SecurityAccess, 0x31 RoutineControl and so on. ISO 14229-1 assigns requests the ranges 0x10 to 0x3E and 0x83 to 0x88; a positive response uses SID + 0x40, a negative response starts with 0x7F followed by the rejected SID. Probing every SID in every session is how a tester maps the diagnostic surface of an ECU.

The SID is the first byte of every UDS message and names the service, from 0x10 DiagnosticSessionControl to 0x3E TesterPresent. Ranges, response rule, SID sweeps.

Source: https://auto-st.com/glossary/sid · Updated: 2026-10-07

## What is a SID?

The service identifier is the one byte at the start of every UDS message that says which service the tester wants. `10` is DiagnosticSessionControl, `11` ECUReset, `22` ReadDataByIdentifier, `27` SecurityAccess, `2E` WriteDataByIdentifier, `31` RoutineControl, `34` RequestDownload, `3E` TesterPresent. Everything after the SID belongs to that service: a sub-function byte for services that have one, then the parameters.

The response rule is simple. A positive response starts with the request SID plus `0x40`: `10 03` is answered with `50 03 ...`, `27 01` with `67 01 <seed>`. A negative response is always three bytes, `7F`, the rejected SID and a negative response code (NRC), for example `7F 27 36`.

## Where is it defined?

ISO 14229-1:2020 lists the service identifiers and their ranges in clause 8 and Table 2. Request SIDs for UDS occupy `0x10` to `0x3E` and `0x83` to `0x88`; `0x00` to `0x0F` and `0x40` to `0x4F` are left to the legacy OBD services of ISO 15031-5. Positive responses live at `0x50` to `0x7E` and `0xC3` to `0xC8`, `0x7F` is the negative response identifier, and `0xBA` to `0xBE` (responses `0xFA` to `0xFE`) are reserved for system supplier specific services. The remaining values are reserved by ISO. Each service clause defines which sub-functions exist and which NRCs the ECU may return.

## What it means in practice

Because the SID is the first byte, a tester can send every possible value and classify the ECU's reaction. An unused SID gets `7F xx 11` serviceNotSupported. A SID that exists but needs another session gets `7F xx 7F` serviceNotSupportedInActiveSession. A SID behind SecurityAccess gets `7F xx 33`. A SID that answers with a wrong-length complaint, `7F xx 13`, exists and is reachable right now. Repeating this sweep in the default, extended and programming session produces a map of the diagnostic surface in a few minutes.

We regularly see three kinds of findings in such a sweep: services that answer in the default session although they should need the extended session (typically `0x2E`, `0x31` or `0x11`), supplier specific services in the `0xBA` to `0xBE` range that nobody documented, and ECUs that answer `7F xx 10` generalReject to everything unknown, which hides the structure but still tells you which SIDs behave differently.

## How AutoST tests it

The AutoST enumeration engine probes every SID from `0x00` to `0xFE` in each discovered session and classifies the response as supported, security access denied, not supported in this session, conditions not correct or not supported. Risky services such as `0x11`, `0x31`, `0x34` and the memory services are flagged and weighted into the risk score; the fuzzing engine can then target selected or non-standard SIDs with malformed payloads.

## Common misunderstandings

A SID is not a session and not a permission. `0x27` exists on almost every ECU, but existing is not the same as being unlocked. Also, the response SID + 0x40 rule is why `0x7F` can never be a request: a request `0x3F` would collide with the negative response identifier, so ISO reserves it.

## FAQ

**How do I recognise a positive response?**

Its first byte is the request SID plus 0x40. A request 10 03 is answered with 50 03, a request 22 F1 90 with 62 F1 90 and data. If the first byte is 0x7F instead, the response is negative and the second byte repeats the rejected SID.

**What is the sub-function byte?**

Services such as 0x10, 0x11, 0x27 and 0x31 carry a second byte that selects a variant, for example 10 03 for the extended session. Bit 7 of that byte (0x80) is the suppressPosRspMsgIndicationBit: 10 83 switches session without a positive response.

**Are SIDs above 0x3E used?**

Yes. 0x83 AccessTimingParameter, 0x84 SecuredDataTransmission, 0x85 ControlDTCSetting, 0x86 ResponseOnEvent and 0x87 LinkControl are standard services; 0xBA to 0xBE are reserved for system supplier specific services, and their responses sit at 0xFA to 0xFE.

## Sources

- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, clause 8 and Table 2 (service identifier ranges)](https://www.iso.org/standard/72439.html)
- [ISO 15765-2:2024 Road vehicles, Diagnostic communication over CAN (DoCAN), Part 2](https://www.iso.org/standard/84211.html)

## Related

- [UDS (Unified Diagnostic Services)](https://auto-st.com/glossary/uds)
- [NRC (Negative Response Code)](https://auto-st.com/glossary/nrc)
- [Diagnostic session (DiagnosticSessionControl 0x10)](https://auto-st.com/glossary/diagnostic-session)
- [UDS Message Decoder](https://auto-st.com/tools/uds-message-decoder)
- [UDS enumeration explained: how to map an ECU safely](https://auto-st.com/insights/uds-enumeration-explained)
- [Know every door into the ECU.](https://auto-st.com/uds-enumeration)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/glossary/sid
