FAQ item index

Search every question across sub-FAQs

Find the exact question, open the source answer card, and copy a direct link to the anchored sub-FAQ response.

Indexed coverage
24of24items
Across 8 modules • Updated Jul 25, 2026
Author
Sorena AI
Published
May 9, 2026
Updated
Jul 25, 2026
RA delegation under ETSI EN 319 411-1

Can a certificate authority delegate RA work under ETSI EN 319 411-1?

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.

For initial identity validation, the TSP must ensure that the subscriber and subject are verified, that direct evidence or an attestation from an appropriate and authorized source is collected and validated, and that certificate requests are accurate, authorized, and complete. A subcontracted person may supply identity evidence only when the identity check follows clause 6.2.2. The registration officer who verifies identity cannot be the natural person receiving the certificate.

  • 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.
  • Keep certificate issuance separate from registration approval: the application must come from a trusted and authorized source, and the issuing procedure must remain securely and unambiguously linked to the associated registration.
Citations
RA delegation under ETSI EN 319 411-1

What controls should cover an external RA?

External registration authorities are controlled trust-service participants. 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.

The same clause points external RAs back to general TSP security requirements, including human resources, operational security, networks, and privacy. ETSI EN 319 401 adds that third-party arrangements need documented agreements and clear obligations for the relevant information security requirements.

  • 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 each registration officer, each revocation officer, and other trusted roles involved in RA work to be appointed, trained, screened where applicable, and separated from prohibited self-validation scenarios.
  • Authenticate each recognized external registration service provider and protect registration data during exchange; a contract alone does not satisfy those operational controls.
Citations
RA delegation under ETSI EN 319 411-1

What evidence should auditors expect for RA delegation?

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.

RA delegation evidence should also cover retention and exit handling. EN 319 411-1 requires specified records to be retained for at least seven years after any certificate based on those records ceases to be valid, and its RA termination clause calls out registration information, revocation status information, and event log archives.

  • 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.
Citations
Subscriber agreements under ETSI EN 319 411-1

What does ETSI EN 319 411-1 require before a subscriber agreement?

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.

The agreement process also needs to be usable as evidence later. The terms must be communicated through a durable means, in human-readable form, before the agreement. Electronic transmission is allowed, but the record must still show what version was presented and how acceptance occurred.

  • 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.
Citations
Subscriber agreements under ETSI EN 319 411-1

How should the agreement handle subscribers and subjects?

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 shall be in two parts: one ratified by the subscriber and one ratified by the subject. The two parts may be ratified together when the subscriber is the subject legal person's official representative, or when the same official representative acts for both subscriber and subject.

That distinction matters for enterprise and delegated-certificate scenarios. The subscriber part should capture subscriber obligations, any secure-device requirement, consent to registration and revocation records, publication choices, and confirmation that certificate information is correct. The subject part should capture the subject obligations, secure-device acceptance where relevant, and consent to the records kept by the TSP.

  • 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; an agreement may be electronic.
  • 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.
Citations
Subscriber agreements under ETSI EN 319 411-1

What evidence should a CA retain for subscriber agreements?

The evidence should prove the exact agreement, the terms accepted, the person or entity accepting, and the specific choices made during registration. ETSI EN 319 411-1 requires the agreement with the subscriber to be recorded, and, where the subscriber and subject are separate, the subject agreement to be recorded as well.

Records should also connect the agreement to the registration file. ETSI EN 319 411-1 lists the storage location of applications and identification documents, including the subscriber agreement, plus specific choices in the agreement such as consent to certificate publication.

  • Retain the signed or electronically accepted subscriber agreement and the version of terms and conditions presented at acceptance.
  • Keep evidence of the wilful act used for acceptance, such as signature data, acceptance timestamp, account identity, or equivalent trace record.
  • Record publication consent, secure-cryptographic-device acceptance, certificate-information confirmation, and any other agreement choices that affect issuance or relying-party information.
  • Retain the agreement records for the period indicated to the subscriber as part of the terms and conditions, and for at least the clause 6.4.6 minimum where that clause applies.
Citations
Subscriber identity validation under ETSI EN 319 411-1

What must be validated before a certificate is issued?

Clause 6.2.2 starts with a direct rule: the TSP verifies the identity of the subscriber and the certificate subject. It then requires the TSP to collect and validate either direct evidence or an attestation from an appropriate and authorized source for the subject's identity and, where applicable, subject attributes.

The validation decision must also cover the certificate request itself. ETSI EN 319 411-1 requires the TSP to check that certificate requests are accurate, authorized, and complete against the collected evidence or attestation. Identity verification happens at registration, but issuance may occur later. At issuance, the attributes must still be correct, the original proofing process must remain acceptable under the CPS, and the CP/CPS must define how long and how often identity validation may be reused without a new validation.

  • Identify whether the subject is a natural person, a natural person linked to a legal person, a legal person or organizational entity, or a device or system operated by or for a natural or legal person.
  • Collect direct evidence or an authorized-source attestation for the subject identity and any certificate attributes that will be included or relied on.
  • Check request accuracy, authorization, and completeness before certificate generation uses the registration result.
  • Record the age of reused evidence and the CP/CPS reuse rule; refresh identity validation when the allowed time, frequency, security, or change conditions are not met.
Citations
Subscriber identity validation under ETSI EN 319 411-1

How does the answer change by subject type?

For natural-person subjects under NCP requirements, ETSI EN 319 411-1 requires identity evidence to be checked against the person directly by physical presence, unless a duly mandated subscriber represents the subject, or indirectly using means that provide equivalent assurance. The evidence set includes the person's full name and either date and place of birth, a recognized identity-document reference, or other distinguishing attributes.

For a natural person associated with a legal person, the file needs both personal and organization evidence: the subject's name and distinguishing attributes, the legal person's full name and legal status, relevant registration information, the affiliation, and approval by both the legal person and natural person that the subject attributes identify the organization. For legal-person and device/system subjects, the evidence shifts to the organization's name, registration or distinguishing attributes, relevant organizational associations, and a device identifier such as an Internet domain name where applicable.

  • Do not use a single identity checklist for every certificate profile; map the requested certificate to the subject type and policy conditions that apply.
  • When the subscriber and subject are different entities, keep evidence that the subscriber is authorized to act for the subject and, if the subscriber is not a natural person, that a natural person is authorized to represent the subscriber.
  • For DVCP, OVCP, IVCP, and EVCP web certificates, apply the policy-specific CA/Browser Forum requirements incorporated by EN 319 411-1. Domain-name and IP-address verification follows the applicable Baseline Requirements methods, not a generic identity checklist; confirm the BRG or EV Guidelines version effective for the certificate population.
Citations
Regulation (EU) No 910/2014 (eIDAS)

Provides the EU trust-services legal context for certificates and trust service providers where ETSI EN 319 411-1 is used for eIDAS-oriented certification services.

Subscriber identity validation under ETSI EN 319 411-1

What evidence should a CA keep for subscriber identity validation?

The evidence record should be specific enough to re-perform the validation decision without collecting unnecessary long-term personal data. ETSI EN 319 411-1 requires the TSP to record all information necessary to verify the subject identity and attributes, including any reference number on verification documentation and any limits on its validity. The standard notes that long-term retention may be limited to a reference to the document used, depending on the records obligations and applicable law.

The record should also prove process integrity. Keep the request, evidence or attestation source, validation method, certificate profile, subscriber contact attributes, authorization evidence, approval history, and the registration officer or RA record. The registration officer who verifies identity must not be the natural person receiving the certificate as subject.

  • Record the subject type, subscriber-subject relationship, certificate profile, evidence source, validation method, document reference, validity limitations, and request approval.
  • Keep subscriber contact attributes such as a physical address or other contact attributes, plus evidence showing how the registration process meets applicable data-protection legislation.
  • Track registration officer independence, RA involvement, and any delegated evidence source so the CA can show who validated what and under which CPS process.
Citations
Page 2 of 2