Skip to content

Siemens Product PKI Certificate Management Service – Certificate Policy for Siemens Digital Industries

Siemens AG · Version V2.0

Publication Date: Sep. 2026

Document History

Version Creation Date Author Change Comment
1.0 June 10, 2024 Kai Che, Michael Munzert
T CST SEA, on behalf of DI CTO CYS		 Initial version
2.0 June 29, 2026 Kai Che, Florian Oprea
FT RPD CST SEA on behalf of DI CTO CYS		 Incorporated changes to include signature certificate, "FDS RA", and operational certificate use case throughout the whole document.
Added OIDs of additional DI CM tenants in Chap. 1.2.
Added additional PKI participants in Chap. 1.3.4.
Updated References.
Minor editorial changes.

This document will be reviewed every year or in the event of an important ad-hoc change according to the Information Security update process for documents. Each new version will be approved by the respective management level before being released.

This document is published under http://www.siemens.com/industrial-security/pki.

Scope and Applicability

This document constitutes the Certificate Policy (CP) for the Siemens Digital Industries Certificate Management Service. The Product PKI is responsible for the operation of the Root CAs as well as for the CAs, which are hosted in the Siemens Trust Center. In addition, it defines requirements for the management and operation of local components and services such as Registration Authorities. Together with the Central CP [CCP] it discloses to interested parties the business policies and practices under which the Siemens Digital Industries Tenant is operated.

The Tenant PMA ensures that the certification practices established to meet the applicable requirements specified in the present document are properly implemented in accordance with Siemens' Information Security Policy.

Document Status

This document with version 2.0 and status "Released" has been classified as "Unrestricted".

Name/Role Department Approval Date
Author Various authors, detailed information in document history
Authorization Dr. Oliver Kaiser
Chief Cybersecurity Officer of Siemens Digital Industries		 Head of Siemens DI CTO CYS Aug. 2026

Content

1 Introduction

This document is structured according to RFC 3647 "Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework" [RFC3647].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. Lowercase occurrences of these words are to be interpreted according to their ordinary meaning unless explicitly stated otherwise.

1.1 Overview

This document describes the Certificate Policy of Siemens Digital Industries.

Together with the Central CP [CCP] it describes the services provided by the Product PKI as well as binding requirements that must be fulfilled by Product PKI participants. In case there are no specific requirements defined by the tenant (in this document, i.e. Tenant CP), the respective section will refer to the Central CP. In case specific requirements are listed they will apply in addition to the requirements set forth in the Central CP.

Moreover – together with the CPSs – the CPs also define the certification process as well as the cooperation, duties and rights of the Product PKI participants.

The Product PKI is a PKI that provides and manages certificates (e.g. "IDevID certificates" or "Manufacturer Device certificates", "LDevID certificates" also called "Operational Certificates", signature certificates for signing manufacturer data (code, licenses, configurations, …) or others) that are stored on and used by Siemens products and solutions. The private key might be used in bootstrapping scenarios for authentication purposes. Or the certificate might be used to prove that the device is a genuine Siemens device.

Unless otherwise stated, the term "Product PKI" or any of its entities, refer to "Siemens Product PKI Certificate Management Service", or any of its respective entities, for the rest of this Certificate Policy.

Since different stakeholders are involved, also responsibilities are distributed between these stakeholders:

  • Siemens Product PKI governance: responsible for the PKI service is the organization listed in section 1.5 Policy Administration.
  • Siemens IT Services: The central PKI service is hosted in the Siemens Trust Center that is operated and managed by Siemens IT department.
  • Tenant: Tenant can be every Siemens AG organizational unit or any other legal entity that has a contract in place that covers Product PKI services. The Tenants typically operate and maintain the registration authorities, for example within their production facilities or data centers. Therefore, the _Tenant_s are responsible for RA operation and End-Entity authentication.
Trust Center
Responsibility: PPKI governance		 ⇔ Tenant: e.g. Production Site
Responsibility: Tenant
PPKI Services ⇐⇒ RA → End Entity (e.g. device)

Figure 1: Stakeholders and typical responsibility split

In accordance with this responsibility split, there are two Certificate Policies, one for the Tenant specific aspects (Tenant CP) and one for the central part of the Product PKI (Central CP [CCP]). The same holds for the corresponding Certification Practice Statements (CPSs).

The Tenant specific CP is always the master document. It defines all requirements for which the Tenant is responsible for. In particular, it comprises the management and operation of the RAs and/or LRAs, and of publicly accessible repositories. Where appropriate, the Tenant specific CP will also refer to requirements valid for the operation of the central service. In that case the phrase "See also Central CP for central service aspects" is used. In those sections that are not relevant for the Tenant, it is referred to the Central CP by using the phrase "See Central CP".

The Tenant specific CP is supplemented with the Central CP. In particular, the Central CP comprises all requirements for the management and operation of the Central PKI System including Root CA and Issuing CAs.

The Tenant CPS describes how the requirements defined in the Tenant CP are implemented. In addition, the Central CPS supplements how the requirements defined in the Central CP are implemented.

The different documents and their interrelation are depicted in the following figure:

Scope Certificate Policy (defines what) Certification Practice Statement (defines how)
Central (Trust Center / Root & Issuing CAs) Central CP [CCP] ⟶ implemented by ⟶ Central CPS
⇧ supplements ⇧ supplements
Tenant (RA / LRA / End Entities) Tenant CP
(this document)		 ⟶ implemented by ⟶ Tenant CPS

Figure 2: Document structure (CP and CPS). The Tenant CP is the master document; the Central CP supplements it. Each CP is implemented by its corresponding CPS.

In addition to the requirements defined in this CP and the corresponding CPSs, Siemens IT systems are operated according to the Siemens internal information security rules and respective execution guidelines, which define how IT systems must be operated securely. The corresponding documents can be retrieved on request.

These rules are part of the Siemens ISMS [ISMS], which is defined and implemented according to ISO 27001.

1.1.1 PKI hierarchy

The generic PKI hierarchies are shown in Figure 3.

Tier Node Role
1 Product(s) Manufacturer Root CA (offline Root CA – self-signed) Issues certificates for the Manufacturer Issuing CAs
⬇ signs
2 ├─ Product Line #1 … #N Manufacturer Issuing CA Issues IDevID / LDevID End Entity certificates
└─ Signature Certificate Issuing CA Issues Signature Certificates
⬇ signs
3 ├─ IDevID / LDevID End Entity Certificates Held and used by devices of the respective product line
└─ Signature Certificates Used for signing manufacturer data (code, licenses, configurations)

Figure 3: Product PKI hierarchy

1.2 Document Name and Identification

This CP is referred to as 'Siemens Digital Industries Certificate Policy'.

  • Title: Siemens Product PKI – Digital Industries Certificate Policy
  • OIDs:
  • 1.3.6.1.4.1.4329.99.1.2.1.1
  • 1.3.6.1.4.1.4329.99.1.2.17.1
  • 1.3.6.1.4.1.4329.99.1.2.35.1
  • 1.3.6.1.4.1.4329.99.1.2.54.1
  • 1.3.6.1.4.1.4329.99.1.2.59.1
  • 1.3.6.1.4.1.4329.99.1.2.80.1
  • Expiration: This version of the document is the most current one until a subsequent release.

The set of all documents describing the Siemens PPKI is referred to under the OID 1.3.6.1.4.1.4329.99.1.2.

1.3 PKI Participants

PKI participants are described in the Central CP [CCP].

1.3.1 Certification Authorities

A graphical overview of the CA hierarchy is depicted in Figure 3: Product PKI hierarchy.

1.3.1.1 Root CA

See Central CP.

1.3.1.2 Intermediate CA

See Central CP.

1.3.1.3 Issuing CAs

See Central CP.

1.3.2 Registration Authorities

See Central CP.

The (L)RA is responsible for verifying device/system identities against production databases before forwarding certification requests to the central PPKI service.

In addition, Local Registration Authorities may be used to request certificates on behalf of a device in production. In this case the LRA also might generate key material on behalf of a device.

The LRA shall communicate with a RA only via a protected communication link.

Additional RA responsibilities shall be detailed in the relevant CPS.

1.3.3 Subscribers

See Central CP.

1.3.4 Relying Parties

See Central CP.

1.3.5 Other Participants

1.3.5.1 Subject (End Entity)

See Central CP.

1.3.5.2 Certificate manufacturing authorities

See Central CP.

1.3.5.3 Providers of repository services

See Central CP.

1.4 Certificate Usage

1.4.1 Appropriate Certificate Usage

See Central CP.

1.4.2 Prohibited Certificate Usage

See Central CP.

1.5 Policy Administration

1.5.1 Organization Administering the Document

The organization responsible for drafting, maintaining, and updating this CP is:

DI CTO CYS

E-mail: industrial-security.pki (at) siemens.com

Website: https://certificates.pki.siemens.cloud/ppki/index.html

1.5.2 Contact Person

Questions about this CP may be sent to:

Siemens AG DI CTO CYS

Certificate Problem Reports shall be sent to: certificate-problem-report (at) siemens.com

1.5.3 Person Determining CP and CPS Suitability for the Policy

The Policy Management Authority (Tenant PMA) in section 1.5.1 determines suitability of this document.

1.5.4 CPS Approval Procedures

A bi-annual risk assessment is carried out to evaluate business requirements and determine the security requirements to be included in the certificate policy for the stated community and applicability. In addition, the CP as well as the CPS will be reviewed bi-annually regarding consistency with the actual PKI processes and services (see also section 8).

This document is accepted and approved by the respective Tenant PMA.

1.6 Definitions and Acronyms

1.6.1 Definitions

Term Definition
Authority Revocation List Certificate Revocation List containing CA certificates.
CA certificate Certificate for a Certification Authority's public key.
Central PMA PMA that is responsible for the management and operation of the Central Product PKI Certificate Management service.
Central Product PKI System Technical components of the Product PKI Certificate Management System that are managed and operated in the Siemens Trust Center facility.
Certificate Policy (CP) Compare section 1.1.
Certification Authority (CA) Authority, that is entitled to certify public keys; compare section 1.3.1.
Distinguished Name Sequence of data-fields uniquely identifying e.g. the issuer and the Subject within a certificate or a CRL. The format of a Distinguished Name is defined in the [X.520] standard.
EE certificate See "End-Entity certificate".
End-Entity Equivalent to Subject; the identity of the End Entity is connected to the certificate and the related key-pair. See also section 1.3.3.
End-Entity certificate A digital certificate is used to prove ownership of a public key and the corresponding private key. It must not be used for certifying and issuing CRLs or other certificates.
End-User certificate See "End-Entity certificate".
Factory hard reset In contrast to a reset to factory settings, in case of a factory hard reset, all device specific key material is deleted.
HSM Hardware Security Module that can be used for random number generation and generation and storage of secret keys. The HSM can use the keys for digital signatures and for other PKI-applications.
Intermediate CA Entity that issues and manages certificates of further Intermediate CAs or Issuing CAs and has a certificate signed by either a Root CA or by an Intermediate CA.
Issuing CA Entity that issues and manages certificates of End Entities and has a certificate signed by either a Root CA or by an Intermediate CA.
Issuing CA System Technical components (hardware and software) hosting Issuing and Intermediate CAs.
Multi-person Control Sensitive activities typically are carried out by more than one person holding a trusted role. This is called Multi-person control.
Policy Management Authority A body (of Siemens) that is responsible for setting, implementing and administering policy decisions regarding this CP and related documents and agreements in the Product PKI.
Product PKI Term used in this document for the Siemens Product PKI Certificate Management Service (due to ease of readability).
Product PKI System Technical components (central and local) that are necessary to manage and operate the Product PKI Certificate Management System.
Qualified Auditor Auditor who has appropriate knowledge in order to evaluate and assess and confirm the requirements and corresponding implementation of measures defined in the Certificate Policy documents and the Certification Practice Statements, respectively.
Registration Authority (RA) PKI-incorporated facility for participant-authentication. See also section 1.3.2.
Relying Party Individual or legal entity that uses certificates; see also section 1.3.5.
Root CA Entity that issues and manages certificates of Intermediate or Issuing CAs (in case there do not exist Intermediate CAs). The certificate of the Root CA is self-signed.
Root CA System Technical components (hardware and software) hosting Root and (optionally) Intermediate CAs.
Secure Device A component (such as a Smart Card or HSM) that substantiated to protect the private key stored in that device. All cryptographic operations using the private key are performed inside this Secure Device.
Siemens Product PKI Certificate Management Service Siemens internal organization that issues and manages certificates. This organization operates the Root CA System as well as the Issuing CA systems.
Smart Card Integrated circuit card including a micro-processor that can be used for random number generation and generation and storage of secret keys. A Smart Card can use the keys for the generation of digital signatures and for other PKI-applications.
Subject End Entity that uses the private End Entity key (EE key). The End Entity may differ from the Subscriber.
Subscriber Subscriber for all certificates issued by the Product PKI is the respective Tenant as legal entity. See also section 1.3.3.
Tenant Tenant can be every Siemens AG organizational unit or any other legal entity that has a contract in place that covers Product PKI services. The Tenants typically operate and maintain the Registration Authorities (e.g. within their production facilities or data center). In such a case the Tenants are responsible for RA operation and End Entity authentication.
Tenant PMA PMA that is responsible for the management and operation of the local Product PKI Certificate Management components such as RA and/or LRA as well as for identification of End-Entities.
Token Transport-medium for certificates and keys.
Trust Center The term "Trust Center" refers to assets and components that are centrally operated and maintained at the Trust Center location as well to the respective processes.
Trusted Operator Product PKI has the overall responsibility of issuing certificates to Subjects and managing and revoking certificates. Tenants may delegate parts of these functions to the Central Product PKI Certificate Management Service or to other internal Service Providers of Siemens, which are called Trusted Operators.

1.6.2 Acronyms

Acronym Meaning
ARL Authority Revocation List
CA Certification Authority
CISO Chief Information Security Officer
CMP Certificate Management Protocol (RFC 9810)
CN Common Name
CP Certificate Policy
CPS Certification Practice Statement
CRL Certificate Revocation List
DN Distinguished Name
EE End Entity
FIPS Federal Information Processing Standard
FQDN Fully qualified domain name
HSM Hardware Security Module
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IDevID Initial Device Identifier (IEEE 802.1AR)
ISO International Organization for Standardization
ISMS Information Security Management System
LDevID Locally significant Device Identifier (IEEE 802.1AR)
LRA Local Registration Authority
OCSP Online Certificate Status Protocol
OID Object Identifier
PIN Personal Identification Number
PKI Public Key Infrastructure
PPKI Product PKI
PMA Policy Management Authority
RA Registration Authority
RFC Request for Comment
SLA Service Level Agreement
URL Uniform Resource Locator
UTF8 Unicode Transformation Format-8

2 Publication and Repository Responsibilities

2.1 Repositories

Tenant specific Product PKI Repositories are operated by trusted service provider(s).

The repository responsibilities include:

  • accurately publishing information;
  • archiving certificates;
  • publishing the status of certificates;
  • promptness or frequency of publication; and
  • security of the repository and controlling access to information published on the repository to prevent unauthorized access and tampering.

Subjects and Relying Parties have access to the Certificate Revocation List (CRL) via the URL specified in section 1.5.1.

2.2 Publication of Certification Information

The Tenant publishes the publicly available information via the URL specified in section 1.5.1.

At a minimum the following information is published:

  • all required certificates to trust the _Root CA_s;
  • all Issuing CA certificates;
  • revocation information for Root CA and Issuing CA certificates and for end entity certificates;
  • possible compromise of used algorithms or associated parameters.

2.3 Time or Frequency of Publication

Updates to this CP and the Central CP are published in accordance with the definitions in section 9.12 of this document.

2.4 Access Controls on Repositories

Information published in the repository is accessible with read-only access from the Internet.

Administration of the published information shall be carried out only by trusted roles with adequate access control restrictions.

3 Identification and Authentication

3.1 Naming

3.1.1 Types of Names

The complete policy of specifying names and CA certificate profiles is documented for each certificate type in the respective Certificate Profile documentation [CPD], which can be retrieved on request.

3.1.2 Need of Names to be Meaningful

3.1.2.1 CA Names

The CN must be stated as the full name of the CA.

3.1.2.2 End Entity Names

For details see Certificate Profile Documentation [CPD].

3.1.3 Anonymity or Pseudonymity of Subscribers

3.1.3.1 CA Names

The use of pseudonyms for CA names is not permitted.

3.1.3.2 End Entity Names

The use of pseudonyms for End Entity names is not permitted.

3.1.4 Rules for Interpreting Various Name Forms

See Central CP.

3.1.5 Uniqueness of Names

3.1.5.1 CA Names

See Central CP.

3.1.5.2 End Entity Names

See Tenant CPS.

3.1.6 Recognition, Authentication, and Roles of Trademarks

See Central CP.

3.2 Initial Identity Validation

Applicants for certificates are End Entities. The applicant always acts on behalf of the Subscriber (Tenant).

A certificate shall be issued to a Subject only when

  • the Subject has submitted a certificate request and
  • the Subject or the RA confirm private key possession.

3.2.1 Method to Prove Possession of Private Key

For IDevID and LDevID certificates, the (L)RA shall guarantee that the End Entity is in possession of the private key or generates the key pair on behalf of the End Entity.

For signature certificates, the key pair is generated centrally within a Hardware Security Module (HSM).

3.2.2 Authentication of Organization Identity

See Central CP.

3.2.3 Authentication of Individual Identity

For IDevID and LDevID certificates the identity of devices shall be validated by checking the provided identity with production information.

For signature certificates the identity of the requester shall be validated.

3.2.4 Non-verified Subscriber Information

Only verified information is included into the certificate.

3.2.5 Validation of Authority

The (L)RA component shall additionally authenticate against the local database providing device specific information.

See Central CP for requests utilizing the WebRA.

3.2.6 Criteria for Interoperation

No interoperation with other communities of trust is foreseen.

3.3 Identification and Authentication for Re-key Requests

Re-keying is not supported unless specified in the tenant CPS.

3.3.1 Identification and Authentication for Routine Re-Key

Not supported unless specified in the tenant CPS.

3.3.2 Identification and Authentication for Re-Key After Revocation

Not supported.

3.4 Identification and Authentication for Revocation Requests

Revocation of Intermediate CA and Issuing CA certificates must be authorized by the Tenant PMA.

Revocation of Intermediate CA and Issuing CA certificates shall only be performed manually by Product PKI trusted employees under dual control.

Revocation request of End-Entity certificates can be performed by Product PKI trusted employees (manually) and the corresponding authorized RA (automatically).

Revocation requests from subjects or relying parties are currently not foreseen.

4 Certificate Lifecycle Operational Requirements

4.1 Certificate Application

4.1.1 Who can submit a certificate application?

4.1.1.1 Root and Intermediate CA

See Central CP.

4.1.1.2 Issuing CAs

See Central CP.

4.1.1.3 (L)RA and EE certificates

Only certification requests from authorized devices or authorized personnel shall be processed by the (L)RA.

4.1.2 Enrollment Process and Responsibilities

4.1.2.1 CA Certificates

For CA certificates to be generated, the following information shall be documented:

  • A name for the CA in accordance with regulations in section 3.1, "Naming", of this CP
  • Date of the request
  • Duration of the CA certificate, which cannot exceed the duration of the Root CA's certificate
  • Certificate profile of the new CA and
  • Profiles of the End Entity certificates to be signed by that new CA, in case of an Issuing CA.
4.1.2.2 End Entity Certificate

End-Entity certificate applicants undergo an enrollment process consisting of:

  • generating, or arranging to have generated, a key pair;
  • completing a certificate application and providing the required information;
  • either demonstrating to the respective RA or CA that the certificate applicant has possession of the private key corresponding to the public key included in the certificate application, or guaranteeing by comparable measure that the certification request is originating from a legitimate End-Entity and that the End-Entity controls the private key.

Certificate applications are submitted for processing, either approval or rejection, to the respective RA.

4.2 Certificate Application Processing

4.2.1 Performing identification and authentication functions

Certificate applicants (= "Subjects") shall be properly identified and authenticated.

4.2.2 Approval or Rejection of Certificate Applications

After a certificate applicant submits a certificate application, the (L)RA shall approve or reject it.

4.2.3 Time to Process Certificate Applications

See Central CP.

4.3 Certificate Issuance

4.3.1 CA Actions during Certificate Issuance

A Certificate is created and issued using secure means after the approval of a certificate application.

For IDevID and LDevID certificates, the Product PKI shall:

  • check authorization of the respective RA by validating the signature of the certification request,
  • generate for the Subject a Certificate based on the information in the certificate application after its validation, and
  • deliver the Certificate through the respective RA.

For other types of certificates, the detailed requirements are described in the relevant CPS.

4.3.2 Notification to Subscriber by the CA of Issuance of Certificate

The CA shall inform the RA whether an EE Certificate has been generated or that the certification request could not be successfully executed.

4.4 Certificate Acceptance

4.4.1 Conduct constituting certificate acceptance

For IDevIDs, the Subjects shall securely obtain the Certificate through the respective RA.

For signature certificates, no certificate acceptance is required.

For CA certificates, see Central CP.

4.4.2 Publication of the certificate by the CA

No stipulation.

4.4.3 Notification of Certificate issuance by the CA to other entities

No stipulation.

4.5 Key Pair and Certificate Usage

The Issuing CA private key is only used for:

  • Issuance of certificates to End-Entities
  • Issuance of Issuing CA's CRLs
  • Issuance of CRL signer certificates and OCSP signer certificates
  • Signing of CMP messages sent to the RA

4.5.1 Subject Private Key and Certificate Usage

See Central CP.

4.5.2 Relying Party Public Key and Certificate Usage

See Central CP.

4.6 Certificate Renewal

Certificate renewal without changing the public key is supported only for certificate types and use cases explicitly defined in the applicable Tenant CPS. For Manufacturer Device Certificates / IDevID-like certificates, renewal is intended only for exceptional cases where the end entity cannot generate a new key pair. Operational, infrastructure, and signature certificate renewal or update behavior shall be defined separately in the applicable profile.

4.6.1 Circumstance for Certificate Renewal

Certificate renewal is allowed only for certificate types and use cases explicitly defined in the applicable Tenant CPS. For Manufacturer Device Certificates / IDevID-like certificates, renewal is intended only for exceptional cases where the end entity cannot generate a new key pair. For Operational, Infrastructure, and Signature Certificates, renewal or certificate update behavior is defined in the applicable Tenant CPS.

4.6.2 Who may request renewal?

Only authorized LRAs may request renewal on behalf of a device.

4.6.3 Processing Certificate Renewal Request

Renewing requests from authorized LRAs will be processed by the respective Issuing CA.

4.6.4 Notification of new Certificate Issuance to Subscriber

No additional stipulation.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate

No additional stipulation.

4.6.6 Publication of the Renewal Certificate by the CA

No additional stipulation.

4.6.7 Notification of Certificate Issuance by the CA to other Entities

No additional stipulation.

4.7 Certificate Re-key

See Central CP.

4.7.1 Circumstances for Certificate Re-key

See Central CP.

4.7.2 Who may request certification of a new Public Key?

4.7.2.1 Re-keying of an Issuing CA certificate

See Central CP.

4.7.2.2 Re-keying of End Entity certificates

Re-keying of End-Entity certificates is not supported unless explicitly specified in the applicable Tenant CPS. Where re-keying is supported, the same requirements apply as for certificate issuance (see section 4.3). Previously validated information must not be reused.

4.7.3 Processing Certificate Re-keying Requests

See section 4.3.1.

4.7.4 Notification of new Certificate Issuance to Subscriber

See section 4.3.2.

4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate

See section 4.4.1.

4.7.6 Publication of the Re-keyed Certificate by the CA

See section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to other Entities

See section 4.4.3.

4.8 Certificate Modification

No stipulation.

4.8.1 Circumstance for Certificate Modification

No stipulation.

4.8.2 Who may request Certificate modification?

No stipulation.

4.8.3 Processing Certificate Modification Requests

No stipulation.

4.8.4 Notification of new Certificate Issuance to Subscriber

No stipulation.

4.8.5 Conduct Constituting Acceptance of Modified Certificate

No stipulation.

4.8.6 Publication of the Modified Certificate by the CA

No stipulation.

4.8.7 Notification of Certificate Issuance by the CA to Other Entities

No stipulation.

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for Revocation

See Central CP.

In addition, there might be product or production specific circumstances that require revocation. These additional circumstances then are described in the respective tenant specific CPS.

4.9.2 Who can request revocation?

Revocation of end entity certificates shall be only performed by authorized personnel (e.g. the personnel who is performing initial device authentication).

The revocation of end entity certificates shall be authorized by the tenant PMA.

4.9.3 Procedure for Revocation Request

See Central CP.

In addition, the tenant PMA can request to revoke issuing CA certificates by sending a digitally signed email to the PPKI central service (trusted operator).

4.9.4 Revocation Request Grace Period

See Central CP.

4.9.5 Time within which CA must Process the Revocation Request

See Central CP.

4.9.6 Revocation Checking Requirement for Relying Parties

Relying Parties shall check the status of certificates on which they wish to rely by consulting the most recent CRL, which is published via the URL specified in section 1.5.1.

4.9.7 CRL Issuance Frequency

ARLs shall be issued at a maximum interval of 6 months, or immediately in exceptional cases when a specific CA certificate needs to be revoked.

CRLs shall be issued at a maximum interval of 2 months, or immediately after a respective end entity certificate has been revoked.

4.9.8 Maximum Latency for CRLs

CRLs shall be posted to the repository within a reasonable time after generation.

4.9.9 On-line Revocation/Status Checking Availability

Not supported.

4.9.10 On-line Revocation Checking Requirements

No stipulation.

4.9.11 Other Forms of Revocation Advertisements Available

See Central CP.

4.9.12 Special Requirements for Private Key Compromise

In case of a CA certificate compromise the device owners shall be informed.

If the tenant or a relying party has a reason to believe that there has been a compromise of an EE private key, then it will notify the respective Issuing CA to take appropriate action, including request for revocation.

See also Central CP for central service aspects.

4.9.13 Circumstances for Suspension

No stipulation.

4.9.14 Who can request suspension?

No stipulation.

4.9.15 Procedure for suspension request

No stipulation.

4.9.16 Limits on suspension period

No stipulation.

4.10 Certificate Status Services

4.10.1 Operational Characteristics

See section 4.9.

4.10.2 Service Availability

The service to retrieve CRLs shall be available twenty-four (24) hours a day, seven (7) days a week, except in case of Force Majeure Events (see Central CP section 9.16.5).

4.10.3 Optional Features

No stipulation.

4.11 End of Subscription

See Central CP.

4.12 Key Escrow and Recovery

Not supported.

4.12.1 Key Escrow and Recovery Policy and Practices

No stipulation.

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation.

5 Management, Operational, and Physical Controls

This chapter sets forth security controls for local, decentralized, tenant-controlled components such as (Local) Registration Authorities. Those controls will be fulfilled by the Trusted Operator role holders that operate outside the Siemens Trust Center scope, e.g. (Local) Registration Authorities, and are typically bound to a production site and its restrictions.

Requirements for the Central Product PKI system are set forth in the Central CP [CCP].

5.1 Physical Security Controls

5.1.1 Site Location and Construction

The (L)RAs shall be located in Siemens Digital Industries production facilities inside the production building or related building in a dedicated, access-controlled room.

The RA instances are hosted on industrial-grade hardware (e.g., Siemens IPCs) located within access-controlled production cells or dedicated server rooms at DI manufacturing sites. Physical protection must be equivalent to the security level of the production line it serves.

See also Central CP for central service aspects.

5.1.2 Physical Access

Access to the sites shall be allowed only to authorized persons.

Access to the (L)RAs shall implement additional access control. Only (L)RA operators shall be able to physically access the (L)RA.

See also Central CP for central service aspects.

5.1.3 Power and Air Conditioning

Buildings hosting (L)RAs shall be equipped with adequate power and air conditioning of the production.

See also Central CP for central service aspects.

5.1.4 Water Exposure

Buildings hosting (L)RAs shall be protected against water exposure.

See also Central CP for central service aspects.

5.1.5 Fire Prevention and Protection

Buildings hosting (L)RAs shall be equipped with fire prevention and protection.

See also Central CP for central service aspects.

5.1.6 Media Storage

No sensitive data shall be stored on external media.

See also Central CP for central service aspects.

5.1.7 Waste Disposal

Components containing sensitive data shall be disposed according to the classification of the contained data.

See also Central CP for central service aspects.

5.1.8 Off-site Backup

No stipulation.

See also Central CP for central service aspects.

5.2 Procedural Controls

5.2.1 Trusted Roles

Trusted roles in the production environment comprise:

  • (L)RA administrator: person that administers the (L)RA, in particular this role defines the access control rights to the server hosting the (L)RA software.
  • (L)RA operator: person that configures and performs trouble shooting of the (L)RA.

See also Central CP for central service aspects.

5.2.2 Numbers of Persons Required per Task

No stipulation.

See also Central CP for central service aspects.

5.2.3 Identification and Authentication for Each Role

Two factor authentication should be used for sensitive tasks.

See also Central CP for central service aspects.

5.2.4 Roles Requiring Separation of Duties

No stipulation.

5.3 Personnel Controls

5.3.1 Qualifications, Experience and Clearance Requirements

Personnel operating PKI components in production sites shall have appropriate qualification and experience with PKI component and IT system operation.

See also Central CP for central service aspects.

5.3.2 Background Check Procedures

Personnel performing Trusted Roles in production shall be checked in line with the position they fulfill.

See also Central CP for central service aspects.

5.3.3 Training Requirements

Appropriate security trainings shall be performed for Trusted Operator roles.

See also Central CP for central service aspects.

5.3.4 Retraining Frequency and Requirements

Trusted Operator roles shall receive appropriate re-trainings.

See also Central CP for central service aspects.

5.3.5 Job Rotation Frequency and Sequence

No stipulation.

5.3.6 Sanctions for Unauthorized Actions

See Central CP.

5.3.7 Independent Contractor Requirements

See Central CP.

5.3.8 Documents Supplied to Personnel

See Central CP.

5.4 Audit Logging Procedures

5.4.1 Types of Events Recorded

The following (L)RA security related events shall be logged:

  1. Key lifecycle management events of (L)RA specific keys, including: a. Key generation, backup, storage, recovery, archival, and destruction; b. Cryptographic device lifecycle management events.
  2. Subscriber certificate lifecycle management events, including: a. Certificate requests, renewal and re-key requests, and revocation; b. All verification activities stipulated in these Requirements; c. Acceptance and rejection of certificate requests by the (L)RA; d. Issuance of certificates or rejection of certificate requests by the CA.
  3. Security events, including: a. Successful and unsuccessful (L)RA system access attempts; b. (L)RA and security system actions performed; c. Security profile changes; d. System crashes, hardware failures, and other anomalies; e. Firewall and router activities; and f. Physical access to the (L)RA.

Log entries shall include the following elements:

  1. Date and time of entry;
  2. Identity of the entity, person or technical component making the journal entry; and
  3. Description of the entry.

See also Central CP for central service aspects.

5.4.2 Frequency of Processing Log

See Central CP.

5.4.3 Retention Period for Audit Log

Production site specific audit logs (in particular of the (L)RAs) shall be retained for at least three (3) years.

See also Central CP for central service aspects.

5.4.4 Protection of Audit Log

Automatically created audit logs shall be integrity protected. Audit logs shall be protected from unauthorized viewing, modification, destruction, or any other form of tampering.

See also Central CP for central service aspects.

5.4.5 Audit Log Backup Procedures

Audit logs are backed up and archived as defined in section 5.5.

5.4.6 Audit Collection System (Internal vs. External)

No stipulation for Tenant specific audit logs.

See also Central CP for central service aspects.

5.4.7 Notification to Event-Causing Subject

See Central CP.

5.4.8 Vulnerability Assessments

Production site specific Product PKI infrastructure (e.g. (L)RA and corresponding routers) shall be regularly checked for vulnerabilities.

See also Central CP for central service aspects.

5.5 Records Archival

5.5.1 Types of Records Archived

All issued certificates shall be archived.

See also Central CP for central service aspects.

5.5.2 Retention Period for Archived Audit Logging Information

The archived data as specified in section 5.5.1 shall be retained for ten (10) years.

See also Central CP for central service aspects.

5.5.3 Protection of Archive

Protection of archived records shall be performed in accordance with Siemens ISMS [ISMS]. No unauthorized user shall be permitted to write to, modify, or delete the archive.

Archived records shall be hosted in multiple locations. These locations shall be equipped with adequate monitoring and protected against theft or unauthorized destruction, alteration or loss, as set forth in the ISMS [ISMS] regulations.

5.5.4 Archive Backup Procedures

Adequate backup procedures shall be established to protect archived backup records against theft or unauthorized destruction, alteration or loss. The technical implementation shall be detailed in the relevant CPS.

5.5.5 Requirements for Time-Stamping of Record

See Central CP.

5.5.6 Archive Collection System (internal or external)

All archived data shall be stored as described in section 5.5.3.

5.5.7 Procedures to Obtain and Verify Archived Information

See Central CP.

5.6 Key Changeover

Key changeover for EE keys is not supported.

See also Central CP for central service aspects.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

See Central CP.

5.7.2 Corruption of Computing Resources, Software, and/or Data

See Central CP.

5.7.3 Entity Private Key Compromise Procedures

See Central CP.

5.7.4 Business Continuity Capabilities After a Disaster

See Central CP.

5.8 CA or RA Termination

Should the Tenant need to revoke an issuing CA or (L)RA certificate, they shall immediately notify Product PKI via the defined procedure.

6 Technical Security Controls

Requirements from Central CP [CCP] are also applicable in this section.

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

For IDevID and LDevID certificates, the end entity keys shall be either generated by the subject itself (typically device) or in case the subject is not able to generate such keys by the LRA where the device is connected to; the private key must be transmitted over a physically protected or encrypted local link.

If the device has access to a dedicated security module, then this module shall be used for key generation and storage.

For signature certificates, key pairs are generated centrally using HSMs. The generation procedure guarantees that the private key never leaves the cryptographic boundary of the HSM.

See also Central CP for central service aspects.

6.1.2 Private Key Delivery to Subscriber

In case a RA requests a Key Pair as subscriber, the corresponding private key shall be secured via technical and/or organizational means.

If keys are generated by the (L)RA, the communication between (L)RA and device shall be protected.

For signature certificates, the private key delivery process is detailed in the respective CPS.

6.1.3 Public Key Delivery to Certificate Issuer

See Central CP.

6.1.4 CA Public Key Delivery to Relying Parties

The certificates of Siemens CA shall be published to Relying Parties for certificate path validation purposes. Siemens CAs' Public Keys shall be published at the repository specified in section 1.5.1.

6.1.5 Key Sizes

Minimum requirements for key sizes and algorithms are defined in accordance with [BSI] and [NIST].

6.1.6 Public Key Parameters Generation and Quality Checking

CAs and subscribers shall generate Key Pairs using secure algorithms and parameters based on state-of-the-art cryptography and industry standards.

6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field)

See Central CP.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

In case Issuing CAs are operated outside the central service:

Key Pairs shall be generated and hosted in Hardware Security Modules, certified at FIPS 140-3 level 3. Additional controls on the cryptographic module include but are not limited to:

  • Multi-Person control required to access the hosting facility and to manage the cryptographic modules (see section 6.2.2);
  • Cryptographic modules shall be hosted in a physically secured facility (see section 5.1);
  • Cryptographic modules shall make use of only state of the art cryptographic algorithms and industry standards.

No specific standards apply for security modules of devices. The information about used security module (if applicable) shall be documented in the product data sheet.

See also Central CP for central service aspects.

6.2.2 Private Key (n out of m) Multi-person Control

No n out of m multi person control is applied for end entity keys.

See also Central CP for central service aspects.

6.2.3 Private Key Escrow

Not supported.

6.2.4 Private Key Backup

Under no circumstances shall a Subject private key be backed up.

See also Central CP for central service aspects.

6.2.5 Private Key Archival

No stipulation.

6.2.6 Private Key Transfer into or from a Cryptographic Module

Not supported for end entity keys. This does not limit the initial protected delivery of a key generated by an LRA on behalf of an End Entity as described in section 6.1.1.

See also Central CP for central service aspects.

6.2.7 Private Key Storage on Cryptographic Module

If technically feasible end entity keys shall be stored in a security module.

Private keys for manufacturer data signing must be stored in a central HSM certified at FIPS 140-3 level 3. These keys are generated internally and shall not be extracted or misused.

See also Central CP for central service aspects.

6.2.8 Method of Activating Private Key

End entity private keys shall be automatically active after generation.

See also Central CP for central service aspects.

6.2.9 Method of Deactivating Private Key

Deactivating Private Keys is not supported.

6.2.10 Method of Destroying Private Key

If technically possible, the end entity private keys shall be deleted in case of a factory hard reset.

See also Central CP for central service aspects.

6.2.11 Cryptographic Module Rating

See section 6.2.1.

6.3 Other Aspects of Key Pair Management

6.3.1 Public key archival

Public key and related certificate shall be archived in accordance with section 5.5.

CA Public Keys of emergency systems shall be backed up centrally as well as locally and shall be archived as part of the routine backup procedures.

6.3.2 Certificate operational periods and key pair usage periods

The respective maximum validity periods for keys are:

Certified Entity Validity Period
Root CA certificate Up to thirty-six (36) years
Issuing CA certificate Up to thirty-five (35) years
End Entity certificate Up to twenty-five (25) years

Table 1: Maximum validity periods

See also Central CP for central service aspects.

6.4 Activation Data

6.4.1 Activation Data Generation and Installation

No activation data for end entity keys shall be used.

See also Central CP for central service aspects.

6.4.2 Activation Data Protection

See Central CP.

6.4.3 Other Aspects of Activation Data

See Central CP.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

Specific computer security requirements for (L)RAs are defined in [ISMS].

See also Central CP for central service aspects.

6.5.2 Computer Security Rating

No stipulation.

6.6 Life Cycle Security Controls

6.6.1 System Development Controls

See Central CP.

6.6.2 Security Management Controls

(L)RA security management controls shall follow regulations equivalent to Siemens ISMS.

See also Central CP for central service aspects.

6.6.3 Life Cycle Security Controls

See Central CP.

6.7 Network Security Controls

The (L)RA network security controls shall follow regulations equivalent to Siemens ISMS.

See also Central CP for central service aspects.

6.8 Time Stamp Process

See Central CP.

7 Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

Details of the tenant specific certificate profile can be found in the respective checklists [CPD]. The checklist will not be published, but an extract can be provided on request.

Siemens Norm 60451 is used as the profile reference for Manufacturer Device Certificates / IDevID-like certificates where applicable. Profiles for LDevID, Operational Certificates, Infrastructure Certificates, and signature certificates are defined in the applicable Certificate Profile Documentation and Tenant CPS.

See also Central CP for central service aspects.

7.1.1 Version Number(s)

See Central CP.

7.1.2 Certificate Extensions

See Central CP.

7.1.3 Algorithm Object Identifiers

Product PKI shall issue Subject certificates using only algorithms that are compatible with section 6.1.5.

7.1.4 Name Forms

Product PKI shall only issue Subject certificates whose Issuer and Subject information is consistent with the Tenant CP.

7.1.5 Name Constraints

Name Constraints set by Product PKI in Subject certificates shall be consistent with the Tenant CP.

7.1.6 Certificate Policy Object Identifier

Subordinate CA certificates and Subject certificates issued under this CP shall assert one or more of the Certificate Policy OIDs listed in section 1.2 of this Certificate Policy. Issuing CA certificates shall contain the policy OIDs of all policies under which they issue certificates.

If OIDs are present the following applies.

Digital certificates use Object Identifiers (OIDs) to uniquely identify objects like data structures, algorithm definitions, or key usages. OIDs are structured in a hierarchical manner. They are not only used by digital certificates but in a variety of protocols.

7.1.6.1 Definition of OIDs

Object Identifiers are strings of numbers with dots as separators. They are allocated in a hierarchical manner, so that each number represents an authority. For instance, the authority for "1.2.3" is the only one that can say what "1.2.3.4" means. They are used in a variety of frameworks and protocols.

The formal definition of OIDs comes from ITU-T X.680 (ASN.1).

Each position in an OID sequence identifies a node in a tree structure. The ASN.1 standard assigns each node a name and meaning. E.g., the positions in the OID 1.2.840.10045.4.3.4 represent the following tree nodes:

iso(1).member-body(2).us(840).ansi-x962(10045).signatures(4).ecdsa-with-SHA2(3).ecdsa-with-SHA512(4)

This OID string as defined by ANSI is the identifier for the Elliptic Curve Digital Signature Algorithm (ECDSA) coupled with the hash algorithm SHA-512.

7.1.6.2 Enterprise numbers

The Internet Assigned Numbers Authority (IANA) is a department of the Internet Corporation for Assigned Names and Numbers (ICANN) responsible for coordinating some of the key elements that keep the Internet running smoothly. Whilst the Internet is renowned for being a worldwide network free from central coordination, there is a technical need for some key parts of the Internet to be globally coordinated and this coordination role is undertaken by IANA.

Specifically, IANA allocates and maintains unique codes and numbering systems that are used in the technical standards (frameworks and protocols) that drive the Internet.

Private enterprise numbers (PENs) are a subset of Object Identifiers, starting with the prefix 1.3.6.1.4.1 and representing the following path in the ASN.1 tree:

iso(1).org(3).dod(6).internet(1).private(4).enterprise(1)

A company or organization may apply for a private enterprise number to use these numbering systems without conflicting with other companies and users. This number is assigned by the IANA and is appended to the OID string above.

7.1.6.3 Siemens OIDs

The Enterprise Number of Siemens AG is 4329. So, all OIDs starting with 1.3.6.1.4.1.4329 are Siemens specific. The position behind the 4329 identifies Siemens organizations, services, and applications. The top-level OIDs below 4329 are centrally managed, currently by T TIM RSQ TMR, Ms. Uschi Obermeier, GID:Z0004FTO.

7.1.6.4 Product PKI CP/CPS Document OIDs

The OID 1.3.6.1.4.1.4329.99.1.2 is reserved in the Siemens MIB for the documents related to Siemens Certificate Policies of Siemens Product PKI.

Hierarchically subordinated under this OID the Siemens PKI services manage an OID sub-tree to identify objects relevant for its operation like organizational units and document versions. Currently this sub-tree consists of the nodes x indicating the Product PKI tenant, y indicating the major version of the document (1.3.6.1.4.1.4329.99.1.2.x.y).

7.1.6.4.1 Tenant

The first position in the Siemens Product PKI OID sub-tree identifies the tenant of the Siemens Product PKI service. A tenant is a part of the Siemens Product PKI system which is provided to one organization (usually a Siemens BU or factory) acting as customer of the Siemens Product PKI service. The Siemens Product PKI service hosts a dedicated set of Root and/or Issuing CAs for each tenant.

The OID 1.3.6.1.4.1.4329.99.1.2.1 identifies the first tenant of the Siemens Product PKI service. This number is incremented for each new tenant. All objects related to this tenant start with this sequence.

The number 1000 identifies a special tenant – the Siemens Product PKI service itself. All objects not related to a dedicated tenant but to the central Siemens Product PKI service are identified by OIDs starting with 1.3.6.1.4.1.4329.2.1000.

7.1.6.4.2 Document version number

The version number of the Certificate Policy (CP) is identified by the next position.

Changes, which will materially change the acceptability of certificates for specific purposes, will lead to a corresponding change in the CP OID.

Changes, which will not materially reduce the assurance that the CP or its implementation provides and will be judged by the Policy Management Authority to have an insignificant effect on the acceptability of certificates, do not require a change in the CP OID.

7.1.6.5 Product PKI certificate type and key store OIDs

The OID 1.3.6.1.4.1.4329.38 is reserved in the Siemens MIB for the Product PKI services. Hierarchically subordinated under this OID the Product PKI services manage an OID sub-tree to identify objects relevant for its operation like documents, organizational units, services, and certificate types. Currently this sub-tree consists of the nodes x indicating the Product PKI tenant, y indicating the certificate type, and z indicating the type of key storage (1.3.6.1.4.1.4329.38.x.y.z).

7.1.6.5.1 Tenant

The first position in the Siemens Product PKI OID sub-tree identifies the tenant of the Siemens Product PKI service. A tenant is a part of the Siemens Product PKI system which is provided to one organization (usually a Siemens BU or factory) acting as customer of the Siemens Product PKI service. The Siemens Product PKI service hosts a dedicated set of Root and/or Issuing CAs for each tenant.

The OID 1.3.6.1.4.1.4329.38.1 identifies the first tenant of the Siemens Product PKI service. This number is incremented for each new tenant. All objects related to this tenant start with this sequence.

The number 1000 identifies a special tenant – the Siemens Product PKI service itself. All objects not related to a dedicated tenant but to the central Siemens Product PKI service are identified by OIDs starting with 1.3.6.1.4.1.4329.38.1000.

7.1.6.5.2 Certificate Type

The type of certificate is identified by the next position. The following certificate categories are defined:

  • Manufacturer Certificates (OID 1.3.6.1.4.1.4329.38.x.1) These certificates identify Siemens hardware devices during their whole existence. Usually, the certificates' validity conforms to the expected lifetime of the devices. Renewal of these certificates is foreseeable only in exceptional cases, but revocation and the publication of appropriate status information is required by the manufacturer.
  • Operational Certificates (OID 1.3.6.1.4.1.4329.38.x.2) This category includes all certificates issued by a tenant for usage by devices, applications, or persons (e.g. service technicians) during regular operation at the end customer site. The applications may be running directly on the devices or on arbitrary hardware (e.g., PCs or virtual machines). Examples are certificates for TLS session establishment (TLS client and/or server certificates), VPN, or for signing of log data. Operational certificates have a limited lifetime and need to be managed after issuance. Also, revocation and the publication of appropriate status information may be required for these certificates.
  • Infrastructure Certificates (OID 1.3.6.1.4.1.4329.38.x.3) These are the certificates used by the Siemens Product PKI service to secure its own operational processes. Infrastructure Certificates are used, e.g., for TLS based client-server-authentication between the single components of the Siemens Product PKI service (like LRA and CMP Gateway) or for the signing of CMP messages by these components. Infrastructure Certificates have to be renewed regularly and may be revoked on demand. Certificate status information must be available via OCSP and CRLs.
  • Signature Certificates for Manufacturer Data (OID 1.3.6.1.4.1.4329.38.x.4) These certificates identify Siemens code, licenses, device specific configurations, product information, etc. by digitally signing such data. The validity of these certificates conforms to the expected lifetime of devices, similar to the Manufacturer Certificates. The actual usage time may be much shorter so frequent certificate updates may be required. Furthermore, revocation and publication of appropriate status information by the manufacturer are required.
  • Signature Certificates for Third Party Usage (OID 1.3.6.1.4.1.4329.38.x.5) These certificates are similar to Signature Certificates used by the manufacturer, but given to Siemens' partners (e.g., system integrators, value-add partners, OEM manufacturers) to identify their data (code, device specific configurations, etc.) by digitally signing. The validity of these certificates may also conform to the expected lifetime of related devices. The actual usage time may be much shorter so frequent certificate updates may be required. Furthermore, revocation and publication of appropriate status information by the manufacturer (who gives the certificates to partners) are required.
7.1.6.5.3 Key Store

The final position in the OID string denotes the type of key store:

  • Secure Device – internal generation (OID 1.3.6.1.4.1.4329.38.x.y.1) This OID indicates that the private key corresponding to the public key in the certificate is created and stored inside a secure element that applies hardware-based security mechanisms to prevent reading/extraction or misusing the private key. The private key only exists inside the secure element. Examples for such secure elements are embedded security controllers, smart cards or hardware security modules.
  • Software Key Store (OID 1.3.6.1.4.1.4329.38.x.y.2) The corresponding private key is stored in a software based Personal Security Environment. This is usually an encrypted file (e.g., according to the PKCS#12 standard).
  • Secure Device – external generation (OID 1.3.6.1.4.1.4329.38.x.y.3) This OID indicates that the private key is created outside but imported into and stored inside a secure element that applies hardware-based security mechanisms to prevent reading/extraction or misusing the private key. The private key may exist also outside the secure element.

The information on the key store is important for certificate users to determine the trust level of the certificate. Secure Device based key stores should offer a much higher level of security compared to software-based key stores.

7.1.7 Usage of Policy Constraints Extension

No stipulation.

7.1.8 Policy Qualifiers Syntax and Semantics

No stipulation.

7.1.9 Processing Semantics for the Critical Certificate Policies Extension

Critical Certificate Policy extension shall conform to IETF RFC 5280 [RFC5280].

7.2 CRL Profile

7.2.1 Version number(s)

See Central CP.

7.2.2 CRL and CRL entry extensions

See Central CP.

7.3 OCSP Profile

7.3.1 Version Number(s)

See Central CP.

7.3.2 OCSP Extension

See Central CP.

8 Compliance Audit and Other Assessment

8.1 Frequency or Circumstances of Assessment

Tenant's compliance to this CP and the relevant CPSs shall be checked at least on a bi-annual basis. In addition, a bi-annual asset classification of the Tenant PKI components takes place. The asset classification is performed in accordance with the Siemens Enterprise Risk Management Process [ERM]. A possible outcome of either the audit or the asset classification is the adaption of the implemented security mechanisms and controls, which may result in changes in CP and CPSs.

See also Central CP for central service aspects.

8.2 Identity / Qualifications of Assessor

Compliance audits shall be performed by a qualified auditor.

See also Central CP for central service aspects.

8.3 Assessor's Relationship to Assessed Entity

The assessor shall be organizationally independent from the assessed entity's operational authority.

See also Central CP for central service aspects.

8.4 Topics Covered by Assessment

See Central CP.

8.5 Actions Taken as a Result of Deficiency

If a compliance audit or other assessments show deficiencies of the assessed entity, a determination of actions to be taken shall be made. This determination is made by Tenant PMA with input from the auditor/assessor. Tenant PMA is responsible for developing and implementing a corrective action plan.

If Tenant PMA determines that such deficiencies pose an immediate threat to the security or integrity of the Product PKI or the respective Tenant, a corrective action plan shall be developed in accordance with the incident response procedures described in section 5.7.1 within thirty (30) days and implemented within a commercially reasonable period of time, and a re-assessment is to be performed within thirty (30) days after completion of the corrective action. For less serious deficiencies, Tenant PMA shall evaluate the significance of such issues and determine the appropriate response.

Possible actions taken include but are not limited to:

  • temporary suspension of operations until deficiencies are corrected
  • revocation of certificates issued to the assessed entity
  • changes in personnel
  • triggering special investigations or more frequent subsequent compliance assessments, and
  • claims for damages against the assessed entity

See also Central CP for central service aspects.

8.6 Communication of Results

An Audit Compliance Report, including identification of corrective measures taken or being taken by the component, shall be provided to the Tenant PMA.

All business and legal matters will be regulated within specific contracts. Such contracts cover the terms and conditions for the overall product, solution and/or service which includes the Product PKI Service.

9.1 PKI Fees

9.1.1 Certificate Issuance or Renewal Fees

No stipulation.

9.1.2 Certificate Access Fees

No stipulation.

9.1.3 Certificate Revocation or Status Information Access Fees

No stipulation.

9.1.4 Fees for other Services

No stipulation.

9.1.5 Refund Policy

No stipulation.

9.2 Financial Responsibility

No stipulation.

9.2.1 Insurance Coverage

No stipulation.

9.2.2 Other Assets

No stipulation.

9.2.3 Insurance or Warranty Coverage for End-Entities

No stipulation.

9.3 Confidentiality of Business Information

9.3.1 Scope of Confidential Information

The scope of confidential information is defined in the respective agreement signed by Siemens and the customer. Such agreement contains the terms and conditions for the delivery of the products, service and/or solutions ("Product Agreement"). In certain cases Siemens enters into separate non-disclosure agreements ("NDA").

Siemens' definition of Confidential Information usually covers all Siemens' proprietary information and is defined as follows in the standard agreements:

"Confidential information is any information marked or declared as confidential upon disclosure or the confidential nature of which is evident to a reasonable person. Confidential information does not include information that (i) is or becomes generally available to the public other than by violation of this NDA; (ii) becomes available to recipient from a source other than discloser, provided that recipient has no reason to believe that the information is subject to an obligation of confidentiality; (iii) was in recipient's possession without obligation of confidentiality prior to receipt from discloser; or (iv) is independently developed by recipient without the use of the confidential information. Recipient may disclose confidential information to the extent required by a governmental agency or law, provided that recipient gives written notice to discloser promptly upon receipt of notice of the required disclosure to the extent such notice is permitted by law, and cooperates with discloser to limit the scope of disclosure."

9.3.2 Information not within the Scope of Confidential Information

No stipulation.

9.3.3 Responsibility to Protect Confidential Information

Customer shall keep Confidential Information confidential and is allowed to use it for the purpose defined in the Product Agreement and/or the confidentiality undertaking.

9.4 Privacy of Personal Information

9.4.1 Privacy plan

Siemens fulfills all mandatory obligations under the applicable international data privacy laws and regulations.

To the extent Siemens processes personal data, the Siemens standard data processing agreements (DPA) are agreed with customer. Such agreements define the technical and organizational measures (TOMs) of the respective offering, including the Product PKI. In case Siemens engages with trusted service providers or any other type of subcontractors ("Subcontractors") such Subcontractors are listed in the Annex of the DPA. Both TOMs and the list of Subcontractors are updated regularly.

Siemens causes its Subcontractors to comply with requirements of applicable national data privacy protection laws when processing Personal Data, including the requirements of the GDPR.

Anonymous, pseudonymized or otherwise non-personal data is not deemed private within the Product PKI.

Siemens uses suitable organizational and technical information security measures to protect personal data against misuse or accidental or unlawful destruction, loss or alteration and unauthorized disclosure or access. Siemens causes its Subcontractors to comply with rules and measures which adhere to the Siemens internal standards.

Siemens will cause its Subcontractors to ensure that personal data is factually correct and – if necessary, up-to-date – and that appropriate measures are taken to assure that inaccurate or incomplete information is corrected or deleted and that customer's rights to information, rectification, erasure, blocking and objection are respected as provided under applicable data protection laws or corporate guidelines.

9.4.2 Information treated as private

Please refer to 9.4.1.

9.4.3 Information not deemed private

No stipulation.

9.4.4 Responsibility to protect private information

The responsibility to protect personal data and private information is with the respective Siemens entity that signs the Product Agreement. Rules and responsibilities are defined by the local corporate data privacy organization. The rules and regulations set forth in 9.4.1 are rolled out and governed globally. Any Siemens entity is bound by the respective rules.

The customer is notified via the data privacy terms where required. Otherwise, general data privacy notices are included in Siemens' internet pages. Siemens Product Agreements contain general data privacy provisions where necessary and where no specific stipulations are required.

9.4.6 Disclosure pursuant to judicial or administrative process

Disclosure of personal and confidential information is allowed where a mandatory court ruling or administrative order requires such disclosure.

Personal data necessary for important public interest grounds or for the establishment, exercise or defense of legal claims may be transferred in accordance with applicable data privacy protection law. The party to whom such personal data is transferred shall be advised that the personal data transferred may be processed or used only for the purpose for which it was transferred.

9.4.7 Other information disclosure circumstances

No stipulation.

9.5 Intellectual Property Rights

The allocation of Intellectual Property Rights (e.g., copyright, trademark) is governed by the respective Product Agreement.

9.5.1 Intellectual Property Rights in Certificates and Revocation Information

Siemens retains all Intellectual Property of its own services, the Product PKI, this CP and any products, issued by Siemens. In case Siemens engages with Subcontractors, such Subcontractors provide Siemens with the necessary rights required to sell, either itself or via its affiliates and external partners, the services, products and/or solutions which contain the Product PKI.

9.5.2 Intellectual Property Rights in CP

Siemens retains all Intellectual Property Rights in and to the CP and related basic Siemens PKI documents.

9.5.3 Intellectual Property Rights in Names

Siemens retains all title and interest in any of its trademarks, brands and trade names related and associated with its own business, products, services and/or solutions, including the Product PKI. Customer retains all rights it has (if any) in its own trademark or trade name contained in and needed for the use of the services, products and/or solutions, including the Product PKI.

9.5.4 Property rights of Certificate Owners

Any information gained within and/or by the Product PKI which does not relate to Siemens or any of its Subcontractors remains the property of the respective customer and/or user of the certificate.

9.6 Representations and Warranties

9.6.1 CA, RA representations and warranties

The representations and warranties Siemens provides are governed by the contractual terms agreed in the Product Agreement. Siemens usually warrants that the product and/or solution fulfills the agreed specification. Such specification contains the Product PKI and its functionalities. Siemens usually warrants that services are provided in a professional and workmanlike manner.

9.6.2 RA representations and warranties

Please refer to 9.6.1.

9.6.3 Subscriber representations and warranties

Please refer to 9.6.1.

9.6.4 Relying party representations and warranties

Please refer to 9.6.1.

9.6.5 Representations and warranties of other participants

No stipulation.

9.7 Disclaimers of Warranties

Siemens intends to limit its warranties to the repair or replacement of the defective products delivered. The Product PKI is considered part of the overall product.

9.8 Limitations of Liability

The limitation of liability is governed by the Product Agreement. Individual limitations of liability for the Product PKI are not foreseen. Siemens limits its liability to the amount of the volume of the Product Agreement. Siemens does not undertake any liability for indirect, incidental or consequential damages, loss of profit, loss of use, loss of data, loss of production and punitive damage.

9.9 Indemnities

If required by the customer, Siemens provides indemnifications for IPR infringement. The limitation of liability applies for such indemnifications.

9.10 Term and Termination

9.10.1 Term

The Term of this CP commences on the effective date published in section 1.2 and continues until terminated as provided in section 9.12.2.

9.10.2 Termination

This CP terminates if the Validity Period of the Siemens Root CA Certificates or Siemens Issuing CA Certificates expire and are not renewed or if it is otherwise necessary to terminate operation for any reason or if the customer stops using the Product PKI.

Before Siemens terminates its services at least the following procedures shall be executed:

  • Siemens shall inform the customer and each subscriber with which Siemens has agreements or other form of established relations.
  • Siemens shall destroy, or withdraw from use, its private keys.

9.10.3 Effect of Termination and Survival

No stipulation.

9.11 Individual Notices and Communication with Participants

Individual notices and communication shall be performed via email except as otherwise set forth in the Product Agreement.

9.12 Amendments

9.12.1 Procedure for Amendment

In the case of CP amendments, change procedures may include:

  • a notification mechanism to provide notice of proposed amendments to affected Product PKI Participants
  • a comment period; a mechanism by which comments are received, reviewed and incorporated into the document and
  • a mechanism by which amendments become final and effective

9.12.2 Notification Mechanism and Period

A modification or amendment of the CP/CPS leads to a new version of the CP/CPS.

The new version of the CP/CPS will be published after its release on the website stated in section 1.5.1.

9.12.3 Circumstances under which OID must be changed

Changes, which will not materially reduce the assurance that the CP or its implementation provides and will be judged by the Policy Management Authority (CP section 1.5) to have an insignificant effect on the acceptability of certificates, do not require a change in the CP OID.

Changes, which will materially change the acceptability of certificates for specific purposes, may require corresponding changes to the CP OID.

9.13 Dispute Resolution Provisions

No stipulation.

9.14 Governing Law

No stipulation.

9.15 Compliance with Applicable Law

No stipulation.

9.16 Miscellaneous Provisions

No stipulation.

9.16.1 Entire Agreement

No stipulation.

9.16.2 Assignment

No stipulation.

9.16.3 Severability

No stipulation.

9.16.4 Enforcement (attorneys' fees and waiver of rights)

No stipulation.

9.16.5 Force Majeure

Siemens shall not be held liable for violations of this CP due to causes that are reasonably beyond its control, including but not limited to, an event of Force Majeure, act of the authority, failure of equipment, failure of telecommunications lines, failure of internet access or any unforeseeable events.

9.17 Other Provisions

9.17.1 Order of Precedence of CP

This CP provides baseline requirements that are applicable to all CAs operated in the name of the Tenant. In the event of a conflict between this CP and any other documents, the following documents shall be given precedence with the same order of the list:

  1. Tenant Specific CP that is applicable to a Tenant operated by the Product PKI [this document]
  2. Siemens Product PKI Central CP
  3. Documentation executed or expressly authorized by Tenant PMA
  4. Documentation executed or expressly authorized by Central PMA

10 References

In case of legitimate interest, Siemens and Siemens Digital Industries internal regulations and guidelines as well as other internal documents can be retrieved on request.

[ACP] Asset Classification & Protection; https://intranet.siemens.com/acp

[BSI] BSI – Technical Guideline; Cryptographic Mechanisms: Recommendations and Key Lengths; BSI TR-02102-1, Version 2026-01; BSI TR-02102-1

[CCP] Siemens Product PKI Certificate Management Service – Central Certificate Policy; 2026, Version 2.2; www.siemens.com/pki

[CPD] Certificate Profile Documentation; latest checklist containing among others details of the applied certificate profile.

[ERM] Siemens Enterprise Risk Management; "Enterprise Risk Management – Integrated Framework"; https://intranet.for.siemens.com/cms/054/en/about/org/Pages/cf-a-erm-org.aspx and https://intranet.for.siemens.com/cms/080/de/processes/office/Pages/ric-ch-erm.aspx

[ETSI 401] ETSI EN 319 401; Electronic Signatures and Trust Infrastructures (ESI); General Policy Requirements for Trust Service Providers; 2026-01; Standards – ETSI

[ETSI 411] ETSI EN 319 411-1; Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements; 2025-04; Standards – ETSI

[FIPS] National Institute of Standards and Technology; SECURITY REQUIREMENTS FOR CRYPTOGRAPHIC MODULES; 2019; https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf

[IEEE802.1AR] IEEE 802.1AR; IEEE Standard for Local and Metropolitan Area Networks – Secure Device Identity; June 2018; https://standards.ieee.org/standard/802_1AR-2018.html

[IHP] The Siemens Incident Handling process as part of the ISMS; https://www.cert.siemens.com/incident-response/process/

[ISMS] SFeRA – Security Framework and Regulations Application; https://webapps.siemens.com/sfera

[ISO27001] ISO/IEC 27001; Information technology — Security techniques — Information security management systems — Requirements; 2022

[NIST] NIST SP 800-57 Part 1 Rev. 5; Recommendation for Key Management: Part 1 – General; May 2020; NIST SP 800-57 Part 1 Rev. 5

[RFC2119] IETF; RFC 2119; Key words for use in RFCs to Indicate Requirement Levels; March 1997.

[RFC3647] IETF; RFC 3647; Internet X.509 Public Key Infrastructure – Certificate Policy and Certification Practices Framework; November 2003.

[RFC5280] IETF; RFC 5280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile; May 2008; https://tools.ietf.org/html/rfc5280

[RFC8174] IETF; RFC 8174; Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words; May 2017.

[RFC9810] IETF; RFC 9810; Internet X.509 Public Key Infrastructure – Certificate Management Protocol (CMP); July 2025.

[TÜV] TÜV IT; Sichere Infrastrukturen für IT-Systeme – Trusted Site Infrastructure; Version 4.0; https://www.tuvit.de/fileadmin/user_upload/TUEViT_TSI_V4_0.pdf

[X.520] ITU-T; X.520 Information technology – Open Systems Interconnection – The Directory: Selected attribute types

© 2026 Siemens AG · Unrestricted