主な用途の OID（RFC 5280 §4.2.1.12）は、1.3.6.1.5.5.7.3.1 serverAuth、…3.2 clientAuth、…3.3 codeSigning、…3.4 emailProtection、…3.8 timeStamping、…3.9 OCSPSigning です。多くの検証者は、中間証明書の EKU をその下にあるすべての証明書に対する制約として扱います。ルートプログラムはこの仕組みによって、TLS、S/MIME、コード署名の階層を分離しています。
公的に信頼される TLS は、単一用途の階層へと移行しつつあります。Chrome ルートプログラムポリシー（バージョン 1.8）は、2027年3月15日以降に発行される加入者証明書に id-kp-serverAuth だけを含めることを求めており、2026年6月15日以降に開示される下位 CA にも同じことを求めています。主要な CA は 2026年に TLS 証明書への clientAuth の追加をやめました。公的に信頼される TLS 証明書を mTLS のクライアント証明書として使っていたサービスには、プライベート CA が必要です。
EKU が欠けていたり誤っていたりすると、Go の x509: certificate specifies an incompatible key usage や OpenSSL の unsupported certificate purpose などのエラーが発生します。