If you have ever coded a BMW with E-Sys, you are probably familiar with the traditional workflow:

Connect to the car, read the FA, find the ECU, change an FDL parameter, and write the coding back to the vehicle.

On older BMWs, this was often enough.

Modern BMWs are different.

On newer G-Series vehicles, you may sometimes change a parameter correctly, perform the coding procedure, and still find that the ECU refuses to accept the data.

This is where the term Secure Coding 2, also commonly referred to as NCD 2.0, comes into the picture.

What exactly is it? Why doesn't traditional FDL coding always work anymore? What is a signed NCD? Does the FA have to be changed first? And most importantly — how should an owner of a modern BMW deal with all of this?

Let's break it down without unnecessary mystery.

What is Secure Coding 2?

The simplest explanation is:

Secure Coding is a protection mechanism used by certain modern BMW control units to validate coding data before accepting it.

With traditional coding, E-Sys could often calculate the required coding data locally and write it directly to the ECU.

With a protected ECU, that may no longer be sufficient.

The ECU can validate not only what you are trying to change, but also whether the data being written has the required cryptographic protection and corresponds to the correct coding context.

That is why you can sometimes see a situation where:

"The coding is correct, but the ECU won't accept the NCD."

This does not necessarily mean that you selected the wrong FDL parameter.

The problem may be that the coding data itself does not satisfy the requirements of the protected coding workflow.

One important clarification:

Secure Coding 2 is not a separate vehicle function and it is not a new version of E-Sys.

It is a commonly used term for modern protected coding workflows. Whether it is required depends on the vehicle platform, the particular ECU, and its software state.

Why did BMW introduce it?

The reason is fairly straightforward.

A modern BMW is no longer just a car with a few electronic control units.

It contains dozens of ECUs, complex software dependencies, communication networks, and multiple layers of software protection.

BMW therefore increasingly controls what kind of data can be written to certain control units.

For the owner, this means that the traditional approach:

Old workflow

Change parameter → write parameter

is becoming:

Modern protected workflow

Define configuration → generate correct coding data → prepare it according to the required security mechanism → write it to the ECU

The purpose of coding has not fundamentally changed.

The important difference is how the data is prepared before it is written to the ECU.

What is an NCD file?

This is one of the most important concepts to understand.

NCD is a file containing ECU coding data.

A simplified way to think about it is as a set of configuration values that can be applied to a specific control unit.

For example, imagine that you want to change a function in the BDC.

You are not simply telling the ECU:

"BDC, turn this feature on."

The system needs to generate coding data that corresponds to the ECU, its software, and its coding structure.

For protected coding workflows, this is where NCD 2.0 comes into play.

And there is one very important distinction:

NCD is not firmware.

In simple terms:

• Coding changes configuration;
• NCD contains coding data;
• Flashing changes ECU software.

These are three different operations.

FA, SVT, CAFD and NCD — what do they mean?

If you work with E-Sys, understanding these four terms is essential.

FA — Vehicle Order

FA (Fahrzeugauftrag) is the Vehicle Order, essentially the configuration description of the vehicle.

It contains information about the factory equipment and configuration of the car.

For example, conceptually:

FA → "This vehicle has these options and equipment."

If you install new equipment, the FA may need to be modified so that the vehicle's configuration reflects the new equipment.

SVT — Software Version Table

SVT describes the software structure of the vehicle and its control units.

A simple way to think about it is:

SVT → "What is currently installed in the vehicle?"

It contains information about ECUs and their software elements.

Two concepts are especially important:

• SVT Actual — the actual state detected in the vehicle;
• SVT Target — a calculated target state used in programming workflows.

For Secure Coding/NCD-related work, the actual data from the specific vehicle is especially important.

Using an old SVT file from a different software state can result in incompatible coding data.

CAFD — the coding structure

CAFD can be thought of as the description of the coding structure associated with a particular ECU.

It tells E-Sys which coding parameters are available for a specific software state.

This is why the same BMW model can have different available parameters.

The difference may be caused by:

• software version;
• CAFD version;
• ECU variant;
• I-Level;
• vehicle configuration.

NCD — the actual coding data

If CAFD describes the structure of the available coding parameters, NCD contains the configuration data that should be applied.

A useful simplified analogy is:

FA — what the vehicle is supposed to have.

SVT — what is actually installed.

CAFD — what coding structure is available for the ECU.

NCD — what coding values should be written.

The real BMW architecture is more complicated, of course, but this model is very useful for understanding Secure Coding.

Why can't you simply reuse an old NCD?

This is where many mistakes happen.

Imagine that:

• BMW updated the vehicle software;
• the I-Level changed;
• the CAFD changed;
• the ECU received a new software state;
• the coding structure changed.

The ECU may still be physically the same ECU.

But from a software perspective, the coding context may now be different.

That is why you should not think of an NCD as a universal file:

"I generated this once, so I can use it on every BMW."

No.

The coding data must correspond to the correct vehicle and software context.

What do FA + SVT have to do with it?

This is one of the most important parts of the workflow.

A secure coding system needs to understand:

1. what configuration the vehicle should have;
2. which ECUs are actually installed;
3. what software state those ECUs are running;
4. which coding structure applies to those ECUs.

This is why modern workflows often start with FA and SVT Actual read directly from the vehicle.

The simplified logic looks like this:

BMW → read FA

↓

BMW → read SVT Actual

↓

identify the target ECU and software context

↓

prepare the appropriate coding data

↓

write the data using a compatible coding workflow

This is very different from downloading a random NCD file and hoping it works.

Do you always have to modify the FA first?

No.

This is an important point.

There is no universal rule saying that FA must always be changed before Secure Coding.

It depends on what you are trying to accomplish.

If you are changing an individual FDL parameter, the FA may not need to change at all.

If you are performing a retrofit and want the new hardware to become part of the vehicle's logical configuration, then modifying the FA may be necessary.

For example:

Install new hardware → add the corresponding option to FA → apply the appropriate coding.

So the correct way to think about it is not:

"Secure Coding always starts with changing FA."

It is:

"First define the final configuration of the vehicle, then prepare the coding data for that configuration."

If the FA needs to change, it should be changed before the corresponding coding data is prepared.

Secure Coding is not the same as VO Coding

Another common misunderstanding.

VO Coding

VO/FA Coding tells the ECU:

"Here is the current Vehicle Order. Apply the corresponding factory configuration."

FDL Coding

FDL Coding allows individual parameters to be modified manually.

Secure Coding

Secure Coding defines how coding data must be prepared and validated before it can be accepted by a protected ECU.

So Secure Coding does not replace FA, VO Coding, or FDL Coding.

It is better understood as an additional security layer around the coding process.

Secure Coding is not Flashing

This distinction is extremely important.

Coding

Changes ECU configuration.

Flashing / Programming

Changes the ECU software itself.

Programming may involve:

• SWFL;
• BTLD;
• applications;
• calibrations;
• other software components.

That is a completely different process involving programming plans such as TAL and target SVT.

Therefore:

NCD ≠ firmware

and:

Secure Coding ≠ ECU software update

They are different operations.

What about SFA?

Another acronym appears frequently in discussions about modern BMWs: SFA / Secure Feature Activation.

SFA is associated with protected features and secure tokens. BMW's E-Sys documentation treats SFA and Secure ECU Mode as separate mechanisms for working with protected ECUs.

Therefore, it is incorrect to automatically assume:

Secure Coding = SFA = NCD 2.0

They are different mechanisms.

They may appear in the same modern BMW, but they solve different problems.

Why is this especially relevant to the BMW G60?

The G60 is a good example of how much BMW electronics have evolved.

Modern G60 vehicles contain sophisticated ECUs, complex software relationships, and security mechanisms that were not present in older generations in the same form.

This is why you should not assume:

"I coded my old G30 this way, so my G60 must work exactly the same."

Not necessarily.

For a G60, the need for a Secure Coding workflow depends on the specific ECU, CAFD, and software state, not simply the name of the chassis.

This is also why two apparently identical G60 vehicles can behave differently after software updates.

What does a correct workflow look like?

If we ignore specific software and focus only on the logic, the process looks roughly like this.

Step 1 — Stabilize vehicle voltage

Always use a stable power supply for serious coding work.

This becomes particularly important when multiple ECUs are involved.

Step 2 — Connect to the vehicle

Use a compatible diagnostic interface.

ENET is commonly used with E-Sys on many modern BMWs.

ICOM may be preferable for more advanced diagnostic and programming operations.

Step 3 — Save the original FA

Rule number one:

Always keep the original.

Do not edit your only copy.

For example:

FA_original.xml

Create a separate working copy for modifications.

Step 4 — Read SVT Actual

Save the actual software structure of the vehicle.

For example:

SVT_Actual_original.xml

Ideally, FA and SVT should be obtained from the same vehicle session.

Step 5 — Define exactly what you want to change

For example:

• vehicle region;
• a specific function;
• a retrofit;
• lighting behavior;
• multimedia functionality;
• parameters of a specific ECU.

Only after that should you determine whether a protected coding workflow is required.

Step 6 — Modify FA if necessary

If the new configuration needs to be reflected in the Vehicle Order, modify a working copy of FA.

Never destroy your original backup.

Step 7 — Prepare the coding data

For ECUs requiring protected coding, the corresponding NCD 2.0 / secure coding data needs to be prepared.

The important principle is:

The data must match the vehicle, ECU, CAFD, and software state.

Step 8 — Write the data to the ECU

The prepared coding data is then written using a compatible coding workflow.

An NCD file does not magically program the car by itself.

It is simply the prepared coding data.

Step 9 — Verify the result

After coding:

• power-cycle the vehicle;
• test the modified function;
• read fault memory;
• use ISTA if necessary;
• check for communication or configuration errors.

What happens if you use the wrong NCD?

In the best case, the vehicle simply rejects it.

You may encounter problems related to:

• software mismatch;
• incompatible CAFD;
• wrong ECU;
• incorrect vehicle context;
• coding-data validation or signature requirements.

This is why Secure Coding can sometimes look confusing:

"The file looks correct, but the ECU refuses it."

In reality, the system is doing exactly what it is designed to do:

reject data that does not match the required context.

Can Secure Coding damage a BMW?

Secure Coding itself does not make a BMW immune to mistakes.

The fundamental risks remain the same:

wrong data + wrong procedure + unstable power = potential trouble.

Particularly risky situations include:

• losing power during a write operation;
• selecting the wrong ECU;
• using incompatible software data;
• accidentally programming instead of coding;
• reusing old files after a software update;
• having no backups.

So the golden rule remains:

Backup first. Experiment second.

What happens after a BMW software update?

This is one of the most important practical considerations.

Imagine that you coded your BMW today.

Several months later, the vehicle receives a major software update.

After that:

• the I-Level may change;
• ECUs may receive updated software;
• CAFD versions may change;
• available parameters may change;
• older NCD data may no longer match the new state.

Therefore, after a significant software update, it is good practice to read the current vehicle data again.

Do not automatically reuse old coding files simply because the physical vehicle is the same.

Why does FDL coding sometimes still work?

Because not every ECU and not every coding scenario requires the same security workflow.

This is an important distinction.

It would be incorrect to say:

"Every BMW after 2021 is completely locked."

It would also be incorrect to say:

"Every function on a G60 requires Secure Coding."

The more accurate statement is:

The need for Secure Coding depends on the particular ECU and its software state.

That is why you should always look at the actual vehicle data instead of relying only on the model year or chassis designation.

The big picture

Secure Coding 2 can seem complicated until you break it down.

The basic logic is actually quite straightforward:

FA describes the intended vehicle configuration.

SVT describes the actual ECU/software structure.

CAFD describes the coding structure associated with an ECU.

NCD contains the coding data.

Secure Coding adds requirements for how that coding data must be prepared and accepted by protected ECUs.

And Flashing is a separate operation that changes ECU software.

Secure Coding 2 in one sentence

If we had to explain it in one sentence:

Secure Coding 2 is not a new way of enabling hidden BMW features; it is an additional security layer used by certain modern BMW ECUs, meaning that simply modifying an FDL parameter is not always enough to produce coding data the ECU will accept.

For owners of modern BMWs, this means that you need to think not only about individual parameters, but about the entire coding context:

FA → SVT → ECU → CAFD → NCD → Coding

Once you understand that chain, Secure Coding stops looking like some mysterious system designed to make BMW coding impossible.

It is simply another step in the evolution of automotive software.

Modern BMWs are increasingly computers on wheels — and they increasingly need to be treated like computers.