--- title: "ETSI EN 319 411-1 FAQ for Certificate Services" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/items" author: "Sorena AI" description: "Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1" - "certificate policy" - "certification practice statement" - "CA operations" - "revocation evidence" - "subscriber validation" - "CPS" - "certificate revocation" --- **[SORENA](https://www.sorena.io/)** - AI-Powered GRC Platform [Home](https://www.sorena.io/) | [Solutions](https://www.sorena.io/solutions) | [Artifacts](https://www.sorena.io/artifacts) | [About Us](https://www.sorena.io/about-us) | [Contact](https://www.sorena.io/contact) | [Portal](https://app.sorena.io) --- # ETSI EN 319 411-1 FAQ for Certificate Services Answers to common ETSI EN 319 411-1 questions on certificate policies, CPS content, CA and RA boundaries, subscriber evidence, revocation, status services, and record retention. *Artifact Guide* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 Certificate Services FAQ Answers for TSP teams applying ETSI EN 319 411-1 to certificate policies, CPS commitments, certificate lifecycle controls, and audit evidence. Grounded in ETSI EN 319 411-1 V1.5.1 and ETSI EN 319 401. Use it as implementation guidance, not for legal interpretation. This FAQ explains how ETSI EN 319 411-1 applies to trust service providers issuing certificates. It focuses on the recurring questions behind certificate policy selection, CPS evidence, CA and RA responsibilities, subscriber validation, revocation, status services, and records that auditors and relying parties expect to trace. ## Browse sub-FAQ modules ### [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md) Understand how ETSI EN 319 411-1 separates Certificate Policy from Certification Practice Statement work for certification authorities and trust service providers. - 3 items ### [ETSI EN 319 411-1 certificate re-key FAQ](/artifacts/global/etsi-en-319-411-1/faq/re-key.md) What ETSI EN 319 411-1 requires when a TSP re-keys an existing certificate with a new subject public key. - 3 items ### [ETSI EN 319 411-1 Certificate Suspension FAQ](/artifacts/global/etsi-en-319-411-1/faq/suspension.md) How CAs should handle certificate suspension under ETSI EN 319 411-1: CPS disclosure, validated requests, status publication, subscriber notice, and audit evidence. - 3 items ### [ETSI EN 319 411-1 Certification Audit Evidence FAQ](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md) How CAs should prepare ETSI EN 319 411-1 audit evidence for CP/CPS scope, registration records, revocation records, CA key logs, and retained assessment files. - 3 items ### [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md) What ETSI EN 319 411-1 expects CAs to evidence for certificate revocation requests, status publication, CRL or OCSP updates, and archived revocation records. - 3 items ### [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md) How certificate authorities can delegate registration authority work under ETSI EN 319 411-1 while keeping identity validation, secure data exchange, role controls, and audit evidence traceable. - 3 items ### [Subscriber agreements under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md) How ETSI EN 319 411-1 expects CAs and TSPs to inform subscribers, record acceptance, handle subject consent, and retain subscriber-agreement evidence. - 3 items ### [Subscriber identity validation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-identity-validation.md) How certificate authorities should validate subscriber and subject identity under ETSI EN 319 411-1, including evidence, authorization, subject categories, and registration records. - 3 items Browse all indexed questions: [/artifacts/global/etsi-en-319-411-1/faq/items](/artifacts/global/etsi-en-319-411-1/faq/items.md) ## All FAQ items *Page 1 of 2. Showing 20 of 24 items.* ### [What is the practical difference between a CP and a CPS?](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md#what-is-the-practical-difference-between-a-cp-and-a-cps) *Module: [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md)* The CP is the policy layer. It identifies the certificate policy, quality level, profile, applicability, and requirements that apply to a certificate service or certificate community. ETSI EN 319 411-1 notes that a CP can be defined by the TSP, ETSI, a government, customers, or another community, and that it can be standalone or included within practice statements or terms and conditions. - Use the CP to state the certificate policy being followed, including policy identifiers, applicability, certificate profile expectations, and any adopted ETSI policy such as LCP, NCP, NCP+, DVCP, OVCP, IVCP, or EVCP where relevant. - Use the CPS to explain how the CA implements the CP through registration, issuance, revocation, repository, key-management, security, and records practices. - Keep subscriber and relying-party documentation clear enough to show which CP applies and where the CPS, terms, or disclosure statement explain implementation details. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines the CP/CPS relationship for certification authorities: CP states what certificate policy requirements apply, while the CPS states how the TSP implements and maintains them. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the trust-service practice statement obligations for approval, availability, maintenance responsibilities, external supporting organizations, and change notice. ### [How should a CA keep CP and CPS evidence aligned?](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md#how-should-a-ca-keep-cp-and-cps-evidence-aligned) *Module: [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md)* Start with a traceability map from each applicable CP requirement to the CPS clause, operating record, or confidential procedure that implements it. This is especially important where certificates carry a CP identifier, because relying parties may use that identifier to judge certificate suitability and trustworthiness. - Record the CP identifier, certificate type, target subscribers or subjects, relying-party use, and certificate profile assumptions. - Link each CP commitment to the CPS clause that explains the CA practice and to the evidence record that proves the practice operated during the review period. - Separate public CPS wording from internal procedures such as access lists, location details, task assignments, HSM handling steps, and audit logs. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines the CP/CPS relationship for certification authorities: CP states what certificate policy requirements apply, while the CPS states how the TSP implements and maintains them. - [IETF RFC 3647 certificate policy and CPS framework](https://www.rfc-editor.org/rfc/rfc3647?ref=sorena.io) - Referenced by ETSI EN 319 411-1 for certificate policy identifiers and the CP/CPS framework used by certificate authorities. ### [When should the CP or CPS be updated?](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md#when-should-the-cp-or-cps-be-updated) *Module: [CP vs CPS under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/cp-vs-cps.md)* Update the CP when the policy itself changes: certificate applicability, policy OID, certificate profile requirements, assurance level, adopted ETSI policy basis, or the community rules that subscribers and relying parties rely on. Update the CPS when the CA changes how it implements the policy, such as identity validation processes, revocation handling, repository availability, RA arrangements, CA key controls, or supporting organizations. - Treat CP changes as policy-governance changes that may affect certificate claims, OIDs, subscriber terms, relying-party expectations, and audit scope. - Treat CPS changes as operational-governance changes that need approval, version control, publication handling, and evidence that the changed practice is actually in use. - Review CP/CPS alignment after new certificate profiles, RA delegation changes, revocation-process changes, CA key lifecycle changes, external support changes, or audit findings. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines the CP/CPS relationship for certification authorities: CP states what certificate policy requirements apply, while the CPS states how the TSP implements and maintains them. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the trust-service practice statement obligations for approval, availability, maintenance responsibilities, external supporting organizations, and change notice. ### [How should certificate authorities handle re-key under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/re-key.md#how-should-certificate-authorities-handle-re-key-under-etsi-en-319-411-1) *Module: [ETSI EN 319 411-1 certificate re-key](/artifacts/global/etsi-en-319-411-1/faq/re-key.md)* Treat re-key as a certificate lifecycle event that starts with a new subject public key. ETSI EN 319 411-1 clause 6.3.7 says the general certificate application and application-processing requirements in clauses 6.3.1 and 6.3.2 still apply, so the request must remain linked to registration, authorization, identity or attribute evidence, and the public key being certified. - Confirm the event is re-key, not renewal: the subject public key changes. - Apply the certificate application and processing controls from clauses 6.3.1 and 6.3.2 to the re-key request. - Verify and record changed certified names or attributes before including them in the replacement certificate. - Check the existing certificate when it is used to authenticate the request. - Communicate and obtain agreement to changed terms and conditions before completing the re-key. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines certificate re-key as issuance with a new subject public key and lists the clause 6.3.7 controls for attributes, expiry changes, previous-certificate authentication, and changed terms. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Provides the general trust service provider policy framework referenced by ETSI EN 319 411-1 for governance, practice statements, security, and auditability. ### [What evidence should support certificate re-key?](/artifacts/global/etsi-en-319-411-1/faq/re-key.md#what-evidence-should-support-certificate-re-key) *Module: [ETSI EN 319 411-1 certificate re-key](/artifacts/global/etsi-en-319-411-1/faq/re-key.md)* The evidence should prove why the re-key was allowed and how the new certificate was bound to the right subject. At minimum, keep the re-key request, request authentication result, registration or attribute evidence reused or refreshed, subscriber authorization where the subscriber and subject differ, and the CP/CPS rule that permits any expiry-date or attribute change. - Request record showing the subject, subscriber, requested public key, certificate profile, and reason for re-key. - Proof of possession or control for a non-CA-generated subject private key where clause 6.3.1 requires it. - Validation record for any changed certified name, organization, device, system, or other subject attribute. - Evidence that changed TSP terms and conditions were communicated and agreed to when applicable. - Audit logs for registration, certificate generation, certificate dissemination, and any related revocation decision. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the evidence list through clause 6.3.7 re-key requirements, clause 6.3.1 application requirements, clause 6.4.5 logging requirements, and clause 6.4.6 archival retention. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the need for TSP-wide governance and audit controls behind the ETSI EN 319 411-1 certificate lifecycle evidence. ### [When should re-key trigger revocation, notification, or CA key-change work?](/artifacts/global/etsi-en-319-411-1/faq/re-key.md#when-should-re-key-trigger-revocation-notification-or-ca-key-change-work) *Module: [ETSI EN 319 411-1 certificate re-key](/artifacts/global/etsi-en-319-411-1/faq/re-key.md)* A subject-certificate re-key can happen before expiry, after expiry, or after revocation. When the re-key is driven by compromise or a security breach, handle the revocation path separately from the replacement-certificate path: revocation requests and reports must be authenticated, processed on receipt, and reflected in status information within the maximum delay required by the CPS and ETSI EN 319 411-1. - If the old certificate was revoked for key compromise, keep the revocation request, authentication, decision, status-publication evidence, and subscriber or subject notification record. - If cryptography or associated parameters become insufficient for remaining use, inform subscribers and relying parties with whom the TSP has relationships and make the information available to other relying parties. - For CA key changeover, keep the documented ceremony procedure, participating roles, responsibilities, collected evidence, and ceremony report. - For subject keys generated by the CA, preserve evidence that delivery protected secrecy and integrity and that copies were deleted after delivery except where escrow or recovery rules apply. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the distinction between certificate re-key, revocation and suspension handling, algorithm-compromise notification, subject-key delivery, and CA key changeover ceremony requirements. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the broader TSP continuity, security, and operational-control context for revocation, compromise response, and CA key-change governance. ### [What should a CA document before enabling suspension?](/artifacts/global/etsi-en-319-411-1/faq/suspension.md#what-should-a-ca-document-before-enabling-suspension) *Module: [ETSI EN 319 411-1 Certificate Suspension](/artifacts/global/etsi-en-319-411-1/faq/suspension.md)* Treat suspension as part of the same controlled certificate-status process as revocation, while keeping the two outcomes distinct. A definitive revocation cannot be reinstated under EN 319 411-1; suspension is therefore useful only where the applicable certificate policy, CPS, customer terms, and status systems can represent a temporary invalid state without confusing relying parties. - Define the suspension model in the CPS: supported certificate policies, accepted requesters, permitted reasons, confirmation method, status-service method, and how suspension differs from final revocation. - Validate authorization before changing status, using the same discipline expected for revocation requests and reports. - Make the suspension status visible through the CA's revocation-status service, such as CRL or OCSP, within the documented delay and no later than the ETSI 24-hour maximum after request receipt. - Inform the subject and, where applicable, the subscriber of a suspended certificate when this is possible. - Do not describe a suspended certificate as valid during the suspension period; relying-party notices should direct users to current certificate-status information. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the suspension handling answer through clause 6.2.4 disclosure and timing requirements, clause 6.3.9 revocation and suspension requirements, and clause 6.3.10 certificate status service requirements. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the general TSP management-system context for controlled procedures, evidence, security management, and continuity behind certificate-status operations. ### [What evidence should support a certificate suspension decision?](/artifacts/global/etsi-en-319-411-1/faq/suspension.md#what-evidence-should-support-a-certificate-suspension-decision) *Module: [ETSI EN 319 411-1 Certificate Suspension](/artifacts/global/etsi-en-319-411-1/faq/suspension.md)* The evidence should show both the business decision and the status-system result. A reviewer should be able to see who requested suspension, how the CA confirmed the request, when the request arrived, what certificate and policy were affected, when the status changed, which CRL or OCSP channel carried the new status, and whether the subject or subscriber was notified. - Request record: requester identity, certificate serial number, certificate policy, reason, request time, intake channel, and authority to request suspension. - Validation record: checks performed, decision owner or trusted role, confirmation result, exception path if confirmation was delayed, and final decision. - Status evidence: CRL entry or OCSP response evidence, publication time, next update or response timing data, and proof that all supported status methods carried consistent information over time. - Notice evidence: subject or subscriber notice, delivery attempt, failure reason if notice was not possible, and customer-service or repository update where applicable. - Case evidence: status-change ticket, approval, publication proof, rollback or final-revocation outcome, and the CP/CPS clause that authorized the temporary state. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the evidence list for request handling, 24-hour status availability, subject or subscriber notice, status-service availability, CRL or OCSP publication, and consistency across supported status methods. ### [What should CAs check before offering suspension?](/artifacts/global/etsi-en-319-411-1/faq/suspension.md#what-should-cas-check-before-offering-suspension) *Module: [ETSI EN 319 411-1 Certificate Suspension](/artifacts/global/etsi-en-319-411-1/faq/suspension.md)* A CA should offer suspension only when the surrounding policy, repository, and status-service design can make the temporary state unambiguous. The risk is not just operational delay; it is that relying parties, subscribers, auditors, or customer contracts may treat a suspended certificate differently from the CA's status infrastructure. - Policy fit: confirm whether the relevant certificate policy permits suspension and whether any separate scheme, customer, browser-program, or national rule changes the answer. - Status fit: verify that CRL and OCSP behavior can expose the suspended state reliably and consistently wherever the CA offers both methods. - Timing fit: test whether intake, validation, approval, publication, and monitoring can meet the 24-hour status availability rule. - Exit fit: define when a suspended certificate returns to active status, moves to final revocation, or expires, and keep this separate from the EN 319 411-1 rule that final revocation is not reinstated. - Assessment fit: keep suspension samples in the audit file with the CP/CPS clause, requirement reference, requester evidence, publication evidence, and notification evidence. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports checking policy disclosure, status-service availability, CRL and OCSP consistency, certificate-status publication timing, subject or subscriber notification, and the distinction between suspension and definitive revocation. - [Regulation (EU) No 910/2014 (eIDAS)](https://eur-lex.europa.eu/eli/reg/2014/910/oj/eng?ref=sorena.io) - Supports the qualified-certificate context in which EU Member States may set national rules for temporary suspension and require the suspension period and status to be visible when those national rules apply. ### [How should certificate authorities handle certification audit evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md#how-should-certificate-authorities-handle-certification-audit-evidence-under-etsi-en-319-411-1) *Module: [ETSI EN 319 411-1 Certification Audit Evidence](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md)* Start with the audit boundary. The evidence file should identify the TSP or CA service being assessed, the applicable certificate policy, the CPS version, the certificate profiles and policy OIDs in use, the assessment period, and whether registration, certificate generation, dissemination, revocation management, revocation status, and subject-device provisioning are in scope. - Keep a scope sheet naming the CA hierarchy, certificate policies, certificate profiles, repository locations, revocation-status methods, RAs, outsourced components, and excluded services. - Trace each evidence request to the CP/CPS clause, EN 319 411-1 requirement ID, assessed period, record owner, evidence location, and sampling result. - Separate public CP/CPS and terms from confidential procedure evidence; EN 319 411-1 allows sensitive operational detail to remain outside the published CPS. - Record open findings with the affected requirement, evidence gap, corrective-action owner, and retest evidence rather than closing them with a certification label alone. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports using the CP, CPS, service components, requirement identifiers, and Annex B checklist as the structure for audit evidence. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports retaining accessible, confidential, integrity-protected operational records for evidence and service continuity. ### [What evidence should support certification audit evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md#what-evidence-should-support-certification-audit-evidence-under-etsi-en-319-411-1) *Module: [ETSI EN 319 411-1 Certification Audit Evidence](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md)* The core evidence should prove operation of the certificate service, not just document intent. For registration, keep application and identity-validation records, subscriber-agreement evidence, the accepting entity, validation method, RA handoff, and the location of supporting documents. For certificate lifecycle events, keep certificate requests, accuracy and authorization checks, issuance links to registration, renewal, re-key, modification, and dissemination evidence. - Registration evidence: certificate application, identity and attribute validation, proof of possession or control, subscriber authorization, subscriber agreement, and RA transfer records. - Certificate lifecycle evidence: request source, completeness checks, issuance record, certificate profile and CP identifier, renewal/re-key/modification checks, and dissemination evidence. - Revocation evidence: authenticated request or report, authorization check, status-change timing, exception justification, CRL or OCSP publication, and relying-party status availability. - Operations evidence: security-event logs, registration logs, certificate lifecycle logs, CA key lifecycle logs, archive access controls, and retention proof. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the listed evidence categories for registration, certificate application processing, certificate issuance, revocation, status services, audit logging, and CA key lifecycle records. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports keeping general TSP operational evidence for access control, backup, continuity, incident handling, termination planning, and supplier arrangements where they affect the assessed service. ### [How should teams package the evidence for assessment?](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md#how-should-teams-package-the-evidence-for-assessment) *Module: [ETSI EN 319 411-1 Certification Audit Evidence](/artifacts/global/etsi-en-319-411-1/faq/certification-audit-evidence.md)* Package the file so the assessor can sample without reconstructing the service from scratch. Use one index for scope and documents, one matrix for EN 319 411-1 requirement IDs, and separate folders for registration, certificate lifecycle, revocation/status, CA key management, audit logs, records archival, supplier or RA evidence, and corrective actions. - Index public documents separately from confidential procedures: CP, CPS, terms and conditions, PKI disclosure statement, repository URLs, and certificate policy identifiers. - For each sampled requirement, keep the request, artifact, owner, time period, system or repository location, and assessor conclusion in the same evidence row. - Flag reused evidence from previous certifications or third-party evaluations with scope, date, scheme, test report, and assessor verification status. - Keep remediation evidence separate from original operating evidence so the audit trail shows both the finding and the corrective action. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports packaging evidence by CP/CPS, service component, retained records, assessment checklist, and seven-year retention after certificate validity ends. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports retaining general trust-service records and evidence needed to show legal, trustworthy, secure, continuous, and supplier-controlled operation. ### [Revocation evidence workflow for CAs](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md#revocation-evidence-workflow-for-cas) *Module: [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md)* Treat revocation evidence as operational proof that the CA followed the CPS procedures required by EN 319 411-1. The CPS needs to state who may submit revocation requests or event reports, how requests are submitted, what confirmation is required, when certificates may be revoked or suspended, how status is distributed, and the maximum delays before relying parties can see the changed status. - Keep the CPS revocation procedure, submission channels, authorized requester list, confirmation rules, and allowed revocation or suspension reasons together. - Record the received request or event report, intake timestamp, authentication check, authorization basis, decision, reason, approver or trusted role, and any subscriber or subject notification attempt. - If confirmation cannot be completed within 24 hours, retain the exception procedure used, the actions taken, and the justification recorded for the case. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.2.4 and 6.3.9 ground the CPS revocation procedure, authorized request checks, 24-hour status availability rule, and certificate revocation duties. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports retaining accessible, confidential, integrity-protected operational records for evidence and service continuity. ### [What records should support revocation handling?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md#what-records-should-support-revocation-handling) *Module: [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md)* The evidence set should prove both the case decision and the publication of status information. EN 319 411-1 requires the maximum delay from receipt of a revocation or suspension request to actual status availability for relying parties to be at most 24 hours, and it applies that same maximum where both CRL and online status services are supported. - Preserve CRL publication logs, CRL files or hashes, nextUpdate values, signing key or delegated-signer evidence, and any last-CRL handling for the certificate scope. - Preserve OCSP responder logs, status-response samples, non-issued certificate handling evidence, and consistency records when CRL and OCSP timing differs. - Preserve UTC clock-synchronization evidence for revocation services and audit logs so request, decision, publication, and notification times can be compared. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clauses 6.3.9 and 6.3.10 ground CRL publication cadence, CRL signing, certificate status availability, OCSP or CRL support, and consistency across status methods. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports protected archives, UTC time records, and retention of records needed to evidence correct service operation. ### [What checklist should teams use before closing a revocation evidence file?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md#what-checklist-should-teams-use-before-closing-a-revocation-evidence-file) *Module: [How should certificate authorities handle revocation evidence under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/revocation-evidence.md)* Before closing a revocation evidence file, verify that the file proves the certificate-specific decision, the status-service outcome, and the archive controls. The test is whether an auditor can reconstruct what was requested, who was authorized, what changed, when relying parties could see it, and where the protected records are retained. - Match the certificate, policy OID or profile, subscriber or subject record, revocation reason, request source, and authorization evidence. - Confirm that a definitive revocation was not later reinstated, and document any suspension path separately from permanent revocation. - Confirm that status was made available through the supported method, or methods, within the CPS and EN 319 411-1 timing constraints. - Archive the record with confidentiality and integrity protection, retention aligned to disclosed terms and conditions, and enough metadata to support legal evidence or continuity needs. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clause 6.3.9 supports timely revocation from authorized and validated requests, mandatory revocation triggers, notice where possible, and the rule that definitively revoked certificates are not reinstated. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 7.10 supports confidentiality, integrity, archive completeness, availability for legal evidence, and retention tied to disclosed business practices. ### [Can a certificate authority delegate RA work under ETSI EN 319 411-1?](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md#can-a-certificate-authority-delegate-ra-work-under-etsi-en-319-411-1) *Module: [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md)* Yes, but delegation does not turn registration into an unmanaged hand-off. ETSI EN 319 411-1 defines a Registration Authority as the entity responsible mainly for identifying and authenticating certificate subjects, and notes that an RA can assist with certificate applications, revocation, or both. - Define which RA tasks are delegated: identity proofing, certificate application intake, revocation request handling, or registration-data submission. - Keep the TSP accountable for the certificate policy and CPS controls even when the registration work is performed by another party. - Do not accept delegated registration evidence unless it supports the subject, subscriber, authorization, and certificate profile requirements that apply to the certificate being issued. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Defines Registration Authority responsibilities and supports the answer that delegated identity evidence must still satisfy clause 6.2.2 validation requirements. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports the point that subcontracting or outsourcing does not remove the TSP's overall responsibility for policy conformance. ### [What controls should cover an external RA?](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md#what-controls-should-cover-an-external-ra) *Module: [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md)* External registration authorities should be treated as controlled trust-service participants, not just intake vendors. ETSI EN 319 411-1 requires registration data from external registration service providers to be exchanged securely and only with recognized providers whose identity is authenticated. - Maintain a current list of recognized external registration service providers and the authentication method used for each provider. - Document the contract or agreement terms that bind the RA to identity proofing, registration-data protection, incident reporting, personnel, and termination obligations. - Require registration and revocation officers, and other trusted roles involved in RA work, to be appointed, trained, screened where applicable, and separated from prohibited self-validation scenarios. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the secure-registration-data exchange requirement for external registration service providers and the trusted-role expectations for registration work. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports documented third-party agreements, supplier obligations, subcontractor competence, and TSP responsibility for outsourced service components. ### [What evidence should auditors expect for RA delegation?](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md#what-evidence-should-auditors-expect-for-ra-delegation) *Module: [RA delegation under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/ra-delegation.md)* The audit file should make the delegated registration chain reconstructable. ETSI EN 319 411-1 requires registration information to be logged and recorded, including document types, unique identification data or references where applicable, storage locations, subscriber-agreement choices, the identity of the entity accepting the application, validation method, and the receiving TSP or submitting RA when applicable. - Keep the RA delegation register, provider agreement, provider authentication evidence, CP/CPS mapping, and list of delegated registration tasks together. - Retain sample registration records that show the identity evidence or attestation source, the validation method, the application-acceptance entity, and any submitting RA. - Document how registration records, revocation-related records, and event log archives remain accessible if an RA relationship ends or the CA/RA service terminates. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Supports the specific RA-delegation audit evidence: registration logging, submitting RA identification, records archival, and CA/RA termination handling. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Supports retaining supplier-relationship evidence because the TSP remains responsible for conformance when third parties provide parts of the service. ### [What does ETSI EN 319 411-1 require before a subscriber agreement?](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md#what-does-etsi-en-319-411-1-require-before-a-subscriber-agreement) *Module: [Subscriber agreements under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md)* The CA or TSP should start with the terms and conditions that explain certificate use, acceptance, obligations, and limitations. ETSI EN 319 411-1 clause 6.3.4 requires the subscriber to be informed of those terms before the contractual relationship is formed. - Identify the certificate policy, CPS, terms and conditions, and any PKI disclosure statement that govern the subscriber relationship. - Present the applicable terms before the subscriber enters the contractual relationship or accepts the certificate. - Use a durable communication method that preserves the terms with integrity over time and is readable by the subscriber. - Define what constitutes certificate acceptance in the terms and conditions, rather than leaving acceptance implied by operational workflow. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Clause 6.3.4 supports the pre-contract notice, durable communication, certificate-acceptance, and recorded-agreement requirements summarized here. - [ETSI EN 319 401 V3.1.1 general policy requirements for TSPs](https://www.etsi.org/deliver/etsi_en/319400_319499/319401/03.01.01_60/en_319401v030101p.pdf?ref=sorena.io) - Clause 6.2 supports the general TSP requirement to inform subscribers and relying parties of precise terms before a contractual relationship. ### [How should the agreement handle subscribers and subjects?](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md#how-should-the-agreement-handle-subscribers-and-subjects) *Module: [Subscriber agreements under ETSI EN 319 411-1](/artifacts/global/etsi-en-319-411-1/faq/subscriber-agreements.md)* ETSI EN 319 411-1 distinguishes the subscriber from the certificate subject. If the subscriber and subject are separate entities and the subject is a natural or legal person, the agreement is expected to be in two parts: one ratified by the subscriber and one ratified by the subject. - Use a two-part agreement when the subscriber and subject are separate and the subject is a natural or legal person. - Use a traceable action such as signing or checking an acceptance box for each required ratification. - When the subscriber and subject are the same entity, or the subject is a device, include the subscriber and subject items in one or two agreement parts. - Allow staged acceptance only where the record still shows each accepted element, such as later confirmation that certificate information is correct. Sources for this answer: - [ETSI EN 319 411-1 V1.5.1 certificate policy and security requirements](https://www.etsi.org/deliver/etsi_en/319400_319499/31941101/01.05.01_60/en_31941101v010501p.pdf?ref=sorena.io) - Requirements REG-6.3.4-09 through REG-6.3.4-13 support the split-agreement approach for separate subscribers and subjects. ## FAQ Pagination - Canonical index (page 1): [/artifacts/global/etsi-en-319-411-1/faq/items](/artifacts/global/etsi-en-319-411-1/faq/items.md) - Page 1 rule: `/page/1` is intentionally not generated; use the canonical index markdown URL. - Current page: 1 of 2 Pages: [1](/artifacts/global/etsi-en-319-411-1/faq/items.md) | [2](/artifacts/global/etsi-en-319-411-1/faq/items/page/2.md) [Next page](/artifacts/global/etsi-en-319-411-1/faq/items/page/2.md) *Recommended next step* *Placement: after certificate-service guidance* ## Operationalize ETSI EN 319 411-1 certificate questions Use this FAQ as the starting point for CP/CPS review, certificate lifecycle evidence, subscriber disclosures, and audit-ready records. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert certificate policy questions into accountable controls, evidence requests, and audit review tasks. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Resolve CP, CPS, CA, RA, revocation, and status-service questions against cited ETSI source material. - [Talk through ETSI EN 319 411-1 implementation](/contact.md): Review certificate-service scope, evidence gaps, and the next CP/CPS actions with Sorena. --- [Privacy Policy](https://www.sorena.io/privacy) | [Terms of Use](https://www.sorena.io/terms-of-use) | [DMCA](https://www.sorena.io/dmca) | [About Us](https://www.sorena.io/about-us) (c) 2026 Sorena AB (559573-7338). All rights reserved. Source: https://www.sorena.io/artifacts/global/etsi-en-319-411-1/faq/items