IEC 61850 conformance certificates: where to look for them and what a certificate really confirms

Technical requirements for digital-substation equipment often contain the wording: "shall support IEC 61850".

But for an engineer, a designer, a commissioning specialist or an operations specialist, that phrase on its own is too general. Support for IEC 61850 can mean very different things: the presence of an MMS server, support for GOOSE and/or Sampled Values, the ability to import/export SCL files, operation in the role of a client or a system configurator.

So in professional practice, the important question is not just:

Does the device support IEC 61850?

A far more important question is:

Has this particular implementation gone through IEC 61850 conformance testing, against which edition of the standard, for which software version and for which functions?

The answer to that question is given by the UCAIug / UCA Testing conformance certificate database.

Where to look for IEC 61850 certificates

The current official point of entry is the UCA Testing website. It positions itself as a resource aggregating information on interoperability testing, conformance testing, accreditation of test laboratories and certification programmes for IEC 61850, CIM and OpenFMB. On the UCA Testing home page the conformance certificate databases are listed separately, including the IEC 61850 database.

For IEC 61850 there is a dedicated 61850 Testing page. It states that the resource contains public and restricted information related to conformance testing of devices. The same page hosts the IEC 61850 Conformance Certificates link, which leads to the external UCAIug Redmine site, where one can view the certificate documents and related information on IEC 61850 conformance.

In other words, the practical scheme today is the following:

UCA Testing — the official point of entry for testing and certification programmes. Redmine Certificate Repository UCAIug — the repository where the records and the certificates themselves are hosted.

It is important not to confuse this database with an ordinary Redmine issue tracker. In this case Redmine is used as the access infrastructure for conformance certificates.

Is this a new resource?

It is more accurate to put it this way: this is the current official repository of IEC 61850 conformance certificates within the UCAIug / UCA Testing infrastructure. Previously the certificates were hosted at a different address.

The current UCA Testing materials point precisely to the external Redmine as the place to view the certificates.

UCAIug / UCA Testing have centralised the up-to-date access to IEC 61850 conformance certificates through the Redmine Certificate Repository. For engineers this means that it is better to check the existence of a certificate not against a PDF copy from a commercial proposal, but against a record in the official database.

Who stands behind these certificates

The UCA International Users Group plays a key role in the practical infrastructure of IEC 61850. In the IEC 61850 community, UCAIug is known above all for the accreditation of test laboratories and the certification of conformance testing results.

This is an important point. UCAIug does not replace the IEC and does not "write the standard instead of IEC TC57". But it is around UCAIug that a significant part of the practical conformance-verification infrastructure has formed: test procedures, accredited laboratories, certificates, interoperability testing and feedback from manufacturers and users.

For a digital substation this is fundamental. IEC 61850 is not only a set of documents. It is also an ecosystem of checks, tests and practical confirmation that specific implementations really do meet the declared requirements.

What conformance testing is

Conformance testing is the verification that a specific product complies with the requirements of the standard and the approved test procedures.

In the context of IEC 61850 this means that what is checked is not an abstract "support of the standard", but a specific implementation:

• a specific model of a device or software product;
• a specific software or firmware version;
• a specific edition of IEC 61850;
• a specific role or characteristic: Server, Client, Merging Unit, Sampled Values, GOOSE Performance or SCL/SCT;
• specific conformance blocks and test procedures.

A certificate therefore confirms not that "the device is suitable for any digital substation in general", but that the tested implementation showed no non-conformities within the declared scope of testing.

This is a narrower, but a far more engineering-useful statement.

How many records the certificate database holds

According to the published extract of the UCA IUG registry of 18 March 2026, the database contained 1,650 records across three editions of IEC 61850. Important: these are exactly test records, not necessarily 1,650 unique physical devices. One product may have several records for different software versions, editions of the standard, roles or types of testing.

The breakdown by IEC 61850 edition was as follows:

These statistics show not only the scale of the database, but also the evolution of the standard. Edition 1 formed the basis of the mass adoption of IEC 61850, Edition 2 became the next major stage, and Edition 2.1 is now becoming the main trajectory for new testing.

What types of certificates exist

The database contains records of different types. The largest categories are Server and Client. Together they account for 1,568 of the 1,650 records, i.e. about 95% of the registry.

This is unsurprising. In most digital-substation projects, protection IEDs, controllers and measurement devices act as IEC 61850 Servers. They provide the data model and the services to access it. SCADA, gateways, engineering and diagnostic tools work in the role of an IEC 61850 Client.

According to the published extract, the distribution by test type looked like this:

These categories can be briefly explained as follows:

The registry also contains a small SCL/SCT category, related to the verification of tools that work with SCL files. Within this article we will not look in detail at configurators, but the very existence of such a category matters: IEC 61850 conformance concerns not only devices and communication services, but also the engineering tools through which SCD, SSD, ICD, CID and other SCL files are created and maintained.

What exactly to look at in a certificate

A mistake is to simply find a manufacturer's name in the database and tick a box. For an engineering check that is not enough.

In the certificate and in the database record one should look at:

1. The product model. A certificate for a different device series does not confirm conformance of the model you need.
2. The software or firmware version. In IEC 61850 this is critical. The communication stack, the data model and other aspects may change from version to version.
3. The edition of the standard. Edition 1, Edition 2 and Edition 2.1 are not the same thing. For new projects, the required edition increasingly needs to be specified separately.
4. The test type. Server, Client, Merging Unit, Sampled Values, GOOSE Performance and SCL/SCT are different areas of verification. A Server certificate does not automatically mean the product has been tested as a Client, a Merging Unit or an SCL tool.
5. The conformance blocks. It is they that show which functional blocks were declared and tested.
6. The test laboratory. It matters to understand who carried out the testing and whether it was an accredited laboratory within the UCAIug procedure.
7. The date of testing. For long-living product lines the date may matter: an old version of a device could have been certified many years ago, while the version actually being supplied already differs.

flowchart TB
    START["<b>A record in the UCAIug / UCA Testing registry</b><br/>the manufacturer name is found — that is not enough"]

    START --> C1["<b>1 · Product model</b><br/>a certificate for another series<br/>does not confirm the model you need"]
    C1 --> C2["<b>2 · Software / firmware version</b><br/>stack, data model, SCL export,<br/>GOOSE and reports change from version to version"]
    C2 --> C3["<b>3 · Edition of the standard</b><br/>Edition 1 / 2 / 2.1 — these are not the same thing"]
    C3 --> C4["<b>4 · Test type</b><br/>Server / Client / Merging Unit /<br/>Sampled Values / GOOSE Performance / SCL-SCT"]
    C4 --> C5["<b>5 · Conformance blocks</b><br/>which functional blocks were<br/>declared and actually tested"]
    C5 --> C6["<b>6 · Test laboratory</b><br/>was it accredited within the UCAIug procedure"]
    C6 --> C7["<b>7 · Date of testing</b><br/>the supplied version may already<br/>differ from the certified one"]
    C7 --> OK["<b>A well-grounded conclusion</b><br/>what exactly the certificate confirms —<br/>and whether it applies to your project"]

    style START fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style C1 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C2 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C3 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C4 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C5 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C6 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style C7 fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style OK fill:#E8F5E9,stroke:#67C23A,color:#1B5E3F

Why a certificate is not just "paperwork for a tender"

In traditional procurement, a certificate is often perceived as a formal document. In IEC 61850 that is a dangerous oversimplification.

A conformance certificate helps answer real engineering questions:

• has this implementation been tested by an independent laboratory;
• against which edition of IEC 61850 it was tested;
• which software version was the object of testing;
• which services and test blocks were within the scope of verification;
• whether the certificate can be referenced during design, procurement, commissioning or acceptance;
• whether the declared role of the device matches its actual use in the project.

This is especially important in multi-vendor digital substations. Problems arise not only because a device "does not support IEC 61850". Far more often, problems appear at the interfaces: different interpretations of SCL, private sections, configurator settings and so on.

A certificate does not solve all these problems automatically. But it sets a baseline level of trust: the specific implementation has at least passed a formal conformance check.

How conformance testing differs from interoperability testing

It is important not to mix two different levels of verification.

Conformance testing answers the question:

Does a specific product comply with the requirements of the standard and the test procedure?

Interoperability testing answers a different question:

Will products from different manufacturers be able to interact correctly with each other in real scenarios?

Both levels are needed. A conformance certificate is the foundation. But for a digital substation that is not enough: on site you still need design-stage SCL verification, GOOSE/SV verification, MMS verification, analysis of how the actual configuration matches the project SCD, and testing within the specific system.

That is exactly why UCAIug matters not only as the holder of the certificate database, but also as a platform around which the practice of IEC 61850 testing develops.

flowchart TB
    subgraph CONF["Conformance testing"]
        direction TB
        CQ["<b>Question:</b><br/>does a specific product comply<br/>with the requirements of the standard<br/>and the test procedure?"]
        CO["Object: one implementation<br/>model · software version · edition · role"]
        CR["Result: a conformance certificate —<br/>a baseline level of trust"]
        CQ --> CO --> CR
    end

    subgraph INTEROP["Interoperability testing"]
        direction TB
        IQ["<b>Question:</b><br/>will products from different<br/>manufacturers be able to interact<br/>correctly with each other?"]
        IO["Object: a set of devices<br/>in real exchange scenarios"]
        IR["Result: confirmation of operation at the<br/>interfaces — SCL, DataSet, RCB,<br/>GOOSE subscriptions, SV, control"]
        IQ --> IO --> IR
    end

    CR ==>|"the foundation, but not enough"| IQ
    IR --> SITE["<b>On site you still need</b><br/>design-stage SCL verification · GOOSE/SV verification ·<br/>MMS verification · FAT / SAT ·<br/>matching the actual configuration against the project SCD"]

    style CONF fill:#EAF3FF,stroke:#42A5F5
    style INTEROP fill:#FBE9E7,stroke:#E64A19
    style CQ fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style CO fill:#fff,stroke:#90b8e0,color:#0D47A1
    style CR fill:#E8F5E9,stroke:#67C23A,color:#1B5E3F
    style IQ fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style IO fill:#fff,stroke:#e0a48a,color:#BF360C
    style IR fill:#FFF3E0,stroke:#E6A23C,color:#7A5418
    style SITE fill:#EDE7F6,stroke:#7E57C2,color:#311B92

How to use the certificate database in a project

The UCAIug certificate database is useful at several stages of a digital substation's life cycle.

At the procurement stage

It is verified whether the equipment declared by the supplier actually has a published IEC 61850 certificate.

It is important to require not just "an IEC 61850 certificate", but a certificate that specifies:

• the product model;
• the software version;
• the edition of the standard;
• the test type;
• the conformance blocks;
• the test laboratory;
• the number and date of the certificate.

At the design stage

The designer can understand which functions are actually confirmed by testing. For example, one device may have a Server certificate, but that does not mean it has been tested as a Sampled Values Publisher or Subscriber.

At the FAT and SAT stage

The certificate can be used as a starting point for the test programme. But the FAT/SAT programme must verify not only the device's compliance with the standard, but the operation of the whole system: SCD, GOOSE, SV, MMS, reports, control, time synchronisation and interaction with other devices.

At the operation stage

For the operations team the certificate database is useful when analysing changes. If the firmware of an IED has been updated on site, it is necessary to understand whether the new version matches the one that was certified, or whether it is already a different implementation from the IEC 61850 point of view.

How best to phrase requirements in a specification

A weak wording:

The equipment shall support IEC 61850.

A more correct wording:

The equipment shall have a published IEC 61850 conformance certificate in the UCAIug / UCA Testing database, specifying the edition of the standard, the test type, the software/firmware version, the test procedures applied and the list of certified conformance blocks.

For protection IEDs, bay controllers and measurement devices, an IEC 61850 Server certificate is most often required.

For SCADA, gateways, data acquisition systems, engineering and diagnostic tools, a Client certificate may be important.

For process-bus solutions, you need to look separately at Merging Unit, Sampled Values and, if needed, GOOSE Performance.

For engineering tools that work with SCL files, the registry provides the SCL/SCT category. In this article we do not examine it in detail, but when designing multi-vendor digital substations the very fact that SCL tools are verified may also matter.

Why Edition 2.1 is becoming especially important

For new projects it increasingly makes sense to specify the requirement for Edition 2.1 separately. The published statistics show that Edition 2.1 has become the dominant direction of new certifications: since January 2024, conformance testing against Edition 2.1 has become a mandatory direction in the accredited UCA IUG laboratories, and the data for 2025–2026 reflects this transition.

This does not mean that all Edition 1 or Edition 2 devices should be considered unfit. On operating sites they will be used for a long time yet. But for new projects, new procurement and new requirements for digital substations it is important to explicitly fix which edition of IEC 61850 is required.

Otherwise the wording "compliance with IEC 61850" may admit a product with an old certificate that formally complies with the standard but does not match the expectations of a modern project.

The key takeaway

The UCAIug / UCA Testing certificate database is not just an archive of PDF documents. It is a practical tool for verifying manufacturers' claims about IEC 61850 support.

For a digital substation, what matters is not the mere presence of the phrase "IEC 61850" in the equipment description, but confirmation that a specific implementation has passed conformance testing:

• against the required edition of the standard;
• in the required role;
• with the required software version;
• against defined test procedures;
• with a clear scope of verified functions.

So when choosing equipment, preparing a specification, carrying out FAT/SAT and supporting operation, the question should sound not like this:

Does the device support IEC 61850?

But like this:

Does this specific product version have a published IEC 61850 conformance certificate in the UCAIug / UCA Testing database, and what exactly does that certificate confirm?

It is this approach that turns IEC 61850 from a general declaration into a verifiable engineering requirement.