Frequently Asked Questions

Data protection and data separation

Q: How do you separate “my data” from other customers' data?

A: Tenant Administrators have access only to the data that belongs to their account. Tenant specific details and/or metadata are protected at rest using volume encryption.

Q: Does Thales, my Service Provider, or anyone else have access to my encryption keys stored in a Luna Cloud HSM Service?

A: When the Luna Cloud HSM Service instance is initialized, the service owner creates passwords or phrases for both the Security Officer and Crypto Officer roles. Those secrets are used in a derivation scheme and are required to allow the HSM to unseal the cryptographic material. Only the Security Officer/Crypto Officer are in possession of those secrets. It is left to the discretion of those officers to share the credentials as needed.

Q: How strong is your encryption and data integrity?

A: Data encryption and integrity mechanisms used within the platform meet or exceed industry best practices using FIPS approved mechanisms. Additionally, our general policy is that any keys used to protect other keys must be at the same security strength or higher. Cryptographic controls are applied to data at rest, in transit and in use where possible, but they are only one facet of our defense in depth strategy. Networking level controls such as intelligent routing, traffic segregation, port and application level firewalls, as well as VPN tunnels, are also employed to ensure that confidentiality, integrity, and availability concerns are all met.

Vulnerability management

Q: Can you show evidence of your vulnerability management program?

A: Thales services undergo regular application and network penetration testing by third parties. The assessment methodology includes review processes based on recognized “best-in-class” practices as defined by such methodologies as the ISECOM's Open Source Security Testing Methodology Manual (OSSTMM), the Open Web Application Security Project (OWASP), Web Application Security Consortium (WASC), and ISO 27001:2022 Information Security Standard

Q: What is your vulnerability remediation process?

A: When a potential security incident is detected, a defined incident management process is initiated by authorized personnel. Corrective actions are implemented in accordance with defined policies and procedures. Prior to the actual service update the following tasks are performed:

• Provisioning Testing: This is done on the updated service in a controlled environment and done by the Thales Service Operations team. With the conclusion of these tests the code has passed 3 rounds of testing successfully, each done by a different group: Unit testing done by the developer, Sprint Code Testing done by the QA group, and Service Update Provisioning Testing done by Service operations.
• A Planned Release Notification (PRN) is sent to all existing customers notifying them on the scope of the update and planned date of actual service update.
• Penetration testing: Penetration testing is done on a dedicated non-production system, but runs in the same environment as the operational service.
• At the last stage, all data is backed up from the operational service, which allows Thales to rollback immediately in case of any unexpected challenges.

Q: How often do you scan for vulnerabilities on your network and applications?

A: We conduct monthly reviews of all patches for servers and network equipment.

Data center failover

Q: How does high-availability between the HSMs in the data center work? Do all requests go to a single HSM, or are requests sent to multiple cards?

A: Requests are sent to a single HSM. In the event the HSM fails, requests are routed to a different HSM.

Q: How are keys replicated between data centers?

A: HSM services are protected by multiple layers of encryption. Data centers are kept consistent through a consensus protocol. When key material is changed in the local data store it is also replicated externally. The HSM service can only be instantiated in a specified disaster recovery pool.

Q: When does key replication between data centers occur?

A: Key replication occurs when key material is created or modified. Key material is not returned to the client until local quorum is established.

Q: When a HSM service is created are the primary and backup HSM provisioned at the same time, or is the second HSM provisioned after the service is initialized?

A: When the HSM service is created an empty logical HSM is created and stored in the database. The service contains no secrets at this time and it is not loaded into a physical HSM. When the customer connects the service the empty HSM service is loaded on a physical device. When the service is initialized the HSM service creates any required key material and encrypts it with a key which is partially derived from the customer supplied password. The HSM service can be loaded on any number of physical HSMs to satisfy service requirements.

Physical and personnel security

Q: Is there restricted and monitored access to critical assets 24x7?

A: Yes. Only Thales employees and contractors whose job responsibilities require logical access to the environment are provided access. For the production environment, this is limited to the following personnel:

• Personnel with administrative responsibilities for the Thales DPoD service.
• Personnel with responsibilities to maintain the network and systems.
• Personnel with responsibilities to deploy code.

Requests for access are submitted as a ticket in the Thales ticketing system. Requests are reviewed by the Thales DPoD Infrastructure Manager and approved by the Sr. Director of Infrastructure and Operations before access is granted. Once a request is approved, access is provisioned by one of the Technical Support team. Note that this process is strictly governing internal access to the system for administrative or operational reasons. This process is not intended to cover external users.

Logical access to the Thales DPoD Infrastructure is monitored as follows:

• LogRhythm is used to monitor use of Local Admin accounts, privileged accounts, as well as access to the Thales DPoD Databases. These logs are reviewed on a weekly basis by the Sr. Director of Infrastructure, who does not maintain the prior mentioned levels of access being reviewed.
• Access to and actions taken through the operator console are monitored via the monthly operator console report.

Application security

Q: Do you follow OWASP guidelines for application development?

A: Yes, we follow OWASP guidelines.

Q: Do you have a rigorous testing and acceptance procedure for outsourced and packaged application code?

A: Thales maintains a formally documented development life-cycle policy and process. Thales DPoD is developed using the agile development methodology that ensures quick, yet reliable turnaround between requirements gathered until service delivery. All changes are developed and tested by the appropriate engineering teams in development sprints. All changes are tested and signed-off by the QA team leader and Thales DPoD product manager. Evidence of testing and the requisite approvals are documented in the engineering project tracking system.

Q: What application security measures do you use in your production environment (Example: application-level firewall, database auditing)?

A: Thales utilizes Antivirus software within the Thales DPoD cloud environment and Antivirus software is utilized on workstations. Virus definitions are updated in real-time as they are released and monitoring is performed in real-time. A third-party Service Provider scans the network externally and alerts the Thales Security Team regarding changes in the baseline configuration to increase audit levels.

Incident response

Q: What is your procedure for handling a data breach?

A: When a potential security incident is detected, a defined incident management process is initiated by authorized personnel. Corrective actions are implemented in accordance with defined policies and procedures.

Compliance requirements

Q: Are your data centers under local compliance requirements?

A: Thales DPoD is based on a number of strategically located global Points-of-Presence (PoPs). One PoP is in Europe and the other in North America, and conform to local compliance requirements. For many years, the EU has had a formalized system of privacy legislation, which is regarded as more rigorous than that found in other areas of the world. Companies operating in the European Union are not allowed to send personal data to countries outside the EU unless there is a guarantee that it will receive adequate levels of protection. Thales hosts the DPoD environment within data centers located in Europe and North America. Data privacy protection can also be afforded by limiting the amount of personal information needed to utilize the service. The minimum Thales DPoD personal data requirement is, email address, first and last name.

Q: Are you ISO-270XX compliant?

A: Thales DPoD operations, and operations-related IT is fully compliant with the ISO 27001:2022 standard, having achieved independent ISO 27001:2022 Certification for its Information Security Management System and processes. Thales DPoD operations, and operations-related IT passed the ISO 27001:2022, 27018:2019, and 27017:2015 recertification audit and successfully transitioned to the to the 2022 version of the 27001 standard while extending our scope to include IdCloud and CDSPaaS.

Thales DPoD has also received SOC 2 Certification, proving compliance with the defined five trust service principles, security, availability, processing integrity, confidentiality, and privacy.

In addition DPoD achieved CSA Star Level 2 Third-Party Audit Certification further solidifying our commitment to transparency and trustworthiness in cloud services.

Support levels and response times

Q: What technical support options are provided?

A: Support for customers is normally provided via our network of highly trained and knowledgeable partners around the globe. The services they provide are backed by Thales' comprehensive support capabilities, details of which can be found here: https://cpl.thalesgroup.com/customer-support.

Reporting options

Q: Is it possible to monitor for service availability?

A: There is a Thales DPoD service status dashboard available for all customers.

Q: Is it possible to get activity logs for operations performed on DPoD services? 

A: Each operation that occurs on a Luna Cloud HSM Service is recorded in the Data Protection on Demand (DPoD) log system. These logs are available for querying in the DPoD platform for a period of 12 months.  

Q: What are the locations and the supplier names for your Data Centers?

A: All Data Centers and outsourcing partners are listed below:

Thales DPoD Data Centers

Cloud HSM Locations

North America Region
Cyxtera Technologies, Inc.
1400 Kifer RD
Sunnyvale, CA, 94086, USA
Entered service March 2023

Equinix Data Center
21830 Uunet Dr
20147, Ashburn VA, USA
Entered service November 2024

Europe Region
Equinix Data Center
Luttenbergweg 4
1101 EC Amsterdam, NL
Entered service June 2024

Equinix FR4
Larchenstrasse 110
Frankfurt, Germany, 65933
Entered Service: July 2025

Management Node
Rogers Communications
436 Hazeldean Rd
Kanata, ON, K2L1T9, CAN
Entered service May 2018

CDSPaaS Locations

North America Region
Primary: US-East1 (South Carolina)
DR: US-East4 (Ashburn, VA)

Europe Region
Primary: Europe-West3 (Frankfurt)
DR: Europe-West1 (Belgium)

CipherTrust Data Security Platform as a Service

1. Services Overview and Relationship to CipherTrust Product

Q: Does CDSPaaS compare in functionality to CipherTrust products?

A: CDSPaaS is built on the CipherTrust Data Security Platform and is designed to closely match the capabilities of the CipherTrust Manager and associated connectors that are delivered as a fully managed, multi-tenant cloud service. Some operational aspects differ because Thales manages infrastructure, backups, and updates on behalf of customers.

Q: What capabilities does CDSPaaS currently provide?

A: CDSPaaS currently supports enterprise key management, data-at-rest encryption and access control (CTE, CTE-LDT, CTE-RWP, CTE-K8s), cloud key management/BYOK (CCKM), KMIP and Oracle TDE integrations according to the roadmap and documentation. Future releases plan to add tokenization, data masking, secrets management, additional database integrations, and data security posture capabilities.

Q: Do CipherTrust products and services release simultaneously?

A: New capabilities are generally released first in product form and then promoted into the service after evaluation and validation. Timing of implementation is driven by needs of the service and customer.

Q: Can I migrate from a CipherTrust product to CDSPaaS?

A: Keys used with supported connectors and CTE policies can be backed up from CipherTrust Manager and restored into the CDSPaaS Key Management Service, with connector reconfiguration required to point to the service.

Q: Can I create subdomains in CDSPaaS Key Management Service?

A: No. It is possible to set up a primary tenant in CDSPaaS and associate sub tenants related to the primary tenant to provide operational independence. Each sub tenant would create a key management service with a unique Cloud HSM partition but would report through the Primary tenant for billing purposes.

Q: Does CDSPaaS enforce licensing on CCKM, CTE or other CDSP connectors?

A: CDSPaaS does not enforce licensing to be applied to any CDSPaaS connector configurations. However, Thales teams will monitor CDSP connector usage to determine if the customer remains in compliance with the quantity ordered. Upon purchase of the service, monitoring of usage is performed on all tenants. Tenants can scale usage as needed at any time. If overage occurs, Thales will invoice for overage or amend the subscription to the new quantity desired by the customer. With CDSPaaS, Thales imposes no impediment to access, so customers may expand usage as needed regardless of quantity purchased.

Q: What CTE agent versions are supported in CDSPaaS?

A: Per documentation, CDSPaaS supports CTE Agent for Windows 7.6.0-132 and above, CTE Agent for Linux 7.6.0-134 and above, and CTE Agent for AIX 7.7.0-36 and above.

2. Architecture, HSM, and key hierarchy

Q: Who has access to my encryption keys stored in CDSPaaS?

A: When a CDSPaaS tenant is provisioned, a tenant admin account and a dedicated Luna Cloud HSM partition are created; keys generated by the tenant are protected under a tenant-specific Master Encryption Key (MEK) in that partition. Access to tenant content is governed by roles and policies defined by the tenant administrator.

Q: Can an external HSM be used as the Root of Trust?

A: At this time, CDSPaaS uses a dedicated Luna Cloud HSM partition per tenant and does not support external physical or cloud HSMs as the root of trust.

Q: Can I rotate the Master Encryption Key in the Cloud HSM partition?

A: CDSPaaS does not expose direct management or rotation of the tenant MEK to avoid breaking the key hierarchy or causing data inaccessibility.

Q: What redundancy mechanisms are in place for the HSM?

A: The Luna Cloud HSM environment supporting CDSPaaS uses primary and DR locations, mirroring the high availability and DR design of the service itself.

Q: How is the CDSPaaS key hierarchy structured and how is recovery handled?

A: Tenant keys stored in CDSPaaS are encrypted under the tenant MEK in the dedicated HSM partition; key material is persisted as encrypted blobs associated with the tenant and can be exported by the customer when allowed by policy. Recovery of accidentally deleted keys is handled by DevOps using transaction metadata within a 7 day window.

3. High availability, backup, and disaster recovery

Q: Can CipherTrust Manager be clustered with CDSPaaS for high availability?

A: No, on premises CipherTrust Managers and CDSPaaS use different architectures and data stores and cannot be clustered together for a single HA domain. Customers can use both as complementary technologies and cluster virtual/physical CipherTrust Managers separately.

Q: How are backups handled in CDSPaaS?

A: Tenant data and configuration changes are continuously replicated to a DR site, and recovery from accidental deletion is possible for a limited period (7 days) through Support and DevOps. Customer initiated local backups are not currently supported though export of certain objects and future tenant backup features are planned.

Q: How does CDSPaaS ensure that data cannot be affected or compromised?

A: A SaaS compromise refers to a security breach or unauthorized access to a Software as a Service (SaaS) application. This can involve a variety of attacks, including account takeover and data breaches potentially leading to significant data loss and operational disruptions.

The following table outlines common attack vectors, the risks presented and what Thales does to mitigate these risks:

Attack Vector	Description	Thales Response
Account Takeover (ATO)	Attackers gain access to user accounts through stolen credentials (phishing, brute-force, etc.) to exfiltrate data, send malicious emails, or escalate privileges.	As the CDSPaaS Service Owner ultimately controls all access to CDSPaaS, they are able to apply account management practices to ensure only those requiring legitimate access can do so. CDSPaaS undergoes regular 3rd party assessment to ensure we are following best practices regarding the operation of our SaaS offering and the attack vectors mentioned in the previous column. DPoD and CDSPaaS are working to included IDP support to allow customers to utilize their established IDP or 2FA processes to CDSPaaS (see roadmap).
Data Breaches	Unauthorized access to sensitive information stored in SaaS applications due to weak encryption, poor access controls, or system vulnerabilities.	To date, we have not experienced such access issues with CDSPaaS based on the controls currently available and planned for implementation. The CDSPaaS service registration process automatically generates a unique Luna Cloud HSM partition for the tenant to act as a transparent Root of Trust for their CDSPaaS Service. Separation of tenants and their respective key hierarchy ensure: - Sovereignty maintained in region with control of the key hierarchy based on the HSM partition (hosted in a private data center separately from CDSPaaS’ deployment). - Control of information (allowing customers greater independence of key ownership and the data protected by these keys). Thales DevOps personnel employ vulnerability scanning, service monitoring and threat detection protocols to ensure we meet our expected SLA.
SaaS-to-SaaS Connections	Vulnerabilities in SaaS-to-SaaS connections, like those used for authentication, can be exploited to compromise multiple applications.	CDSPaaS tenants can use VPN with Google Cloud Interconnect to support secure “cloud to cloud” or “cloud to private network” connections. Implementation has already been completed for our various CCKM integrations. For some use cases, Thales will utilize Google Private Service Connect to allows consumers to access managed services privately from inside their VPC network. Please review documentation for specific configuration details.
Misconfigurations	Exposed APIs, weak authentication, or insecure integrations can create entry points for attackers.	CDSPaaS is continuously working to address such issues by: - Offering customers the ability to support configuration of the services through a GUI or via REST API calls. - Ensuring that as we add new technology integrations to the portfolio, we are following best practices in terms of secure integration and access between CDSPaaS and the 3rd party application. - Provide customers with access to our Support, Professional Services and technology implementation partners to ensure proper configuration and deployment.

Q: How does the hosting environment support disaster recovery and business continuity?

A: Each production region has an associated DR site with replicated services and databases, with documented recovery procedures and typical recovery time objectives depending on failure and corruption scenarios.

Scenario	Description	Recovery Time
Primary region went down	Here we assume that there is: - no Data corruption - no database backup - Recovery is required. CDSPaaS DBs read replicas will be up to date to the point of region failure and when we bring DR site up, it will be up from that point of time when region went down.	1 hour Note: Site is up within 30 mins once the DNS is switched; read replica creation can also perform in the background.
Primary region down + DB corruption	Here we must perform a two step recovery: - Site switch: Primary to DR or vice-versa - DBs Restore	1h 40mins Note: Site is up within 30 mins once the DNS is switched; read replica creation can also perform in the background.
Primary site is up but observe DB corruption	Here we will only restore DBs to their previous healthy state.	40 mins

4. Authentication, access control, and separation of duties

Q: How is access to CDSPaaS determined and authenticated?

A: Access is scoped by the service region chosen during provisioning and uses DPoD tenancy plus CDSPaaS user and client identities for authentication to the UI, CLI, and REST APIs. Local users and DPoD-based identities can be used, with MFA and IDP integration available or planned according to the DPoD roadmap.

Q: What security measures protect the administration interfaces?

A: Users and clients authenticate to the service and are assigned to groups that define permissions; all administrative and cryptographic operations are logged with the relevant identity. This model supports the least privilege and provides a clear audit trail.

Q: How does CDSPaaS support separation of duties and quorum?

A: CDSPaaS supports key policies, groups, and quorum for selected key lifecycle operations so that sensitive tasks can require multiple approvals. See Key Policies for more details. Access can be based on local users or identities federated via the DPoD platform. CDSPaaS KMS utilizes policies to determine the necessary controls between key administrators and key consumers. See the following link for a breakdown of the Operations Supported by Quorom.

Q: What security measures protect the administration interface (encryption, brute force protection, etc.)?

A: Two entity types can authenticate to CipherTrust Data Security Platform Service web console UI, ksctl CLI and REST API: clients and users.

Clients are applications that access CDSPaaS keys as needed to perform cryptographic or key management operations. Users are people who access the CipherTrust Data Security Platform Service to perform configuration and key management tasks manually. CipherTrust Data Security Platform Service authenticates a user or client, CipherTrust Data Security Platform Service checks the user or client's group membership, and applies the permissions associated with those groups.
Any cryptographic or key management operation occurs over a client. CDSPaaS always attempts to identify the client for these operations and adds the client's identity to the DPoD audit query records if identified. Client authentication occurs when a client's identity is found.
CDSPaaS authenticates users when a user identity is presented with the request. This authentication provides a mechanism to enforce permissions on a user and an audit trail of a user's activities.
It is possible to only provide a client identity and not a user identity, in which case the client is the authenticated entity, and its identity appears in the audit record. This authentication is appropriate for an automated client or a service account that requires no human interaction.
When a user's identity is presented, with or without a client identity, only the user is authenticated. The client's actions are assumed to be performed on behalf of a user.
CipherTrust Data Security Platform Service authenticates a user or client, CipherTrust Data Security Platform Service checks the user or client's group membership, and applies the permissions associated with those groups.

5. Logging, monitoring, SLA, and alerts

Q: How can customers use CDSPaaS logs with SIEM tools and how long are logs stored?

A: Customers can export audit logs from the DPoD tenant associated with CDSPaaS and forward them to external syslog/SIEM solutions, with the service retaining logs on a rolling 7-day basis. Long term retention is the customer’s responsibility via log export. See Audit Logging for further details.

Q: How is SLA compliance monitored and communicated?

A: Internal SLIs and SLOs are maintained for performance and availability, and external uptime and incident information is published via the DPoD Status site where customers can subscribe to notifications. Subscribe for alerts by signing up at DPoD Status.

Q: What update and patching model does CDSPaaS use?

A: Thales DevOps operates a regular update cycle to deliver fixes and enhancements across the multi-tenant environment; updates are centrally controlled and applied to all tenants.

Q: Are anti-DDoS protections in place or supported?

A: Alerts have been created within our DevOps Monitoring processes to provide feedback if CDSPaaS is under a higher-than-expected load. Should a customer need to exceed those boundaries, Thales would prefer to validate their deployment scenario in a staging infrastructure prior to rolling forward new connection limits into Production.

Q: Are there limits on CTE deployments in CDSPaaS?

A: Per documentation, each CDSPaaS service supports up to 500 combined CTE clients, CTE UserSpace clients, and CTE-K8 nodes of a Kubernetes cluster. We recommend up to 200 guardpoints per client. Should you have a scenario where more client/guardpoints are required, please contact your account team.

6. Scalability, limits, and deployment scale

Q: How does CDSPaaS scale with demand?

A: CDSPaaS uses a microservices-based architecture that automatically scales services such as CTE and CCKM based on load, with subscription terms governing commercial usage and overage handling.

Q: Are there limits on CTE deployments in CDSPaaS?

A: Each CDSPaaS instance supports documented limits on the number of CTE and CTE related clients and recommended guardpoints per client, and customers should engage Thales if their use case exceeds standard guidelines.

7. Regions, connectivity, and migration between regions

Q: How is regional access handled and can keys move between regions?

A: CDSPaaS provides distinct regions (for example, Americas and Western Europe) with separate infrastructure and HSM backends, but customers are not restricted from consuming services in another region. Migration of tenant content or keys between regions is possible with coordination from Thales DevOps.

Q: How is communication between CDSPaaS and customer environments secured?

A: Connectivity is configured via the management console or REST API, and can use options such as VPNs or Google Private Service Connect to provide private cloud to cloud or cloud to on premises connectivity where appropriate.

8. Security controls, WAF, DDoS, and threat mitigation

Q: Is a Web Application Firewall or anti DDoS protection in place?

A: CDSPaaS is protected by a cloud WAF service and monitored for abnormal traffic patterns, with DevOps processes to review and adjust limits when customers have high throughput needs.

Q: How does CDSPaaS reduce the risk of SaaS compromise and common attack vectors?

A: CDSPaaS combines strong tenant isolation via dedicated HSM partitions, access control, vulnerability management, and secure integration patterns to address threats such as account takeover, data breaches, misconfigurations, and insecure SaaS to SaaS links.

9. Governance, reversibility, and legal requests

Q: How is responsibility shared between customer and Thales?

A: Thales operates, maintains, and supports the platform and its SLA, while customers remain responsible for configuring use cases, enforcing internal policies, and meeting compliance obligations related to their data and keys.

Q: Could you please explain your reversibility clause? Specifically, how does your solution ensure data and configuration portability? What processes are in place to allow a smooth migration or exit if needed?

A: Customers may export encryption keys from CDSPaaS Key Management Service to be used by other applications. All other configuration information related to CDSPaaS is for its own purposes and therefore not of much value to the customer. Alternatively, the customer could facilitate a maintenance window to decrypt all data protected by CDSPaaS and re-encrypt with the new solution.

Q: How does CDSPaaS intend to meet a legal inquiry for information based on the US Cloud Act or similar legislation?

A: Currently, the CLOUD Act does not create surveillance powers or unfettered access to materials stored within cloud or other digital services. Similarly, using a national service provider does not guarantee data will be beyond the reach of domestic or international jurisdiction. As a result, the effective management of information in the digital age requires a risk-based approach that considers all relevant factors and costs, including the availability of technology-based solutions To date, Thales CSP has not received a request to produce data under the US Cloud Act or similar legislation. As a legally responsible entity, Thales would follow due process if legitimately compelled to provide access to the tenant's information. However, please note that any tenant encryption keys (and by association with any data encrypted with those keys) will not be functional without access to the MEK stored in Luna Cloud HSM outside of our CDSPaaS infrastructure. While we understand the perceived risk the Cloud Act presents to customers, it is our belief that the architecture and deployment of CDSPaaS and Luna Cloud HSM has implemented a balanced security posture that allows us to make the service accessible globally without 100% dependence on a central vendor and the risks presented by the US Cloud Act. Full details of the security practices for the Data Protection on Demand platform, including details of the ISO 27001, SOC2, CSA STAR2 and FIPS certifications held by the platform and components are published at DPoD Marketplace Architecture and Security White Paper.