Certification Practice Statement (CPS) for Public API mTLS

Table of Contents

1. Introduction
2. Publication and Repository Responsibilities
3. Identification and Authentication
4. Certificate Life-Cycle Operational Requirements
5. Facility, Management, and Operational Controls
6. Technical Security Controls
7. Certificate, CRL, and OCSP Profiles
8. Compliance Audit and Other Assessments
9. Other Business and Legal Matters
10. Appendix A: References

1. Introduction

1.1 Overview

This Certification Practice Statement (CPS) describes the practices employed by Qualtrics, LLC. in operating the Public Api Client Certs Intermediate CA and in issuing X.509 client certificates for Mutual Transport Layer Security (mTLS) authentication on the Qualtrics Public API.

This CPS is the operational counterpart to the Certificate Policy (CP) — Public API Client Certificates v1.0. It implements every requirement stated in the CP and must not contradict it. Where the CP states policy requirements, this CPS describes the concrete procedures and technical controls Qualtrics uses to meet them.

This document is structured in accordance with RFC 3647. Each section mirrors the corresponding section of the CP. Where a section has no stipulation in either document, this is explicitly stated.

1.2 Document Name and Identification

Attribute	Value
Document name	Certification Practice Statement — Public API Client Certificates
Applicable CA	Public Api Client Certs Intermediate Authority '{dc}.qualtrics.com'
Corresponding CP	Certificate Policy — Public API Client Certificates, available at https://api.qualtrics.com/93f3527791b03-certificate-policy-cp-for-public-api-m-tls
This document published at	https://api.qualtrics.com/a0004e731f379-certification-practice-statement-cps-for-public-api-m-tls

1.3 PKI Participants

1.3.1 Certification Authorities

Root CA — Qualtrics Production Root CA 2019

• Subject CN: Qualtrics Production Root
• Hosted as a HashiCorp Vault PKI backend
• Signs only Intermediate CA certificates
• Root CA certificate is distributed in Qualtrics' internal trust bundles

Intermediate CA — Public Api Client Certs Intermediate Authority

• Vault backend name: client_certs_int
• Vault URL pattern: internal Vault instances, one per DC, accessible only within Qualtrics' internal network
• Subject CN: Public Api Client Certs Intermediate Authority '{dc}.qualtrics.com'
• Deployed in all DCs
• Vault role for issuance: qualtrics-dot-com

1.3.2 Registration Authorities

No separate RA is operated. The Qualtrics Public API platform (POST /API/v3/organizations/{organizationId}/clientcertificates) performs automated validation and forwards validated requests to the Vault PKI signing service. This function is part of Qualtrics' API Engineering platform and acts on behalf of the CA under the authority of the Internal Engineering team.

1.3.3 Subscribers

Subscribers are external Qualtrics customers who have:

1. Received approval from their Qualtrics Account Representative to enable mTLS.
2. Completed the mTLS enablement process in collaboration with the Qualtrics API Engineering team.
3. Had the mTLS feature provisioned for their Qualtrics organization.

Subscribers are identified by their Qualtrics brandID (organizationID). Each Subscriber organization may hold up to 10 simultaneously active certificates.

1.3.4 Relying Parties

The sole Relying Party is Qualtrics' Public API infrastructure. Specifically, the mutualtls.{dc}.qualtrics.com endpoints validate client certificates during TLS handshakes. These endpoints are operated by the Qualtrics Engineering team.

1.3.5 Other Participants

Qualtrics Account Representatives act as the initial approval gate before a Subscriber organization is granted access to the mTLS feature.

1.4 Certificate Usage

Certificates issued under this CPS are used exclusively for mTLS client authentication to https://mutualtls.{dc}.qualtrics.com endpoints. The id-kp-clientAuth EKU enforces this technically.

mTLS does not replace existing API authentication (API Token or OAuth). Both must still be presented on every request.

1.5 Policy Administration

Policy Management Authority: Qualtrics Internal Engineering
Contact: support@qualtrics.com Qualtrics, LLC, 333 W. River Park Drive, Provo, UT 84604, USA

This CPS is reviewed at least annually by the Internal Engineering team. Proposed changes are reviewed against the CP; the CPS may be more restrictive than the CP but must not contradict it.

1.6 Definitions and Acronyms

See Section 1.6 of the CP — Certificate Policy — Public API Client Certificates v1.0.

Additional terms specific to this CPS:

Term	Definition
Vault	HashiCorp Vault — the secrets management platform used as the CA backend
vault-pki-ca	The internal Qualtrics repository containing declarative PKI configuration and management tooling
brandID	Qualtrics organizational identifier used as the O field in Subscriber certificate Subjects

2. Publication and Repository Responsibilities

2.1 Repositories

This CPS is published at: https://api.qualtrics.com/a0004e731f379-certification-practice-statement-cps-for-public-api-m-tls

The corresponding CP is published at: https://api.qualtrics.com/93f3527791b03-certificate-policy-cp-for-public-api-m-tls

The Intermediate CA certificate for each DC instance is available to authorized Qualtrics infrastructure via the internal CA management platform.

The CRL for each DC instance is accessible to Qualtrics' API infrastructure directly at an internal Vault PKI endpoint; it is not embedded in issued certificates via a CDP extension (see Section 7.2).

2.2 Publication of Certification Information

Both the CP and this CPS are maintained in version-controlled form. The Internal Engineering team publishes updated versions to the repository URLs above. Previous versions are retained in version control history for audit purposes.

The CP and CPS are not embedded in issued certificates.

2.3 Time or Frequency of Publication

This CPS is reviewed and re-published at least annually.

2.4 Access Controls on Repositories

The published CP and CPS documents are publicly readable. The repository containing the configuration is access-controlled to authorized Qualtrics Internal Engineering team members. Vault backends themselves require Vault authentication to access.

3. Identification and Authentication

3.1 Naming

3.1.1 Subject DN Structure

End-entity certificates issued by this CA contain the following Subject Distinguished Name:

CN=mutualtls.{dc}.qualtrics.com
O={brandID}

Example:

CN=mutualtls.iad1.qualtrics.com
O=some_brand

The {dc} value is the Qualtrics datacenter identifier.

No other Subject fields (C, ST, L, OU) are required or added by the CA.

3.1.2 Name Validation

At signing time, the Vault PKI service validates:

• The CN matches the pattern mutualtls.{dc}.qualtrics.com where {dc} is a valid datacenter (enforced via allowed_domains in the role config: {dc}.qualtrics.com with allow_subdomains: true).
• The CSR is a valid PKCS#10 PEM-encoded request.

A request that fails these checks returns error MSS_1.0 (PKI service rejection) or VC_0.1 (CSR validation failure).

3.2 Initial Identity Validation

Qualtrics implements the following automated validation chain before signing a certificate:

Step 1 — API authentication: The request must include a valid X-API-TOKEN header associated with an active Qualtrics user account.

Step 2 — Role check: The Qualtrics API platform verifies the authenticated user holds the Brand Admin role within their organization. Requests from non-Brand Admin users are rejected with error MSS_0.4.

Step 3 — Organization ID match: The organizationId in the API request path is compared to the brand ID of the authenticated user's organization. A mismatch is rejected with MSS_0.1. This prevents cross-organization certificate requests.

Step 4 — Active certificate count: The platform verifies the organization does not already hold 10 active certificates. If the limit is reached, the request is rejected with MSS_0.3.

Step 5 — CSR validation: The CSR is forwarded to the Vault PKI service. Vault validates the PKCS#10 format, verifies the CN is within the allowed domains for the qualtrics-dot-com role, and validates the O field matches the Subscriber's organization.

All five steps must succeed before a certificate is signed.

3.3 Identification and Authentication for Re-Key

Certificate renewal and re-key follow the identical validation chain as initial issuance. The Subscriber generates a new key pair and submits a new CSR. The same API endpoint and all five validation steps apply. No special re-key procedure exists; re-key is operationally equivalent to new issuance.

3.4 Identification and Authentication for Revocation

Revocation is performed via DELETE /API/v3/organizations/{organizationId}/clientcertificates/{certificateId}. Qualtrics validates:

• The caller is authenticated with a valid API token.
• The caller holds the Brand Admin role.
• The organizationId matches the caller's organization.
• The certificateId (SHA-256 thumbprint) corresponds to a certificate registered to that organization.

Requests that fail any check return the appropriate MSS_4.x error code.

4. Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

A Subscriber applies for a certificate as follows:

1. Generate key pair and CSR:

   openssl req -new -keyout myPrivateKey.pem -out myCSR.csr

   • At the Organization Name prompt: enter the Qualtrics brandID.
   • At the Common Name prompt: enter mutualtls.{dc}.qualtrics.com (e.g. mutualtls.iad1.qualtrics.com).
   • A passphrase should be set to protect the private key.

2. Submit the CSR via the Qualtrics Public API:

   curl --request POST \
     --url 'https://{dc}.qualtrics.com/API/v3/organizations/{organizationId}/clientcertificates' \
     --header 'Content-Type: application/json; charset=utf-8' \
     --header 'X-API-TOKEN: {token}' \
     --data '{"certificateRequest": "-----BEGIN CERTIFICATE REQUEST-----\n...\n-----END CERTIFICATE REQUEST-----"}'

   All newlines in the PEM CSR must be replaced with \n escape sequences for the JSON body.

3. Save the returned certificate: The API response contains the signed PEM certificate in result.certificate and the SHA-256 thumbprint in result.id. Save both. The id is required for future GET and DELETE operations.

Prerequisites before applying:

• The Subscriber's Account Representative has approved mTLS access.
• The mTLS feature has been enabled for the Subscriber's organization by the Qualtrics API Engineering team.
• The Subscriber has confirmed readiness of all users who access the Public API.

4.2 Certificate Application Processing

The Qualtrics API platform processes certificate applications fully automatically with no manual intervention. The processing sequence is:

1. Authenticate the API token and check Brand Admin role.
2. Validate the organizationId matches the authenticated user's organization.
3. Count active certificates for the organization; reject if ≥ 10.
4. Forward the CSR to the Vault PKI backend (client_certs_int) via the qualtrics-dot-com role.
5. Vault validates the CSR and signs the certificate with the Intermediate CA key.
6. The signed certificate and SHA-256 thumbprint are returned to the Subscriber in the API response.

Processing is synchronous; the response contains either the signed certificate or an error code. Processing time is typically sub-second.

4.3 Certificate Issuance

The Vault PKI backend signs the certificate using the Intermediate CA private key stored in the Vault instance for the target datacenter. The certificate is issued with:

• Validity period: 1 year (365 days) from the time of signing
• Signature algorithm: SHA-256 with RSA
• Serial number: Generated by Vault (unique per CA instance)
• Certificate identifier: SHA-256 thumbprint (returned as result.id in the API response)

The Vault role qualtrics-dot-com enforces an allowed domain of {dc}.qualtrics.com with allow_subdomains: true, which permits mutualtls.{dc}.qualtrics.com as the CN. The role TTL is 8,760h (1 year), matching the certificate validity period.

4.4 Certificate Acceptance

There is no explicit acceptance workflow. The Subscriber is deemed to have accepted the certificate upon retrieving it. Qualtrics recommends that upon receipt, the Subscriber:

1. Verifies the certificate contents:

   openssl x509 -noout -text -in myCert.cert

2. Verifies the expiry date:

   openssl x509 -noout -dates -in myCert.cert

3. Validates certificate presentation using the pre-enablement test (see Section 4.5).

4.5 Key Pair and Certificate Usage

The certificate is used by configuring the Subscriber's HTTP client to present it during TLS handshakes to https://mutualtls.{dc}.qualtrics.com. The Subscriber must also include API Token or OAuth credentials in the request; mTLS alone is not sufficient for authentication.

Pre-enablement validation: Before enabling mTLS for the organization, the Subscriber should verify the certificate is being correctly presented:

curl --request GET \
  --url 'https://mutualtls.{dc}.qualtrics.com/API/v3/whoami' \
  --header 'X-API-TOKEN: {token}' \
  --cert myCert.cert \
  --key myPrivateKey.pem \
  --pass '{passphrase}'

An AUA_1.1 response at this stage confirms the certificate is being received and evaluated by Qualtrics infrastructure. This is the expected result before mTLS is enabled for the organization.

After mTLS enablement: All calls must use the mutualtls.{dc}.qualtrics.com subdomain. Calls to {dc}.qualtrics.com will fail with AUA_1.1. Propagation of the mTLS enablement setting may take up to 60 minutes.

Per-system issuance: For organizations with multiple systems or integrations, the recommended practice is to issue one certificate per system or integration rather than sharing a single certificate across multiple consumers.

4.6 Certificate Renewal

Renewal is subscriber-initiated. Qualtrics provides a 60-day advance notice mechanism: when an API call is made using a certificate that expires within 60 days, the API response meta object includes:

{
  "meta": {
    "notice": "The client certificate presented with this call expires within 60 days. Please generate a new client certificate to use with this call."
  }
}

Additionally, the Subscriber may check expiry proactively using GET /API/v3/organizations/{organizationId}/clientcertificates/{certificateId} to retrieve the PEM, then inspect with openssl x509 -noout -dates.

Recommended renewal procedure:

1. Generate a new key pair and CSR.
2. Submit the new CSR via POST /API/v3/organizations/{organizationId}/clientcertificates.
3. Validate the new certificate using the pre-enablement test (see Section 4.5) — expect AUA_1.1.
4. Update all systems to present the new certificate.
5. Confirm the new certificate works end-to-end.
6. Delete the old certificate via DELETE /API/v3/organizations/{organizationId}/clientcertificates/{certificateId}.

This sequence ensures the old certificate remains active until the new one is confirmed working.

4.7 Certificate Re-Key

Re-key is equivalent to renewal. The Subscriber must always generate a new key pair when obtaining a new certificate. There is no mechanism to issue a new certificate bound to an existing key pair.

4.8 Certificate Modification

Not supported. Certificate modification is not available. Any change to Subject fields requires issuing a new certificate and deleting the old one.

4.9 Certificate Revocation and Suspension

4.9.1 Revocation by Subscriber

The Subscriber revokes a certificate by calling:

curl --request DELETE \
  --url 'https://{dc}.qualtrics.com/API/v3/organizations/{organizationId}/clientcertificates/{certificateId}' \
  --header 'X-API-TOKEN: {token}'

Where {certificateId} is the SHA-256 thumbprint returned at issuance. To list active certificates and their IDs:

curl --request GET \
  --url 'https://{dc}.qualtrics.com/API/v3/organizations/{organizationId}/clientcertificates' \
  --header 'X-API-TOKEN: {token}'

Deletion is permanent and cannot be undone. The certificate is removed from the organization's active certificate store and added to the Vault-maintained CRL for that DC.

4.9.2 Revocation by Qualtrics Internal Engineering

Qualtrics Internal Engineering may revoke certificates directly through the Vault CLI or API without going through the customer-facing API. This will be used in the event of:

• Confirmed or suspected CA private key compromise
• Confirmed or suspected Subscriber private key compromise, where the Subscriber cannot be reached
• Discovery of certificate misuse
• Account closure or withdrawal of mTLS access

4.9.3 Suspension

Certificate suspension is not supported. Certificates may only be permanently revoked.

4.9.4 Certificate Status — CRL

Upon deletion, the Vault PKI backend immediately updates the CRL for the CA mount in the affected DC. The CRL is accessible to Qualtrics' API infrastructure directly at the internal CA management platform endpoint for the relevant DC; certificates do not carry a CDP extension pointing to this endpoint (see Section 7.2).

Infrastructure propagation of revocation may take up to 60 minutes (consistent with mTLS configuration propagation windows).

4.9.5 OCSP

Not provided. OCSP is not operated for this CA.

4.10 Certificate Status Services

No CRL Distribution Point (CDP) extension is embedded in issued end-entity certificates (see Section 2.2 and Section 7.1). The CRL is available directly at a Vault PKI endpoint for the issuing Intermediate CA instance, accessible within Qualtrics' internal network. OCSP is not offered.

4.11 End of Subscription

When a Subscriber's mTLS access is terminated:

• The Subscriber must delete all active certificates using the DELETE endpoint.
• Qualtrics will administratively disable mTLS for the organization.
• Any remaining certificates not deleted by the Subscriber will be revoked by Qualtrics Internal Engineering.

Expired certificates that have not been deleted continue to count against the 10-certificate organization limit until explicitly deleted, but they are not accepted for mTLS after their expiry date.

4.12 Key Escrow and Recovery

Not applicable. Subscriber private keys are generated by the Subscriber on their own infrastructure. Qualtrics never receives, stores, or escrows Subscriber private keys. No key recovery service is provided.

5. Facility, Management, and Operational Controls

5.1 Physical Controls

The HashiCorp Vault instances hosting the Intermediate CA are deployed in Qualtrics-operated datacenters. These facilities implement industry-standard physical security controls.

The Vault hosts for customer PKI and secrets are separate from the internal engineering Vault instances and are physically co-located within the same DC facilities.

5.2 Procedural Controls

5.2.1 Trusted Roles

The following roles are defined for CA operations:

Role	Responsibilities
CA Administrator (Internal Engineering)	Manages the configuration repository; executes CA backend creation and configuration; reviews and updates CP/CPS
Vault Operator	Manages the Vault infrastructure; responsible for unseal operations, backup, patching, and access management
API Engineering	Operates the Qualtrics Public API platform that mediates certificate requests; responsible for mTLS enablement workflow
Account Representative	First-line approval for Subscriber mTLS access requests

5.2.2 Number of Persons Required per Task

Task	Minimum persons
Creating a new CA backend	1 authorized CA Administrator
Emergency CA revocation	1 authorized CA Administrator
CP/CPS changes	1 Internal Engineering author + 1 Internal Engineering reviewer + 1 Security Assurance reviewer

5.2.3 Identification and Authentication for Each Role

CA Administrators authenticate to the vault-pki-ca tooling. Token retrieval requires the operator to be authenticated to Vault. Access to Vault is controlled through Qualtrics' identity and access management (IAM) systems.

5.3 Personnel Controls

Qualtrics Internal Engineering personnel with CA Administrator access are:

• Full-time Qualtrics employees subject to pre-employment background screening
• Subject to annual security training
• Bound by Qualtrics' Acceptable Use and Information Security policies
• Subject to access reviews at least annually

Access to CA systems is granted on a least-privilege basis and is revoked immediately upon role change or departure.

5.4 Audit Logging Procedures

HashiCorp Vault audit logging is configured on the Vault instances to log all CA operations including:

• Certificate signing requests (issuance)
• Certificate revocation events (deletion)
• Role creation and modification
• Backend configuration changes
• Authentication events (login/logout)

Vault audit logs are forwarded to Splunk via the Vault audit device. Logs are protected from unauthorized modification by Splunk access controls, with write access restricted to the Vault audit pipeline service account.

Audit log records are retained for a minimum of 18 months.

Application-layer audit trails are also maintained in the Qualtrics API platform, recording each certificate issuance and deletion event with the requesting user's identity, timestamp, and result.

5.5 Records Archival

Certificate issuance and revocation records are retained in:

• HashiCorp Vault audit logs (see Section 5.4)
• Qualtrics API platform audit trail
• The vault-pki-ca repository (configuration history via git)

Retention period: 18 months minimum.

5.6 Key Changeover

When an Intermediate CA instance approaches its 3-year validity period:

1. A new Intermediate CA backend (client_certs_int) is created in the affected DC using the vault-pki-ca tooling.
2. The new CA generates a fresh CSR via Vault's endpoint.
3. The CSR is signed by the Qualtrics Production Root CA 2019.
4. The signed certificate is uploaded to the new backend.
5. The qualtrics-dot-com role is configured on the new backend.
6. New certificate issuance is routed to the new backend.
7. Certificates issued under the old backend remain valid until their own expiry. Subscribers are advised to rotate to new certificates issued under the new CA before the old CA expires.

The Root CA certificate was created in 2019 and will require renewal in 2029. Root CA renewal requires Internal Engineering to conduct a new Root CA key ceremony and to re-issue all Intermediate CA certificates under the new Root.

5.7 Compromise and Disaster Recovery

5.7.1 Incident and Compromise Handling Procedures

In the event of confirmed or suspected compromise of the Intermediate CA private key:

1. Internal Engineering immediately seals the affected Vault instance to prevent further signing.
2. Internal Engineering revokes all certificates issued by the compromised CA via the Vault CLI.
3. All active Subscribers are notified via Qualtrics' customer communication channels and their Account Representatives.
4. A new Intermediate CA instance is created following the key changeover procedure (Section 5.6).
5. Subscribers are directed to re-issue certificates under the new CA.
6. A post-incident review is conducted and documented.

5.7.2 Computing Resources, Software, and/or Data are Corrupted

If the Vault instance in a DC is unavailable or corrupted:

• Certificate issuance is unavailable for that DC until the Vault instance is restored.
• The Vault instance is restored from backup per Qualtrics' Vault disaster recovery procedures.
• If recovery from backup is not possible, a new CA backend must be created following the key changeover procedure.

5.7.3 CA Private Key Compromise Procedures

See Section 5.7.1.

5.7.4 Business Continuity After a Disaster

Qualtrics' Vault infrastructure benefits from DC-level redundancy across the production fleet. Each DC maintains its own independent client_certs_int backend. A failure in one DC does not affect certificate issuance in other DCs.

5.8 CA Termination

If the public_api_client_certs_intermediate CA is to be permanently decommissioned:

1. Internal Engineering provides at least 90 days advance notice to all active Subscribers via Account Representatives and customer communication channels.
2. No new certificates are issued after the termination date is announced.
3. All outstanding certificates are revoked on or before the termination date.
4. The Vault PKI backend is disabled.
5. All CA keying material is securely destroyed within Vault.
6. CA certificate records are archived per Section 5.5 retention requirements.

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 CA Key Pair Generation

The Intermediate CA key pair is generated within HashiCorp Vault using the PKI secrets engine. This generates the private key inside Vault's encrypted storage and creates a CSR for signing by the Root CA. The private key is generated as internal type, meaning it is never exported and cannot be retrieved outside of Vault.

The key generation is performed by an Internal Engineering CA Administrator executing the management tooling from the Vault hosts. The tooling:

1. Creates the PKI backend mount at client_certs_int.
2. Calls /intermediate/generate/internal with common_name and ttl options.
3. Signs the resulting CSR with the Qualtrics Production Root CA 2019 via /root/sign-intermediate.
4. Uploads the signed certificate via /intermediate/set-signed.
5. Creates the qualtrics-dot-com role.

There is no formal key ceremony ceremony with witnesses for Intermediate CA creation, since the key is generated and stored inside Vault without ever being exposed. Vault audit logging captures the creation event.

6.1.2 Subscriber Key Pair Generation

Subscribers generate their own key pairs using openssl req or equivalent tooling on their own infrastructure. Qualtrics does not specify a required key generation tool but recommends:

• RSA 2048-bit minimum; RSA 4096-bit recommended.
• Private key protected with a passphrase.
• Key generated on systems with sufficient entropy.

The private key must be retained securely by the Subscriber and must never be transmitted to Qualtrics or included in the CSR or API request.

6.1.3 CA Key Installation

The signed Intermediate CA certificate is installed into the Vault backend. After installation, the CA is active and can sign end-entity certificates.

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 CA Private Key Storage

The Intermediate CA private key is stored in HashiCorp Vault's encrypted storage backend. Vault encrypts all stored secrets using AES-256-GCM. The encryption key is protected by Vault's seal mechanism (Shamir secret sharing or cloud auto-unseal, per DC configuration — details maintained in internal Vault operations documentation).

No Hardware Security Module (HSM) is used. The CA private key is stored in Vault's software encryption layer.

6.2.2 Vault Access Controls

Access to the Vault instances is controlled via:

• Network-level controls (hosts are not reachable from outside Qualtrics' internal network)
• Vault authentication with policy-enforced least privilege
• Vault tokens used for signing operations have only the minimum required policies

6.2.3 CA Private Key Backup

The CA private key is protected by Vault's storage backend encryption and is included in Vault's snapshot/backup mechanism. Backups are stored in an S3 bucket with server-side KMS encryption.

The CA private key itself is not separately backed up outside of Vault's internal storage.

6.2.4 CA Private Key Destruction

When the CA is decommissioned, the Vault PKI backend is disabled, which destroys all associated keying material. Any Vault backups containing the old CA data are subject to Qualtrics' backup retention and destruction policies.

6.3 Other Aspects of Key Pair Management

6.3.1 Certificate Validity Periods

Certificate type	Validity period	Vault TTL config
Qualtrics Production Root CA 2019	10 years (87,600h)	Configured at root creation
Intermediate CA (client_certs_int)	3 years (26,280h)	options.ttl: 26280h in configs/public-api.yaml
End-entity (Subscriber)	1 year (8,760h)	ttl: 8760h on the qualtrics-dot-com role

6.4 Activation Data

CA signing operations are performed automatically by Vault once unsealed. Vault is unsealed using the configured unseal mechanism for each DC (Shamir shares held by Vault Operators, or cloud-provider auto-unseal). No additional activation data is required for individual signing operations once Vault is unsealed.

6.5 Computer Security Controls

The Vault hosts are hardened in accordance with Qualtrics' server hardening standards, including:

• Operating system hardening (minimal package set, unused services disabled)
• Firewall rules restricting inbound connections to required ports only (Vault API: 8200/tcp; cluster port: 8201/tcp)
• Vault configured with TLS on all listener interfaces (HTTPS)
• Automatic security patching for OS packages; Vault binary patching governed by change management process
• Host-level intrusion detection

6.6 Life Cycle Technical Controls

Vault binary and OS packages on Vault hosts are maintained under Qualtrics' patch management process. Security patches are applied on at least a quarterly cadence; critical security patches are evaluated for expedited application outside the regular cycle.

The vault-pki-ca configuration repository is managed via git with merge request review processes enforced for changes to CA configurations.

6.7 Network Security Controls

The Vault instances are accessible exclusively within Qualtrics' internal network via private network segments. No public internet access is permitted to or from these hosts. Network access is controlled by:

• VPC/network security group rules permitting only required internal traffic
• No public IP addresses assigned to hosts

6.8 Time-Stamping

Certificate notBefore and notAfter fields are set using the system clock of the Vault host at signing time. The notBefore value is the time of certificate generation; notAfter is notBefore + 1 year (8,760h).

7. Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

All end-entity certificates issued under this CPS conform to the following profile:

Basic Certificate Fields:

Field	Value
Version	3 (X.509 v3)
Serial number	Unique integer generated by HashiCorp Vault
Signature algorithm	sha256WithRSAEncryption (OID 1.2.840.113549.1.1.11)
Issuer DN	CN=Public Api Client Certs Intermediate Authority '{dc}.qualtrics.com'
Validity — notBefore	Time of signing
Validity — notAfter	Time of signing + 365 days
Subject DN	CN=mutualtls.{dc}.qualtrics.com, O={brandID}
Subject public key	RSA public key (minimum 2048-bit, as provided in the Subscriber's CSR)

X.509 v3 Extensions:

Extension	OID	Critical	Value
Basic Constraints	2.5.29.19	Yes	CA: FALSE
Key Usage	2.5.29.15	Yes	digitalSignature (1), keyAgreement (4), keyEncipherment (2)
Extended Key Usage	2.5.29.37	No	id-kp-clientAuth (1.3.6.1.5.5.7.3.2)
Subject Key Identifier	2.5.29.14	No	Hash of the Subject public key
Authority Key Identifier	2.5.29.35	No	Key identifier of the signing Intermediate CA

Extensions not included:

• Certificate Policies (no OID asserted — CP referenced by URL only)
• Subject Alternative Name (not required for client certificates used in this context)
• OCSP / Authority Information Access
• CRL Distribution Point (see Section 7.2)

7.2 CRL Profile

A Certificate Revocation List (CRL) is maintained by the HashiCorp Vault PKI engine for each DC's CA mount. The CRL is updated in real time upon each certificate deletion event.

CRL fields:

Field	Value
Version	X.509 v2 CRL
Signature algorithm	sha256WithRSAEncryption
Issuer	Same DN as the signing Intermediate CA
This Update	Time of CRL generation
Revoked certificates	List of revoked certificate serial numbers with revocation timestamps

7.3 OCSP Profile

No Stipulation. An OCSP responder is not operated for this CA. The CRL is the sole revocation status mechanism.

8. Compliance Audit and Other Assessments

8.1 Frequency and Scope of Assessments

The Internal Engineering team conducts an internal compliance review of this CA at least annually. The review covers:

• Comparison of actual CA operations against this CPS
• Review of certificate issuance and revocation audit logs for anomalies
• Review of personnel access to CA systems
• Vault configuration review (role configurations, access policies, TLS configuration)
• Vault and OS patch level review
• CP/CPS currency review — whether the documents reflect current operations
• Review of any security incidents involving the CA

This CA is not subject to external WebTrust or CA/Browser Forum audit requirements as it is a private, non-publicly-trusted CA.

8.2 Assessor Identity and Qualifications

Internal assessments are performed by Internal Engineering team members with sufficient knowledge of PKI operations and the Vault infrastructure.

8.3 Actions Taken as a Result of Deficiency

Severity	Response timeline
Critical (e.g. key compromise, unauthorized issuance)	Immediate escalation; remediation within 24 hours
High (e.g. access control gap, policy non-compliance)	Remediation within 30 days
Medium / Low	Remediation within 90 days

Deficiency findings and remediation status are documented and tracked by the Internal Engineering team.

8.4 Communication of Results

Annual assessment results are reported to the Internal Engineering team lead. Critical findings are escalated to Qualtrics' Information Security leadership and relevant engineering stakeholders immediately.

9. Other Business and Legal Matters

9.1 Fees

See existing agreement between Qualtrics and Subscriber.

9.2 Financial Responsibility

See existing agreement between Qualtrics and Subscriber.

9.3 Confidentiality of Business Information

Certificate content (including Subscriber brandID in the O field) is treated as Subscriber data. Vault audit logs and internal CA operational records are classified as Qualtrics confidential information and are not disclosed externally.

9.4 Privacy of Personal Information

Certificate Subject fields contain organizational identifiers (brandID), not personal data.

9.5 Intellectual Property Rights

No Stipulation.

9.6 CA and Subscriber Obligations

Qualtrics obligations:

• The CA is operated in accordance with this CPS.
• Certificates issued conform to the profile in Section 7.1.
• Revocation processing occurs in real time upon receipt of a valid DELETE request.
• The CRL is maintained and accessible to Qualtrics' API infrastructure.
• This CPS is reviewed and updated at least annually.

Subscribers obligations:

• All information provided in CSRs is accurate and pertains to their own organization.
• The requesting user is a legitimate Brand Admin of the named organization.
• The Subscriber's private key is generated on secure systems, protected by a passphrase, and is not shared with or accessible to unauthorized parties.
• The certificate is used exclusively for mTLS authentication to Qualtrics Public API endpoints.
• Any certificate whose corresponding private key is compromised must be promptly revoked.
• The Subscriber will comply with the certificate validity and rotation requirements in this CPS.

9.7 Disclaimers of Warranties

See existing agreement between Qualtrics and Subscriber.

9.8 Limitations of Liability

See existing agreement between Qualtrics and Subscriber.

9.9 Indemnities

See existing agreement between Qualtrics and Subscriber.

9.10 Term and Termination

This CPS takes effect upon publication and remains in effect until formally superseded or withdrawn. Withdrawal of this CPS will be accompanied by decommissioning of the CA per Section 5.8.

9.11 Individual Notices and Communications

Notices of material changes to this CPS, or of CA events affecting Subscribers (such as CA compromise or planned termination), are delivered through Qualtrics' customer communication channels and via Subscriber Account Representatives.

9.12 Amendments

Qualtrics may amend this CPS at any time. Amendments are effective upon publication of the updated document. The version number and date in the document header are updated on each revision.

9.13 Dispute Resolution Provisions

See existing agreement between Qualtrics and Subscriber.

9.14 Governing Law

See existing agreement between Qualtrics and Subscriber.

9.15 Compliance with Applicable Law

See existing agreement between Qualtrics and Subscriber.

9.16 Miscellaneous Provisions

No Stipulation.

9.17 Other Provisions

No Stipulation.

Appendix A: References

Document	Description
RFC 3647	Internet X.509 PKI Certificate Policy and Certification Practices Framework
RFC 5280	Internet X.509 PKI Certificate and CRL Profile