PIN, CS, ISN and SKIM Codes: How Module Security Access Really Works

The secret inside the module

Modern vehicles do not trust each other by default. When you turn the key or press the start button, a short conversation happens between at least two computers: something holding the key credential, and something controlling the engine. The engine controller will not fuel and spark until it is satisfied.

The thing that makes that conversation meaningful is a shared secret stored in memory on both sides. Different manufacturers named it differently, but the concept is remarkably consistent across the industry — a value that is written once during manufacture or programming, is not printed anywhere on the outside of the part, and is what makes two specific modules a matched pair rather than two interchangeable boxes.

Immobilizer-based starting systems have been effectively universal on U.S.-market passenger vehicles for more than 20 model years now, across the national light-vehicle fleet tracked by the National Highway Traffic Safety Administration. That is why the secret matters on almost anything you are likely to be working on.

Understanding this one idea explains most of what people find confusing about module programming: why a used engine controller from a scrapyard will not simply start your car, why a locksmith needs the immobilizer module rather than just the key, why an all-keys-lost job is expensive, and why a module that reads fine on a scan tool can still refuse to be written.

What the secret is called, by platform family

The names differ, the role does not. Broadly:

A PIN or CS code is the classic form on many domestic and Asian platforms — a short value the immobilizer or body module and the engine controller both hold, exchanged at every start. On many Ford-family vehicles the same idea shows up as the parameter block behind the passive anti-theft system. On Mopar-family cars the immobilizer function lives in a SKIM or SKREEM module and the secret is the SKIM code.

An ISN — an individual or immobilizer serial number — is the BMW-family equivalent, and it is the value the engine controller and the car access system module must agree on. It is why a used engine controller for a BMW is not a plug-and-play part.

On Mercedes-family vehicles the electronic ignition switch holds key and drive-authorization data, and the relationship between that module and the engine controller is what has to be reproduced when either is replaced.

Volkswagen and Audi platforms carry component security values that tie the engine controller to the cluster or body control module, depending on generation. General Motors has used everything from a resistor-pellet key value in the early anti-theft era through to modern security-access-gated controllers.

Platform family	Common name for the secret	Where it typically lives	Usual bench path when there is no working key
Ford family	PATS parameter / key code data	Body or instrument-cluster-based immobilizer function	Read stored data from the module on the bench, or clone identity onto a replacement
Mopar family	SKIM / SKREEM secret code	Dedicated immobilizer module near the column or cluster	Read from module memory, then program keys against the recovered value
BMW family	ISN (individual serial number)	Engine controller plus car access system module	Read the ISN from the engine controller on the bench and align it with the access module
Mercedes family	Drive-authorization and key data	Electronic ignition switch module	Read and clone the ignition switch data to a matched replacement
GM family	Anti-theft / security-access secret	Body control module or engine controller	Read or reset module memory on the bench, depending on generation
VW and Audi family	Component security value	Engine controller with cluster or body module	Read the value on the bench and pair the units, or clone to a donor

That table simplifies genuinely complicated engineering, and the details vary by model year even inside one family. But the pattern holds: there is a value, it lives in non-volatile memory in a specific module, and recovering or reproducing it is the actual work.

Reading a code on a bench versus asking the car over the diagnostic port

There are two fundamentally different ways to obtain one of these values, and conflating them is the single most common source of confusion.

Asking the vehicle over the diagnostic port means connecting a tool to the vehicle, authenticating to the module through its normal protocol, and requesting the value or the operation the value gates. It is fast, it is non-invasive, and it is how nearly all routine key work happens on a healthy car. It also depends entirely on three things being true: the module must be alive and communicating, the security gate must open for your tool, and the vehicle's electrical system must be stable enough to hold a session.

Reading the value on a bench means removing the module, powering it on a regulated supply, and accessing its memory directly — through a boot-mode connection, a dedicated programming interface, or in some cases direct access to the memory device itself. It is slower, it requires the part to be shipped, and it demands hardware and technique. What it offers in return is independence: a bench read does not care whether the vehicle's diagnostic bus is functional, does not care whether the vehicle has any working key, and is not blocked by a security gate that has stopped answering.

The trade-off is straightforward. Over the port is easier when the car cooperates. On the bench is the answer when it does not. Our broader walkthrough of how module programming works, from VIN writing through seed-key access and checksums, covers the mechanics of the write side in more depth.

The seed-key handshake, in plain English

Now the second mechanism — the one that controls whether you are allowed to write anything at all.

Under the unified diagnostic services standard maintained through SAE International and its international counterparts, a module exposes a set of numbered diagnostic services — more than 20 distinct service identifiers in the published standard, covering everything from reading fault memory to writing calibration data. One of them, service two-seven, is called SecurityAccess. It is the gate.

The sequence is a challenge and response:

1. The tool requests access. It asks the module to begin a security-access exchange, naming which level of access it wants — different levels exist for reading, for writing calibrations, and for higher-privilege operations.
2. The module issues a seed. It returns a value, typically a few bytes, that is effectively random for that session. The seed is different every time, which is what stops anyone from simply recording a successful exchange and replaying it later.
3. The tool computes a key. It applies a manufacturer-specific algorithm to the seed and produces the response value. The algorithm is the actual secret here — not the seed, not the key, but the transformation between them.
4. The tool sends the key back. The module runs the same computation independently and compares.
5. The module unlocks or refuses. If the values match, the module raises its privilege level for the remainder of the session and will accept the writes that were previously rejected. If they do not match, nothing unlocks.

That is the whole mechanism. It is not encryption of the data being written; it is authentication of the tool doing the writing. The elegance is that the correct algorithm never travels across the wire — only a random seed and a computed answer — so listening to the exchange teaches an eavesdropper very little.

Suppliers who build these controllers implement this pattern across enormous product lines. Bosch alone employs well over 400,000 people worldwide across its mobility and industrial divisions, and Continental employs well over 100,000 of its own. The automotive electronics families those two produce show up under a dozen different vehicle badges — which is why the same access architecture appears on cars that otherwise have nothing in common.

Attempt counters, lockout timers, and why a weak battery is a real hazard

Modules do not simply say no to a wrong key. They remember.

Most implementations maintain a failed-attempt counter. After a small number of incorrect responses — often two or three — the module refuses further attempts and starts a delay timer, commonly on the order of 10 minutes on the families we see most. During that delay it will not open the gate for anyone, including a perfectly legitimate tool with the correct algorithm. Some implementations escalate the delay with each subsequent failure, and a few require a full power cycle before the counter resets.

This is well-designed security. It converts a brute-force attack from a computing problem into a waiting problem, and waiting scales badly for an attacker.

It creates a genuine hazard in a repair bay, though, and it is worth stating plainly.

Picture a car with no working key. Someone attempts security access with a tool that has the wrong algorithm variant for that model year. Three failures later, the module is in a lockout delay, and the technician now needs the module powered continuously for several minutes to let the timer run out. The vehicle's battery is already weak — a car that has been sitting undriven while its owner sorts out a lost key is almost always down on charge. Voltage sags mid-session. The module browns out.

At best you lose the session and start over. At worst you interrupt a module in a partially authenticated or partially written state, which is exactly the condition that turns a repairable problem into a recovery problem.

This is one of the strongest arguments for bench work on difficult jobs. A regulated bench supply does not sag, does not brown out during a lockout delay, and does not care that the vehicle's battery is tired. It removes the single most common environmental failure in security-access work.

"Almost every bricked module I get sent started as somebody trying to push through a security lockout in a car with a battery that could barely hold twelve volts. The module was never the problem. The power was. On a bench I can sit through a delay timer for as long as it wants to make me wait, at rock-steady voltage, and the same module that failed in the car walks through the process without complaint." — Independent bench programming technician, 16+ years in immobilizer and ECU recovery work (anonymized)

Checksums — why a write is not finished when the write finishes

There is one more mechanism that trips people up, and it lives on the other side of the gate.

Control module memory is not a plain container. Calibration areas and identity areas typically carry checksums — computed values stored alongside the data whose job is to prove the data has not been corrupted. The module verifies them, sometimes at every startup.

If you modify data and do not recompute the checksum, the module sees a mismatch. Depending on the platform and what was changed, the result ranges from a stored fault code, to a refusal to leave a limited operating mode, to a module that will not initialize at all. The write technically succeeded. The result is still broken.

This is why respectable bench work always includes checksum correction as a step rather than an option, and why software that handles a particular family properly is worth more than software that merely writes bytes. A tool that can write but cannot compute the correct checksum for that memory layout will produce a module that looks programmed and behaves as though it is not.

It is also why an archived read of the original memory matters so much. If the original dump is preserved before anything is modified, a checksum problem or a bad edit is recoverable — you write the archive back and start again. Without that archive, you are reconstructing from nothing.

When the bench is the only path

Four situations remove the diagnostic-port option entirely.

The module is dead. No communication, no response to anything. If the value you need lives in that module's memory, the only remaining route is physical access to the memory. This is the domain of dead-module data recovery, and it succeeds far more often than owners expect, because the memory device frequently survives failures that kill the module's power supply or communication interface.

There is no working key. An all keys lost situation removes the vehicle's ability to authenticate anything. On some platforms a key can still be generated through the port; on many others the immobilizer module must be read directly. This is also the highest-scrutiny job class, and proof of ownership is mandatory before any such work begins.

The controller is blocked or locked. Some engine controllers ship from the factory locked against calibration writes, and some enter a blocked state after a failed immobilizer exchange or a botched programming attempt. Unlocking is a bench operation on most affected families — see the PCM unlocking service for the general case.

You have a donor module. A used controller carries the donor vehicle's identity and secret. Cloning that unit to your vehicle — or reading your original's data and writing it into the replacement — is inherently a bench job, because you are working on a part that is not installed in anything. Mercedes electronic ignition switch work is a good example of the pattern, handled through Mercedes EIS cloning.

A fifth situation deserves separate mention because it is a design decision rather than a failure: deliberately removing the immobilizer relationship. On orphaned platforms, engine-swap builds, and vehicles where the immobilizer hardware no longer exists, deleting the check rather than reproducing the secret is the practical repair. Our BMW EWS delete walkthrough covers how that is done on that family, and the corresponding BMW DME EWS delete service is the bench job itself. Work of that kind is offered for legitimate repair, off-road, orphaned-platform, or already-deleted applications, and the customer is responsible for compliance with the rules that apply to their vehicle and use.

The boundary this article does not cross

Everything above describes how vehicle security architecture works and why bench access exists. None of it is instruction for defeating security on a vehicle you do not own, and no part of this service lane operates without documented authorization.

The reason for that is not squeamishness. The National Highway Traffic Safety Administration has required theft-protection safeguards on passenger vehicles for decades, across a national fleet of well over 250 million registered light vehicles, and the resulting immobilizer systems work — insurance loss research published by the Insurance Institute for Highway Safety has found theft-claim frequencies on the order of 2 times higher on vehicle lines built without immobilizers than on comparable vehicles that had them. That success is exactly why attention shifted toward the modules themselves. The National Insurance Crime Bureau has reported roughly 1 million or more vehicles stolen in the United States in recent high years, and a meaningful share of contemporary theft technique works through the security system rather than around it.

The industry's answer is documented access. The National Automotive Service Task Force maintains a vetted registry of more than 2,000 credentialed security professionals, through which theft-relevant data and parts move on a recorded basis. A bench lab applies the same principle at a smaller scale: proof of ownership before any key, immobilizer, or security-access work, every time, with no exceptions for urgency or good manners.

Practically, that means an ownership document naming you and matching the VIN, photo identification, the full VIN, and a photo of the module and its label. Shops add a repair order and their customer's ownership document. It takes minutes and it is not negotiable.

Sending a module in

Bench work is mail-in and nationwide from our Arlington workshop at 1168 W Pioneer Parkway, Arlington, TX 76013. Modules ship to a different address depending on carrier: USPS to PO Box 120241, Arlington, TX 76012, and UPS or FedEx to 1009 Oakwood Ln # 120241, Arlington, TX 76012, because UPS and FedEx cannot deliver to a USPS PO Box. We buy and email you a prepaid inbound label. Return shipping is chosen at checkout and paid by you, starting at $24.95 for standard 3 to 5 business day service, with UPS 2nd Day Air at $54.95 and UPS Next Day Air at $94.95.

Text us the VIN, a photo of the module label, and a short description of the symptom before you ship, and the full catalog of bench services is on the services hub.

Frequently asked questions

Is a PIN code the same thing as a seed-key security access? No, and the distinction matters. A PIN, CS, ISN, or SKIM secret is a stored value that lets two modules agree the key is genuine — it is about the vehicle authenticating itself. Seed-key security access is a separate challenge-and-response handshake that decides whether your diagnostic tool is permitted to write to the module at all. A job can be blocked by either one independently.

Can the security-access algorithm just be read out of the module? Not in any practical sense from the outside, which is the point of the design. The algorithm lives inside the module's firmware and never travels across the diagnostic wire — only a random seed and the computed response do. That is why recording a successful exchange and replaying it later does not work, and why capability in this field comes from having correct per-family implementations rather than from intercepting traffic.

What happens if a tool gets the security access wrong too many times? The module increments a failed-attempt counter and enters a lockout delay during which it refuses all access, including from a correct tool. Some implementations lengthen the delay with each additional failure and some require a full power cycle to reset the counter, so the practical effect is that repeated guessing costs progressively more time rather than eventually succeeding.

Why is a lockout timer dangerous on a car with a weak battery? Because the module has to stay powered and stable for the entire delay, and a vehicle whose owner has been unable to drive it is almost always low on charge. If voltage sags during a lockout wait or a subsequent write, you can interrupt the module in a partially written state, which converts a straightforward job into a recovery job. A regulated bench supply eliminates that failure mode entirely.

Do I really need the checksum corrected after a write? Yes, on any memory area that carries one. A module verifies stored checksums and treats a mismatch as corruption, so an otherwise perfect data write with a stale checksum produces fault codes, a limited operating mode, or a module that will not initialize. Correct checksum handling is part of a competent write, not an optional refinement afterward.

When is reading the code on a bench genuinely the only option? Four situations remove the diagnostic-port route: a dead module that no longer communicates, a vehicle with no working key on a platform that requires direct memory access, a controller that is factory-locked or has entered a blocked state, and a donor module that is not installed in any vehicle. In all four the value you need exists in memory but nothing on the car can be asked for it.

Do you require proof of ownership for this kind of work? Yes, without exception, for every job touching keys, immobilizers, immobilizer deletion, or security access. Send an ownership document matching the VIN, photo identification, the full VIN, and a photo of the module and its label; shops should add a repair order and their customer's ownership document. The requirement exists because the technical operation is identical whether the requester is the owner or a thief.

The bottom line

Two separate mechanisms govern security work on a control module, and most confusion in this field comes from mixing them up. One is the stored secret — the PIN, CS code, ISN, SKIM value, or component security value that makes two modules a matched pair and lets the car recognize its own key. The other is the seed-key handshake, a random challenge the module issues and a computed response your tool must return before any write is permitted at all.

Recovering the first is what makes a lost-key or donor-module job possible. Passing the second is what makes a write possible. Getting the checksums right afterward is what makes the result actually run.

A healthy car with a working key rarely needs any of this done on a bench. A dead module, an all-keys-lost vehicle, a locked or blocked controller, or a used donor unit removes the easy route and leaves direct memory access as the only path — and doing that on a regulated bench supply, with the original memory archived before anything changes, is what separates a clean job from a recovery.

None of it is a route around vehicle security for someone else's car. Proof of ownership is required before any of this work begins. Text us the VIN, a photo of the module label, and a description of what the vehicle is doing, and we will tell you which of these mechanisms is actually standing in your way before you ship anything.