# SC-047v2: the OU field disappears from TLS certificates

> SC-047v2 banned the subject organizationalUnitName (OU) field in publicly trusted TLS certificates issued from 2022-09-01.

Source: https://ssl.sh/ballots/sc-047/
Last updated: 2026-11-10

SC-047v2 removed the "OU" (organizational unit) field from TLS certificates. Since 2022-09-01, publicly trusted CAs may not put an organizationalUnitName attribute into the subject of a TLS certificate, even if your [CSR](https://ssl.sh/glossary/csr/) contains one.

## What changed

SC-047v2 set a sunset date for the OU field because CAs could not verify its free text meaningfully. The ballot text says several earlier attempts to strengthen validation of the field failed to gain consensus. Before the deadline, an OU was only allowed together with an organization name; from 2022-09-01 it is prohibited altogether. It was proposed by Entrust and endorsed by Mozilla and Firmaprofesional. The certificate profiles later defined by [SC-062v2](https://ssl.sh/ballots/sc-062/) list OU as "MUST NOT" for subscriber certificates.

## Effective dates

The BR change took effect on 2021-08-16. The prohibition applies to certificates issued on or after 2022-09-01.

## Who is affected

Organizations ordering [OV](https://ssl.sh/glossary/ov-certificate/) or [EV](https://ssl.sh/glossary/ev-certificate/) certificates that used OU for a department name, and internal tools or pinning rules that matched on OU. DV certificates never contained it.

## What to do

You can leave OU in your CSR; the CA drops it. Don't build logic that relies on the OU of a public TLS certificate. Use the [CSR generator](https://ssl.sh/tools/csr-generator/) to create a request with only the fields that matter.


| Field | Value |
|---|---|
| Ballot | SC-047v2 |
| Status | Passed |
| Adopted | 2021-06-30 |
| Effective | 2021-08-16 |
| BR version | 1.7.9 |
| Official page | https://cabforum.org/2021/06/30/ballot-sc047v2-sunset-subjectorganizationalunitname/ |