Data Sovereignty and Regional Compliance Challenges in PKIaaS

When an organization adopts PKI as a Service, the PKI infrastructure moves: CA keys, audit logs, certificate metadata, administrative access, and backup data all move from systems the organization operates directly to systems operated by (or in partnership with) a third party. For most organizations, this move is operationally beneficial. For organizations subject to data sovereignty requirements, key custody mandates, or regional compliance frameworks, the move creates specific questions that must be answered before selecting a deployment model and before signing a contract.

Where do the CA private keys actually reside, physically and legally? In which jurisdiction is the certificate issuance audit log processed and stored? Who has administrative access to the management console, and from which countries are those administrators operating? If the PKIaaS provider has a subprocessor relationship with a cloud infrastructure provider, which jurisdiction governs the subprocessor’s data handling? These are not hypothetical questions. They are the questions that GDPR auditors, NIS2 competent authorities, FedRAMP assessors, and banking regulators ask when examining an organization’s PKI program.

This post is written for compliance teams, CISOs, and legal counsel at government agencies, financial institutions, and regulated enterprises evaluating PKIaaS for environments with data sovereignty or key custody requirements. It explains what data elements have sovereignty implications, how those implications map to specific regulatory frameworks, and how deployment model selection resolves or creates compliance challenges.

Quick Answer: What Data Elements in PKIaaS Have Sovereignty Implications?

Five categories of data in a PKIaaS deployment have sovereignty implications: CA private key material (the cryptographic keys in HSMs); certificate issuance and audit logs (records of every certificate lifecycle event); certificate metadata embedded in issued certificates (subject names, SANs, organizational identifiers); administrative access logs (who accessed the management console, from where, and what they did); and backup and recovery data (encrypted key backups and certificate database backups). Each category is treated differently by different regulatory frameworks. CA private key material is the most frequently restricted. Audit logs and certificate metadata are the most frequently overlooked. Administrative access from foreign jurisdictions is the most operationally difficult to constrain.

Key Takeaways

• Data sovereignty and key custody are related but legally distinct requirements. Data residency governs where data is geographically stored and processed. Key custody governs who physically controls the hardware holding cryptographic keys. A deployment can satisfy data residency (infrastructure in a specific country) without satisfying key custody (provider staff in a different country can administer the HSMs). Both requirements must be analyzed separately for each applicable framework.
• GDPR applies to PKIaaS deployments when the certificates issued contain personal data. User certificates (S/MIME, smart card logon, TLS client auth) typically include the subject’s name and email address, making the PKIaaS provider a data processor under GDPR Article 28. A Data Processing Agreement is required, and transfers of EU personal data to non-EEA countries require an Article 46 transfer mechanism. This is frequently overlooked in PKI compliance assessments because PKI is perceived as infrastructure rather than personal data processing.
• NIS2 (Directive 2022/2555/EU) and DORA (Regulation 2022/2554/EU) both create specific PKI-related obligations for essential and important entities (NIS2) and financial entities (DORA). NIS2 requires secure supply chain management for critical ICT components; PKI is a critical ICT component. DORA Article 28 imposes concentration risk limits on ICT third-party service providers and requires contractual provisions governing data location and key custody. Both frameworks require organizations to understand and document where their PKI data resides.
• The vendor-hosted PKIaaS deployment model is appropriate for most organizations without specific key custody or data residency requirements. Customer-hosted and hybrid models exist specifically for organizations with requirements that vendor-hosted cannot satisfy: key custody mandates (CMMC Level 3, ITAR, classified programs), geographic data restrictions (some NIS2 national implementations, BSI C5 for German federal systems, sector-specific data localization requirements), or air-gapped deployments for classified or isolated environments.
• The PKIaaS provider’s subprocessor disclosure is a critical but frequently overlooked document. Most cloud services use subprocessors (underlying cloud infrastructure, CDN, monitoring services). If the PKIaaS provider processes EU personal data through a US-based subprocessor without an adequate transfer mechanism, the customer may inherit a GDPR compliance gap that was not disclosed during procurement. Review the subprocessor list and the Data Processing Agreement before signing.

The Five Data Elements and Their Sovereignty Implications

1. CA Private Key Material

CA private key material is stored in HSMs at specific physical locations. In a vendor-hosted deployment, the HSMs are in the provider’s data centers. The physical location of those data centers, and the legal jurisdiction governing the data centers’ operation, determines the geographic scope of the key material’s residency. In a customer-hosted deployment, the customer’s own HSMs hold the CA private keys, and the physical location is entirely the customer’s choice.

The sovereignty question for CA key material is both geographic and legal. Geographic: in which country are the HSMs physically located? Legal: under which jurisdiction’s laws can a government authority compel disclosure or access to the key material? These two questions can have different answers: an HSM in a data center in the EU may be operated by a US-incorporated company subject to US legal process, creating a legal access risk even if the HSM is physically in an EU location.

For organizations with key custody requirements (CMMC Level 3 for defense contractors processing CUI; ITAR for defense-related technology; classified program requirements), the requirement is typically that the regulated entity must exclusively control the HSMs holding CA key material, and that no third party has physical or logical access to those HSMs for purposes of extracting key material. This requirement is satisfiable in a customer-hosted deployment and not satisfiable in a standard vendor-hosted deployment.

2. Certificate Issuance and Audit Logs

The PKIaaS audit log records every certificate lifecycle event: issuance requests (including the requester’s identity and the certificate’s subject fields), renewals, revocations, administrator logins, and CA administrative operations. For user certificates, the audit log contains personal data: the user’s name, email address, and organizational identifier appear in the certificate’s Subject Distinguished Name and in the Subject Alternative Name field.

Under GDPR, processing personal data requires a lawful basis (Article 6), and if the PKIaaS provider stores audit log records in non-EEA infrastructure, a transfer mechanism is required (Article 46). The audit log is not just a technical record; it is a personal data record under GDPR, and it must be protected accordingly. Organizations that adopt vendor-hosted PKIaaS should confirm with the provider: in which country are audit logs stored, are logs replicated to non-EEA locations, and what is the data retention period for log records.

Beyond GDPR, audit logs are compliance evidence for framework-specific obligations. FedRAMP requires that audit logs for federal systems be accessible to the sponsoring agency. DORA requires that ICT third-party providers make audit logs available to competent authorities. NIS2 requires that essential entities maintain auditable records of their ICT supply chain. If the PKIaaS provider stores audit logs in a jurisdiction that does not cooperate with the customer’s regulatory authority, the customer may be unable to produce required audit evidence.

3. Certificate Metadata in Issued Certificates

X.509 certificates are public by design: the Subject DN, SANs, issuer information, and extensions are unencrypted and can be read by any party who encounters the certificate in a TLS handshake, in an email message, or in a certificate transparency log. For device and server certificates, this is generally not a sovereignty concern. For user certificates, the personal data embedded in the certificate (name, email, organizational role) is publicly accessible once the certificate is in use.

The sovereignty implication for certificate metadata is less about storage jurisdiction and more about disclosure scope. Certificate Transparency (CT) logs, required for publicly trusted certificates, make every issued certificate publicly searchable. For privately trusted certificates (which PKIaaS typically issues), CT logging is not mandatory, and many PKIaaS deployments do not submit private CA certificates to public CT logs. Organizations should confirm whether their PKIaaS provider submits internally issued certificates to public CT logs, particularly for certificates containing employee personal data.

4. Administrative Access

Administrative access to the PKIaaS management console (creating certificate profiles, managing CA configuration, performing revocations, reviewing audit logs) can originate from any geographic location unless the provider and customer explicitly configure access restrictions. If provider support staff in a third country can access the management console for the customer’s PKI partition, that access constitutes a cross-border data transfer under GDPR (if the console displays personal data from the audit log), a potential sovereignty issue for government customers, and a supply chain security risk for organizations subject to NIS2 or DORA.

Organizations with strict administrative access requirements should confirm with the provider: whether administrative access can be restricted to specific IP ranges or geographic locations, whether provider support staff access to the customer’s partition requires the customer’s explicit approval, whether all administrative access events are logged with the accessing party’s location and identity, and whether a “no-access” support model is available in which provider staff cannot access customer certificate data without the customer’s explicit one-time authorization.

5. Backup and Recovery Data

CA private key backups and certificate database backups must be stored at a location different from the primary HSM to serve their DR purpose. In a vendor-hosted deployment, the backup location is the provider’s choice unless the customer specifies geographic restrictions in the contract. If the primary PKI infrastructure is in the EU and the backup is in a US data center, the backup CA key material is subject to US legal jurisdiction, which may conflict with EU sovereignty requirements even if the primary infrastructure satisfies them.

The backup’s jurisdiction should be specified in the contract with the same precision as the primary infrastructure’s jurisdiction. A contract that guarantees primary infrastructure in the EU but does not specify the backup location has a potential sovereignty gap in the DR scenario that is most likely to be exercised under stress.

Regulatory Frameworks and PKIaaS Implications

GDPR (EU/EEA)

GDPR applies to PKIaaS deployments where certificates include personal data (user certificates with name, email, UPN), where the controller or processor is established in the EU/EEA, or where the processing relates to data subjects in the EU/EEA. The key GDPR obligations for PKIaaS are: a Data Processing Agreement (DPA) under Article 28 between the customer (controller) and the PKIaaS provider (processor); a legitimate transfer mechanism under Article 46 if the provider processes EU personal data from non-EEA infrastructure (Standard Contractual Clauses are the most common mechanism); the provider’s subprocessor list must be reviewed and any material changes must be notified to the customer; and data retention periods for audit logs must be documented and enforceable.

Practical PKIaaS deployment implications: confirm the primary data center location, the audit log storage location, the backup location, and the administrative access location are all within the EEA or covered by an adequate transfer mechanism. For customer-hosted deployments, the PKIaaS provider’s management platform may still process some data (if a connector phones home to the provider’s management console); confirm whether that connectivity involves personal data transfer and whether it is covered by the DPA.

NIS2 (Directive 2022/2555/EU)

NIS2 covers essential and important entities in 18 sectors including energy, transport, banking, financial market infrastructure, health, digital infrastructure, and public administration. PKI is a critical ICT component for most of these entities. NIS2 Article 21 requires entities to implement supply chain security measures for ICT components, which includes evaluating the security of PKI service providers. NIS2 Article 23 imposes incident notification requirements that are fulfilled partly through having adequate PKI audit logs available to competent authorities.

NIS2 does not mandate specific geographic data restrictions at the EU level, but national implementations may. Germany’s implementation aligns NIS2 with BSI C5 requirements for critical infrastructure operators. France’s implementation through ANSSI guidance imposes specific requirements for sovereign cloud services used by OIV (Operators of Vital Importance). The Netherlands, Belgium, and Scandinavian implementations have varying interpretations of NIS2’s supply chain security requirements as applied to cloud PKI. Organizations subject to NIS2 must confirm which national implementation applies to their entity and what that implementation requires of their PKI supply chain.

DORA (Regulation 2022/2554/EU)

DORA applies to financial entities in the EU: banks, payment institutions, investment firms, insurance companies, crypto-asset service providers, and others. DORA Article 28 requires financial entities to assess ICT third-party concentration risk. If a single PKIaaS provider issues all certificates for a significant portion of the EU financial sector, regulators may raise concentration concerns. DORA Article 30 requires contractual provisions in ICT third-party agreements that specify: the locations where data is processed and stored; the provider’s obligations regarding data portability and data return on exit; audit rights for the financial entity and competent authorities; and incident notification obligations.

For PKIaaS specifically, DORA compliance requires the contract with the PKIaaS provider to explicitly state the geographic location of CA infrastructure and audit log storage, grant the financial entity audit access rights (directly or through an independent auditor), specify the PKIaaS provider’s RTO and RPO commitments, and address the process for terminating the relationship and recovering CA key material. A PKIaaS provider who cannot satisfy these contractual requirements is not suitable for DORA-regulated financial entity deployments.

FedRAMP (United States Federal)

FedRAMP (Federal Risk and Authorization Management Program) establishes security requirements for cloud services used by US federal agencies. PKIaaS used by federal agencies is a cloud service subject to FedRAMP authorization requirements. FedRAMP Moderate authorization requires the provider to have undergone a Third Party Assessment Organization (3PAO) assessment against NIST SP 800-53 controls. FedRAMP High requires a higher control baseline appropriate for systems with high confidentiality, integrity, or availability requirements.

For federal agencies, PKIaaS providers should be selected from those with active FedRAMP authorization at the appropriate impact level, verified through the FedRAMP Marketplace. A provider who claims FedRAMP “readiness” or “compliance” without an active authorization has not completed the assessment process and cannot be treated as FedRAMP-authorized. Key custody requirements for federal PKI programs are addressed through NIST SP 800-57 Part 2 and agency-specific security requirements that may mandate customer-controlled HSMs, particularly for root CA operations.

ITAR and CMMC (US Defense)

ITAR (International Traffic in Arms Regulations) restricts the export of defense articles and services, including cryptographic technology and key material used in defense programs. For defense contractors using PKIaaS to issue certificates to systems involved in ITAR-controlled programs, the CA private key material and administrative access to the PKI management console must be restricted to US persons and US-located infrastructure. A vendor-hosted PKIaaS provider whose administrative staff or HSM infrastructure is outside the United States may create an ITAR violation for a defense contractor customer, even if the customer did not intend to export controlled technology.

CMMC (Cybersecurity Maturity Model Certification) Level 3 introduces requirements for protecting CUI (Controlled Unclassified Information) at a higher assurance level. For CMMC Level 3, the organization must demonstrate exclusive control over key material used to protect CUI systems. A vendor-hosted PKIaaS deployment where the provider controls the HSMs and administrative access does not satisfy this requirement. A customer-hosted or hybrid deployment where the organization’s own HSMs hold the CA keys and administrative access is restricted to the organization’s vetted US persons is the appropriate architecture for CMMC Level 3 PKI programs.

BSI C5 (Germany)

The German Federal Office for Information Security (BSI) Criteria Catalogue Cloud Computing (C5) defines requirements for cloud services used by German federal authorities and regulated entities. For PKIaaS, BSI C5 is particularly relevant in areas covering data location (DL-01 to DL-03: data must be processed in the EU/EEA or equivalent jurisdictions; exceptions require explicit customer approval and documentation), cryptographic key management (KRY-01 to KRY-04: key generation, storage, rotation, and destruction procedures must be documented and auditable), and supply chain transparency (SCA-01 to SCA-03: subcontractors and subprocessors must be disclosed; changes must be notified).

German public sector organizations and critical infrastructure operators regulated under the German IT Security Act (IT-Sicherheitsgesetz 2.0) typically require BSI C5 Type 2 attestation from cloud service providers, or customer-hosted deployment within BSI C5-attested infrastructure. A vendor-hosted PKIaaS provider without BSI C5 Type 2 attestation is generally not acceptable for these use cases in Germany.

Sector-Specific Frameworks

Banking and financial services: Beyond DORA, national banking regulators in the EU (EBA guidelines on ICT risk management) and globally (Basel III operational resilience expectations, local central bank regulations) impose ICT third-party risk management requirements. For PKIaaS used in payment systems and core banking authentication, regulators typically expect the bank to control or at least have verifiable access to the PKI’s audit logs and to have tested continuity of PKI services as part of the institution’s operational resilience program.

Healthcare: HIPAA Technical Safeguards require access controls and transmission security for ePHI-handling systems. For healthcare organizations using PKIaaS to issue certificates to systems handling ePHI, the PKIaaS provider is a Business Associate under HIPAA, and a BAA is required. The BAA must address where audit logs containing potentially identifiable information are stored and who can access them.

Critical infrastructure: IEC 62443 security levels for industrial control systems create requirements for network segmentation and access control that affect PKI architecture. For high-security ICS environments (Security Level 3 or 4), PKI infrastructure for machine authentication must meet strict isolation requirements that typically require customer-hosted or air-gapped deployment rather than vendor-hosted.

Mapping Regulatory Requirements to Deployment Models

Regulatory requirement	Vendor-hosted	Customer-hosted	Hybrid	Key contract provisions needed
GDPR personal data in certificates	Requires DPA + Article 46 transfer mechanism if non-EEA processing	Satisfies if infrastructure is EEA; confirm connector data flows	Confirm which data the vendor-hosted components process	DPA, subprocessor list, geographic processing restrictions, retention periods
NIS2 supply chain security	Requires provider’s security attestation and audit access rights	Reduces supply chain risk; residual risk in provider management connector	Split; verify each component’s regulatory classification	Audit access rights, incident notification timelines, key custody documentation
DORA (EU financial entities)	Requires explicit geographic data location, audit rights, exit provisions in contract	Greater customer control; still requires DORA-compliant contract terms	Document which entity controls which component for regulatory reporting	DORA Article 30 provisions: data location, audit, exit, concentration risk assessment
FedRAMP (US federal)	Requires active FedRAMP authorization at appropriate impact level	Requires deployment in FedRAMP-authorized environment	Split authorization; complex boundary documentation	FedRAMP authorization verification, agency ATO documentation
ITAR / CMMC L3 (US defense)	Generally not satisfiable; provider HSMs and admin access not US-controlled	Required model; customer HSMs, US-only admin access	Root CA customer-hosted (US); provider issuing CAs may not be ITAR-compliant	ITAR-controlled systems list, US person access restrictions, key custody documentation
BSI C5 (Germany)	Requires BSI C5 Type 2 attestation from provider; EU data location	Acceptable if infrastructure is BSI C5-attested; subprocessors must be disclosed	Both components must satisfy C5 requirements separately	C5 Type 2 attestation, subprocessor disclosure, DL-01 to DL-03 compliance
HIPAA (US healthcare)	Requires BAA; confirm ePHI-related log data handling	Customer-controlled environment; provider software must be covered by BAA	BAA must cover both components; verify audit log data flow	HIPAA BAA, ePHI handling restrictions, audit log access controls

Essential Contractual Provisions for Sovereignty-Compliant PKIaaS

Regardless of which regulatory framework applies, the following contractual provisions should be present in any PKIaaS agreement where data sovereignty or key custody is a compliance requirement. Their absence from a contract is a procurement risk that should be resolved before signing.

Geographic specificity for all data types: The contract should specify, by named country or region, where each of the five data categories (CA key material, audit logs, certificate metadata database, administrative access, backups) is stored and processed. A clause stating “data will be stored in the European Union” does not specify which member state, whether the backup is included, or whether subprocessors in the EU can transfer data to non-EU affiliates.

Subprocessor disclosure and notification: The contract should require the provider to maintain a current list of subprocessors (including cloud infrastructure providers, CDN providers, and monitoring service providers) and to notify the customer of material changes to the subprocessor list before those changes take effect, with a right for the customer to object to new subprocessors that create compliance conflicts.

Audit access rights: The contract should grant the customer (and, where applicable, the customer’s competent authority) the right to audit the provider’s controls relevant to the customer’s PKI deployment. This includes the right to inspect audit logs, the right to commission a third-party assessment, and the right to review the provider’s SOC 2 Type II report or equivalent attestation. A provider who refuses audit access rights in the contract is not suitable for regulated entity deployments where regulators require supply chain auditability.

Administrative access restrictions: For ITAR, CMMC, classified programs, and some government sector deployments, the contract must specify that provider administrative staff access to the customer’s PKI partition is restricted to vetted personnel in approved jurisdictions, that access requires the customer’s explicit authorization, and that all access events are logged and reportable to the customer.

Key custody documentation: For customer-hosted and hybrid deployments, the contract should document the key custody model: who holds the CA private keys, where the HSMs are located, what access controls govern HSM operations, and what the key recovery procedure is in the event of HSM failure. This documentation is the evidence auditors need to verify that key custody requirements are satisfied.

Data portability and exit provisions: DORA explicitly requires ICT third-party contracts to address data portability and the return of data on exit. For PKIaaS, this means the contract should specify how the customer can export all certificate records, audit logs, and (for customer-hosted deployments) how the CA key material is retained after the relationship ends. An exit that leaves the customer unable to access historical audit records or to continue operating with their existing certificate hierarchy is a compliance and operational risk.

Practical Assessment Steps for Regulated Organizations

For organizations beginning a PKIaaS procurement under data sovereignty or key custody constraints, the following sequence reduces the risk of selecting a deployment model or provider that cannot satisfy the applicable requirements.

Step 1: Inventory the applicable regulatory frameworks. Work with legal counsel to identify every framework that applies to the organization’s PKI use cases. A healthcare organization in Germany operating in the financial sector may be subject to GDPR, NIS2 (German implementation), BSI C5, and HIPAA. Each framework may impose different and potentially conflicting requirements; identify conflicts early.

Step 2: Map certificate types to personal data classification. Determine which certificate types the PKIaaS deployment will issue and whether any contain personal data. User certificates (S/MIME, smart card, TLS client auth) containing names and email addresses are personal data under GDPR. Device and server certificates typically contain only technical identifiers and are lower risk.

Step 3: Confirm the provider’s geographic infrastructure specifics. Request in writing: the physical location (country) of primary CA infrastructure; the location of audit log storage; the location of backup infrastructure; the location from which provider administrative access to the customer’s partition originates; and the identities and locations of all subprocessors involved in the PKIaaS service. Do not accept “in the EU” without a named country or named data center.

Step 4: Review the DPA and subprocessor list. If GDPR applies, the DPA must be in place before any personal data is processed. Review it against the GDPR Article 28(3) mandatory provisions. Confirm the subprocessor list includes all relevant parties and that the notification procedure for changes is workable for your organization’s approval process.

Step 5: Confirm the deployment model satisfies key custody requirements. If your framework requires customer-controlled key custody, confirm that the selected deployment model actually provides it and that the contract specifically reflects the key custody model. A vendor-hosted deployment with a clause saying the customer “retains data ownership” does not provide key custody; the physical HSMs holding the keys are still the provider’s.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering supports vendor-hosted, customer-hosted, and hybrid deployment models, with contractual geographic specificity for data residency, DPA for GDPR-applicable deployments, and key custody documentation for customer-hosted and hybrid models. Contact us at Encryption Consulting to discuss your sovereignty and compliance requirements.
• Compliance Advisory Services: Encryption Consulting’s Compliance Advisory Services provide structured assessments of PKIaaS procurement against GDPR, NIS2, DORA, FedRAMP, ITAR/CMMC, and sector-specific frameworks. We produce a gap analysis of the proposed PKIaaS architecture against each applicable framework and the contractual provisions required to close those gaps, in a format that can be presented to auditors and regulators.
• PKI Assessment Service: For organizations with an existing PKIaaS deployment whose sovereignty and compliance documentation is incomplete, Encryption Consulting’s PKI Assessment Service reviews the current deployment against the applicable regulatory frameworks and produces a remediation plan covering deployment model, contractual, and governance gaps.
• PKI Services (CP/CPS Development): Data sovereignty and key custody requirements must be reflected in the organization’s Certificate Policy and CPS. Encryption Consulting’s PKI Services include CP/CPS development and revision services that incorporate data residency, key custody, and supply chain transparency requirements from applicable regulatory frameworks into the formal PKI governance documentation.
• HSM as a Service: For organizations selecting customer-hosted or hybrid deployment to satisfy key custody requirements, Encryption Consulting’s HSM as a Service provides dedicated FIPS 140-3 Level 3 certified HSM capacity with full customer control and geographic specificity, in locations that satisfy common data residency requirements for EU, US, and UK deployments.

Conclusion

Data sovereignty in PKIaaS is not a single requirement; it is a family of related requirements spanning geographic data location, legal jurisdiction, key custody, administrative access, and subprocessor disclosure that vary by regulatory framework and sector. An organization subject to GDPR, DORA, and BSI C5 simultaneously must satisfy different and partially overlapping requirements across all three frameworks, and the PKIaaS deployment model and contract must be designed to satisfy all of them.

The deployment model choice is the starting point, but it does not resolve sovereignty requirements by itself. A customer-hosted deployment places CA key material in the customer’s environment, but if the provider’s management software phones home to a US-based cloud service, there is still a potential cross-border data flow. A vendor-hosted deployment in an EU data center may still route audit logs through a US-based monitoring service. The complete sovereignty picture requires mapping all five data elements through all system components, including the ones that are invisible unless you ask specifically about them.

For government agencies, financial institutions, defense contractors, and healthcare organizations, getting this right before procurement is significantly less expensive than getting it wrong after deployment. The remediation of a sovereignty gap in a deployed PKI program, including potentially re-keying a CA hierarchy, re-issuing certificates, and re-negotiating provider contracts, is a major undertaking. Investing in a structured sovereignty assessment during procurement is the more economical path.

If your organization is evaluating PKIaaS under data sovereignty or key custody requirements and needs structured compliance support, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when GDPR enforcement decisions, NIS2 national transposition measures, DORA implementing technical standards, or FedRAMP program updates materially affect the PKIaaS compliance landscape.

Frequently Asked Questions

What data elements in a PKIaaS deployment have data sovereignty implications?

Five categories: CA private key material (in HSMs); certificate issuance and audit logs (containing personal data for user certificates); certificate metadata embedded in issued certificates; administrative access logs (who accessed the management console, from where); and backup and recovery data. Each category may be subject to different geographic restrictions under applicable regulatory frameworks. CA private key material is the most frequently restricted; audit logs and administrative access are the most frequently overlooked.

Does GDPR apply to PKIaaS deployments?

Yes, when certificates issued contain personal data. User certificates (S/MIME, smart card logon, TLS client auth) typically include names and email addresses, making the PKIaaS provider a data processor under GDPR Article 28. A Data Processing Agreement is required. If the provider processes EU personal data from non-EEA infrastructure, an Article 46 transfer mechanism (Standard Contractual Clauses) is required. The subprocessor list must also be reviewed, as subprocessors in non-EEA jurisdictions create additional transfer compliance obligations.

What is the difference between data residency and key custody in PKIaaS compliance?

Data residency governs where data is geographically stored and processed. Key custody governs who physically controls the hardware holding CA private keys. A deployment can satisfy data residency (infrastructure in a specific country) without satisfying key custody (provider staff in another country can administer the HSMs). Both requirements must be analyzed separately: CMMC and ITAR address key custody; GDPR and some NIS2 national implementations address data residency.

Can a vendor-hosted PKIaaS deployment satisfy FedRAMP requirements?

A vendor-hosted PKIaaS can satisfy FedRAMP Moderate if the provider has an active FedRAMP authorization at Moderate impact level for the PKIaaS service, verified through the FedRAMP Marketplace at marketplace.fedramp.gov. FedRAMP High requirements are harder to satisfy in fully vendor-hosted deployments; customer-hosted or hybrid models that keep CA key material within the agency’s or a FedRAMP High-authorized cloud environment are typically more appropriate for High-impact systems.

What is BSI C5 and how does it affect PKIaaS deployments in Germany?

BSI C5 (Cloud Computing Compliance Criteria Catalogue) is the German BSI’s framework for cloud service security. For PKIaaS, the relevant controls address data location (DL-01 to DL-03: EU/EEA processing or explicit approval required), cryptographic key management (KRY-01 to KRY-04: key generation, protection, and custody procedures must be documented), and supply chain transparency (SCA-01 to SCA-03: subcontractors must be disclosed). German public sector and critical infrastructure organizations typically require BSI C5 Type 2 attestation from PKIaaS providers.