# UDS Negative Response Code Decoder

> This tool decodes UDS negative response codes (NRCs) per ISO 14229-1 Annex A. Paste a complete negative response such as 7F 27 35, or a bare code such as 33, and it shows the ISO name, the service that was rejected and what the code usually means when you test an ECU. The full table below the tool is searchable and includes the codes used by the Authentication service (0x29).

Decode a UDS negative response in a second: paste 7F 27 35 or a bare code and get the ISO 14229 name, the rejected service and what it means on the bench. Full NRC table.

Source: https://auto-st.com/tools/uds-nrc-decoder · Updated: 2026-10-07

## How it works

A UDS negative response is always three bytes: `7F`, the service identifier (SID) of the rejected request, and the negative response code. The tool accepts the full response or just the code, looks it up in the ISO 14229-1 table and adds what the code usually tells you when you test an ECU, written from the tester's point of view rather than the ECU's.

The table covers all codes defined in ISO 14229-1:2020 Annex A, including the range 0x50 to 0x5D used by the Authentication service (0x29) and the vehicle-condition codes 0x81 to 0x94. Codes outside the table are manufacturer-specific or reserved.

## How to read the result

Three codes carry most of the information during enumeration. `0x11` serviceNotSupported means the service does not exist on this ECU at all. `0x7F` serviceNotSupportedInActiveSession means it exists but needs another session, typically extended (0x03) or programming (0x02). `0x33` securityAccessDenied marks the surface that is protected by SecurityAccess. An ECU that answers `0x12` or `0x7E` for sub-functions, and `0x31` for unknown identifiers, is telling you its map one response at a time.

During SecurityAccess testing, count `0x35` invalidKey responses. After the configured number of attempts the ECU must answer `0x36` exceedNumberOfAttempts and then `0x37` requiredTimeDelayNotExpired. An ECU that keeps answering `0x35` has no attempt counter, which is a finding.

## Limits

The tool knows the standard codes, not what your ECU does with them. Some implementations answer `0x10` generalReject to everything they do not understand, which hides the structure. Some mislabel conditions. AutoST's enumeration treats the responses statistically across sessions, which is how it maps services and identifiers even on such ECUs.

## FAQ

**What is the structure of a UDS negative response?**

Three bytes: 0x7F, the service identifier of the request that was rejected, and the negative response code. A tester that sends 27 03 (SecurityAccess, requestSeed level 3) and receives 7F 27 7E learns that sub-function 03 exists but not in the active session.

**Is 0x78 an error?**

No. requestCorrectlyReceived-ResponsePending tells the tester the ECU needs more time; the tester extends its P2* timeout and waits for the final response. ECUs that send 0x78 and then never answer are a finding, because the tester hangs.

**Why do some ECUs answer 0x31 instead of 0x7F for unknown DIDs?**

requestOutOfRange (0x31) is the correct answer to a DID the ECU does not support, while serviceNotSupportedInActiveSession (0x7F) means the whole service is unavailable in the current session. Mixing them up is common and makes enumeration harder; AutoST interprets both.

## Sources

- [ISO 14229-1:2020 Road vehicles, Unified diagnostic services (UDS), Part 1: Application layer, Annex A](https://www.iso.org/standard/72439.html)

## Related

- [NRC (Negative Response Code)](https://auto-st.com/glossary/nrc)
- [UDS (Unified Diagnostic Services)](https://auto-st.com/glossary/uds)
- [UDS Message Decoder](https://auto-st.com/tools/uds-message-decoder)
- [Know every door into the ECU.](https://auto-st.com/uds-enumeration)
- [Does your seed/key actually hold?](https://auto-st.com/security-access-testing)

---
AutoST by Zyberum. Canonical page: https://auto-st.com/tools/uds-nrc-decoder