--- title: "ETSI EN 319 411-1 Revocation Evidence Workflow" canonical_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow" source_url: "https://www.sorena.io/artifacts/global/etsi-en-319-411-1/revocation-evidence-workflow" author: "Sorena AI" description: "Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention." published_at: "2026-05-09" updated_at: "2026-05-09" keywords: - "ETSI EN 319 411-1" - "certificate revocation" - "OCSP" - "CRL" - "CPS" - "revocation evidence" - "CPS evidence" --- **[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 Revocation Evidence Workflow Build a revocation evidence workflow for ETSI EN 319 411-1 covering CPS procedures, request authentication, 24-hour status updates, CRL/OCSP publication, logs, and retention. *Artifact Guide* *GLOBAL* *ETSI EN 319 411-1* ## ETSI EN 319 411-1 Revocation Evidence Workflow A workflow for proving how a trust service provider receives, authenticates, decides, publishes, and records certificate revocation events. Grounded in ETSI EN 319 411-1 V1.5.1 clauses for CPS revocation procedures, certificate status services, CRL/OCSP publication, audit logging, and records archival. Use this page to turn ETSI EN 319 411-1 revocation duties into an evidence trail. The workflow focuses on what the CPS must define, how revocation requests are authenticated and processed, how status is made available to relying parties, and what records auditors should be able to trace later. ## Start with the CPS revocation procedure The first evidence item is the CPS section for revocation of end-user and CA certificates. It should identify who can submit a revocation request or report a revocation event, how the request is submitted, when confirmation is required, the reasons a certificate can be suspended or revoked, the status-distribution mechanism, and the maximum publication delays. Treat that CPS section as the control map for operations. Each intake channel, authorization rule, confirmation step, suspension reason, revocation reason, CRL location, OCSP endpoint, and relying-party disclosure should be traceable to a clause, an owner, and a record. - Link each revocation intake channel to the CPS language that authorizes it. - Record who is permitted to submit a revocation request or event report, including subscribers, subjects, authorized representatives, and CA operational roles where applicable. - Keep the list of suspension and revocation reasons aligned with the certificate policy and CPS instead of relying on free-form ticket categories. - Document the maximum time from request receipt or confirmation to status information being available to relying parties. 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.2.4 defines the CPS content expected for revocation request procedures, submission routes, confirmation, reasons, distribution mechanisms, and delays. - [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) - General TSP policy requirements support the management-system and practice-statement context used by EN 319 411-1. ## Authenticate and time-bound revocation requests The operational workflow should begin when a request or report is received, not when a weekly review queue is opened. EN 319 411-1 says revocation requests and event reports are processed on receipt and authenticated as coming from an authorized source. The workflow also needs time evidence. The standard requires the time used for revocation services to be synchronized with UTC at least once every 24 hours, and the maximum delay from receiving a revocation or suspension request to making the status change available to relying parties is at most 24 hours. If confirmation cannot be completed within 24 hours, the exception procedure and recorded justification become part of the evidence pack. - Capture request receipt time, submitter identity, authorization basis, certificate identifier, reason code, and confirmation requirement. - Store UTC synchronization evidence for systems that receive requests, approve changes, sign CRLs, or operate OCSP responders. - Use a timer from request receipt, or from the scheduled effective date for future-dated requests, to the point where relying parties can see updated status. - When confirmation cannot be completed within 24 hours, attach the CPS exception procedure, actions taken, and justification to the revocation 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 REV-6.2.4-03A through REV-6.2.4-09 support the 24-hour status-update limit, exception records, UTC synchronization, processing on receipt, and authentication checks. ## Publish revocation status through CRL, OCSP, or both The evidence trail is incomplete until relying parties can check certificate status. EN 319 411-1 requires certificate status services, requires revocation status information to be available 24 hours per day and 7 days per week, and requires integrity and authenticity protection for the status information. If the service uses CRLs, the workflow should prove the CRL publication schedule, nextUpdate handling, signing authority, and any last-CRL condition. If the service uses OCSP, it should prove responder profile handling and that non-issued certificates are not returned as good. If both CRL and OCSP are supported, updates must be available through both methods and the CPS must explain possible delays and how to interpret differences. - For CRL evidence, keep issued CRLs or publication logs, next scheduled issue time, signer identity, and proof of at least daily publication until a last CRL is published. - For OCSP evidence, keep responder configuration, signing certificate controls, sample responses, monitoring results, and handling rules for certificates that were not issued. - For combined CRL and OCSP services, compare status values and update timestamps so differences are explained by documented propagation delays. - Publish relying-party status information through public and internationally available mechanisms where EN 319 411-1 requires that availability. 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 the CRL publication, OCSP-or-CRL support, 24/7 availability, integrity, consistency, and public availability requirements. - [IETF RFC 5280 certificate and CRL profile](https://www.rfc-editor.org/rfc/rfc5280?ref=sorena.io) - EN 319 411-1 references RFC 5280 for CRL profile handling, including CRL fields used in publication evidence. - [IETF RFC 6960 Online Certificate Status Protocol](https://www.rfc-editor.org/rfc/rfc6960?ref=sorena.io) - EN 319 411-1 references RFC 6960 for OCSP profile handling and responder status behavior. ## Revocation evidence workflow table Use this table as the operating workflow for each revocation case or periodic audit sample: Step | Owner | Evidence | Acceptance test. 1 | CPS owner | CPS revocation procedure, certificate policy mapping, subscriber and relying-party disclosures | The CPS identifies submitters, submission methods, confirmation rules, revocation and suspension reasons, status mechanisms, and maximum delays. 2 | Revocation officer or authorized operations role | Request record, event report, submitter authentication, certificate serial number, reason, receipt timestamp | The request was processed on receipt and authenticated as coming from an authorized source. 3 | CA or revocation management service | Decision record, approval trail, confirmation result, exception justification if needed | The status-change decision is complete within the EN 319 411-1 timing limit or a documented CPS exception applies. 4 | Repository, CRL, or OCSP owner | CRL publication log, OCSP response evidence, endpoint monitoring, signer controls | Relying parties can obtain protected status information through the required method. 5 | Audit and records owner | Revocation log, resulting action, retained records, change review | Requests, reports, and resulting actions are logged and retained with the relevant certificate lifecycle evidence. - Apply the workflow per revocation case and again as a sampled control during internal audit or conformity assessment preparation. - Use the same certificate identifiers across the request ticket, CA system, CRL entry, OCSP response, and audit log. - Do not mark the case closed until publication evidence shows that relying parties can see the changed status. - Keep exceptions tied to CPS language, not informal operational judgment. 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) - The workflow table combines clause 6.2.4 request handling, clause 6.3.9 revocation and suspension, clause 6.3.10 status services, and clause 6.4.5 logging. *Recommended next step* *Placement: after practical guidance* ## Operationalize ETSI EN 319 411-1 revocation evidence Use this workflow to assign CPS updates, revocation request controls, CRL/OCSP publication checks, and evidence retention before an ETSI EN 319 411-1 assessment. - [Open Assessment Autopilot for ETSI EN 319 411-1](/solutions/assessment.md): Convert revocation request handling, status publication, and retention controls into assigned evidence tasks. - [Research ETSI EN 319 411-1 source questions](/solutions/research-copilot.md): Resolve CPS, CRL, OCSP, short-term certificate, and audit-log questions against the cited ETSI clauses. - [Talk through revocation evidence](/contact.md): Review the revocation workflow, evidence gaps, and next compliance actions with Sorena. ## Evidence pack for audit and retention The evidence pack should prove both the individual revocation outcome and the service control. Include the CPS version in force, the certificate profile and serial number, the request and authorization evidence, timing evidence, decision evidence, publication evidence, and the resulting audit log entry. EN 319 411-1 requires logging all requests and reports relating to revocation and the resulting action. It also requires retention of specified lifecycle records for at least seven years after any certificate based on those records ceases to be valid. The retention rule means the revocation workflow should not depend on short-lived ticket comments or monitoring dashboards that cannot be reproduced later. - Retain revocation request records, event reports, submitter authentication evidence, confirmation attempts, and exception justifications. - Retain status-publication evidence such as CRL files, CRL publication logs, OCSP response samples, endpoint monitoring, and consistency checks. - Retain audit logs showing the resulting action, including suspension, definitive revocation, reinstatement where suspension rules allow it, or no-action decisions with justification. - Record the practice-statement retention period and identify which records must be handed over or preserved under a CA or RA termination plan. 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.4.5 and 6.4.6 support revocation logging, practice-statement retention periods, archival records, and the seven-year retention baseline. ## Handle short-term and non-revocable certificate cases explicitly Short-term certificate handling needs its own evidence because EN 319 411-1 distinguishes short-term certificates that can be revoked from short-term certificates that cannot be revoked through a revocation management service. A generic revocation workflow can mislead relying parties if it implies all certificates in the service are revocable in the same way. For short-term certificates that cannot be revoked, the CPS should describe which certificates cannot be revoked, how problems with those certificates can be notified, how information on a notification can be requested, and how notified problems are recorded in the audit log. - Separate revocable and non-revocable short-term certificate profiles in the CPS and public relying-party material. - For revocable short-term certificates, apply the normal request handling, timing, status-service, and key compromise controls. - For non-revocable short-term certificates, keep evidence of the notification mechanism, information-request process, and audit log entries for notified problems. - Do not use CRL or OCSP monitoring evidence to imply revocation availability for a certificate profile that the CPS describes as non-revocable. 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 REV-6.3.9-15 through REV-6.3.9-19 ground the short-term certificate exceptions, CPS descriptions, notification mechanism, and audit log requirements. ## Primary sources - [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) - Primary ETSI source for CPS revocation procedures, request authentication, 24-hour publication timing, CRL/OCSP status services, revocation logs, and records archival. - Quote: "Policy and security requirements for Trust Service Providers issuing certificates" - [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) - General ETSI policy requirements that EN 319 411-1 relies on for trust service provider management and practice-statement context. - Quote: "General Policy Requirements for Trust Service Providers" - [IETF RFC 5280 certificate and CRL profile](https://www.rfc-editor.org/rfc/rfc5280?ref=sorena.io) - Referenced by EN 319 411-1 for X.509 certificate and CRL profile requirements used when proving CRL publication behavior. - Quote: "Certificate and Certificate Revocation List (CRL) Profile" - [IETF RFC 6960 Online Certificate Status Protocol](https://www.rfc-editor.org/rfc/rfc6960?ref=sorena.io) - Referenced by EN 319 411-1 for OCSP profile requirements used when proving online certificate status behavior. - Quote: "Online Certificate Status Protocol - OCSP" ## Related Topic Guides - [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. - [EN 319 411-1 vs EN 319 411-2 Certificate Policy](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-en-319-411-2.md): Compare ETSI EN 319 411-1 general certificate-service requirements with EN 319 411-2 EU qualified certificate requirements, including policy scope, CP/CPS evidence, and audit boundaries. - [ETSI EN 319 411-1 Audit File Evidence](/artifacts/global/etsi-en-319-411-1/audit-file-evidence.md): Build an ETSI EN 319 411-1 audit evidence file for CA logging, registration records, revocation records, CA key lifecycle evidence, and records archival. - [ETSI EN 319 411-1 CA Key Management](/artifacts/global/etsi-en-319-411-1/ca-key-management.md): CA key management guidance for ETSI EN 319 411-1: CPS commitments, key ceremonies, secure cryptographic devices, backup, recovery, and lifecycle evidence. - [ETSI EN 319 411-1 certificate lifecycle workflow](/artifacts/global/etsi-en-319-411-1/certificate-lifecycle-workflow.md): Workflow for EN 319 411-1 certificate application, issuance, acceptance, renewal, re-key, modification, revocation, suspension, status services, and evidence records. - [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. - [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. - [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. - [ETSI EN 319 411-1 Compliance Guide](/artifacts/global/etsi-en-319-411-1/compliance.md): Build an ETSI EN 319 411-1 compliance file for certificate policies, CPS commitments, certificate lifecycle controls, revocation services, CA keys, and audit evidence. - [ETSI EN 319 411-1 CP and CPS template](/artifacts/global/etsi-en-319-411-1/cp-and-cps-template.md): Build a certificate policy and Certification Practice Statement template for ETSI EN 319 411-1 certificate services, with fields for policy identifiers, subscribers, relying parties, revocation, publication, and evidence. - [ETSI EN 319 411-1 FAQ for Certificate Services](/artifacts/global/etsi-en-319-411-1/faq.md): 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. - [ETSI EN 319 411-1 Identity Validation](/artifacts/global/etsi-en-319-411-1/identity-validation.md): Identity validation requirements in ETSI EN 319 411-1 for subscribers, subjects, RAs, certificate requests, registration evidence, and issuance records. - [ETSI EN 319 411-1 Identity Validation Evidence Workflow](/artifacts/global/etsi-en-319-411-1/identity-validation-evidence-workflow.md): A workflow for building ETSI EN 319 411-1 identity validation evidence packs across subscriber, subject, certificate request, RA, logging, and retention controls. - [ETSI EN 319 411-1 RA Delegation Guide](/artifacts/global/etsi-en-319-411-1/ra-delegation.md): How to scope registration authority delegation under ETSI EN 319 411-1, including delegated RA tasks, external provider controls, registration records, and audit evidence. - [ETSI EN 319 411-1 RA Delegation Review Workflow](/artifacts/global/etsi-en-319-411-1/ra-delegation-review-workflow.md): Review delegated registration authority work under ETSI EN 319 411-1: retained CA responsibility, recognized registration service providers, secure data exchange, CPS coverage, and audit evidence. - [ETSI EN 319 411-1 requirements map for certificate services](/artifacts/global/etsi-en-319-411-1/requirements.md): Map ETSI EN 319 411-1 requirements for certificate policies, CP/CPS content, registration, revocation, certificate status, and CA key-management evidence. - [ETSI EN 319 411-1 Revocation, OCSP, and CRL Operations](/artifacts/global/etsi-en-319-411-1/revocation-ocsp-and-crl-operations.md): Operate ETSI EN 319 411-1 revocation status services with CPS procedures, authenticated requests, 24-hour CRL or OCSP publication controls, and audit evidence. - [ETSI EN 319 411-1 vs CA/B Forum Baseline Requirements](/artifacts/global/etsi-en-319-411-1/en-319-411-1-vs-ca-browser-forum-baseline-requirements.md): Compare how EN 319 411-1 incorporates CA/B Forum BRG concepts for DVCP, OVCP, IVCP, [WEB] requirements, CPS disclosure, domain validation, and conflict handling. - [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. - [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. - [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. - [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. --- [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/revocation-evidence-workflow