2043837 - eMudhra emSign PKI Services: www Subdomain Inclusion in Certificate SAN via ACME Issuance Workflow

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Naveen Kumar ML]

Preliminary Incident Report

Summary

• Incident description: During a review prompted by a customer inquiry regarding certificate issuance behavior, it was identified that the ACME issuance workflow automatically included the corresponding www subdomain in the Subject Alternative Name (SAN) extension when a request was submitted for the base domain. This behavior occurred as part of the certificate issuance process and was not separately specified within the certificate request. Following internal assessment, the behavior was determined to be inconsistent with applicable certificate issuance requirements governing requested domain names.
• Relevant policies: CA/Browser Forum Baseline Requirements — Section 4.2.1 (Performing Identification and Authentication Functions). Requirements relating to the inclusion of domain names in certificates and validation of all names contained within the certificate.
• Source of incident disclosure: The issue was brought to eMudhra’s attention following a customer inquiry regarding the presence of a www domain name in an issued certificate where only the corresponding base domain had been requested.

Comment 1

[Naveen Kumar ML]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A005678
• Incident description: During a review prompted by a customer inquiry, it was identified that the ACME issuance workflow automatically included the www subdomain in the Subject Alternative Name (SAN) extension when a certificate request was submitted for a base domain only. This behavior occurred without explicit subscriber authorization and was determined to be inconsistent with CA/Browser Forum Baseline Requirements governing the inclusion of domain names in certificates. It is noted that the option to include the www subdomain is a legitimate and configurable feature available via eMudhra's web portal and REST API channels, where the subscriber must explicitly opt in. The issue was specific to the ACME implementation, which applied this addition unconditionally without subscriber consent.
• Timeline summary:
  • Non-compliance start date: 02 May 2026
  • Non-compliance identified date: 30 May 2026
  • Non-compliance end date: 30 May 2026
• Relevant policies: CA/Browser Forum Baseline Requirements Section 4.2.1 (Performing Identification and Authentication Functions); BR requirements governing inclusion and validation of all domain names in issued certificates.
• Source of incident disclosure: Customer complaint. A subscriber identified that their issued certificate contained www.<domain> in the SAN despite not having requested or authorized that domain name.

Impact

• Total number of certificates: 239 subscriber certificates affected
• Total number of "remaining valid" certificates: 239 certificates were valid at time of identification. All 239 were revoked by 02 June 2026, 19:15 UTC.
• Affected certificate types: TLS/SSL DV and OV end-entity certificates issued via ACME protocol
• Incident heuristic: Certificates where the issued certificate SAN contained www.<domain> but the corresponding CSR SAN did not include www.<domain>, confirming the www entry was added by the CA without subscriber authorization. Determined by direct CSR-to-certificate SAN comparison for each affected certificate.
• Was issuance stopped in response to this incident, and why or why not?: Yes. The unconditional www auto-addition logic in the ACME pipeline was disabled on 30 May 2026, the same day the issue was identified. The www subdomain option remains available via eMudhra's web portal and REST API channels as an explicit subscriber opt-in, which is BR-compliant.
• Analysis: Affected certificates were identified by cross-referencing the SAN of each issued certificate against the original CSR submitted by the subscriber. Certificates where www.<domain> appeared in the issued SAN but not in the CSR were classified as misissuances. Certificates belonging to eMudhra's own domains were excluded from the subscriber impact count.
• Additional considerations: N/A

Timeline

Date / Time (UTC)	Event
02 May 2026 07:29	Earliest affected subscriber certificate issued via ACME pipeline.
29 May 2026 11:50	Latest affected subscriber certificate issued.
30 May 2026 00:30	Customer complaint triaged. Internal investigation initiated.
30 May 2026 07:00	Raised the internal incident to analyse further with the affected and certificates.
30 May 2026 11:15	ACME www auto-addition logic was corrected.
30 May 2026 15:20	Preliminary Incident Report filed on Bugzilla CA Public Forum.
30 May 2026 – 02 Jun 2026	Full inventory analysis. Affected certificates identified via CSR-to-SAN comparison.
02 June 2026 11:30	Revocation initiated based on the certificate replacement confirmation by customers.
02 June 2026 19:15	Revocation of all 239 valid affected certificates completed.
09 June 2026	Full Incident Report prepared and submitted.

Related Incidents

Bug	Date	Description
1712120	2021-05-20	Sectigo: Inadequate DCV. A single-domain www subdomain order using email DCV could result in issuance where domain control of the relevant name had not properly occurred. Related www-vs-apex validation-scope theme..

Root Cause Analysis

Contributing Factor #1: ACME Pipeline www Auto-Addition Logic

• Description: The ACME issuance pipeline contained logic that unconditionally appended www.<domain> to the SAN of any certificate request containing a bare domain, without verifying whether the subscriber had explicitly requested the www variant. This logic was introduced recently as part of a pipeline update and was not present in earlier versions of the ACME implementation. The www opt-in feature is legitimate and compliant in eMudhra's portal and REST API channels; it was ported to ACME without preserving the subscriber consent mechanism. The change was not caught during QA and the feature was released to production.
• Timeline: Active from at least 02 May 2026. Disabled 30 May 2026.
• Detection: Detected via customer complaint on 30 May 2026.
• Interaction with other factors: No other contributing factors identified. This was a self-contained pipeline configuration issue.
• Root Cause Analysis methodology used: 5 Whys: The ACME pipeline applied www unconditionally → the opt-in feature was recently ported from portal/REST API without preserving the consent requirement → the change missed QA gates → no CSR-vs-SAN validation gate existed in ACME → pre-issuance controls did not include SAN-vs-CSR alignment checks → this requirement was not incorporated during the ACME pipeline design phase.

Lessons Learned

• What went well: The issue was identified and the pipeline fix deployed within the same day as the customer complaint. All 239 valid affected certificates were revoked within 5 days, meeting BR Section 4.9.1.1.
• What didn't go well: The www opt-in feature was ported from portal/REST API to ACME without preserving the subscriber consent requirement. This was a recently introduced change that was not present in earlier versions of the ACME implementation. The change missed QA gates as pre-issuance compliance checks were not included in the test suite at the time. No pre-issuance CSR-vs-SAN validation gate existed in the ACME pipeline.
• Where we got lucky: A customer complaint surfaced the issue while the scope was still limited to 239 subscriber certificates. All CSR data was retained, enabling accurate scope determination.
• Additional: This incident reinforces that any automatic SAN augmentation logic, even where the underlying feature is legitimate, must preserve subscriber consent mechanisms across all issuance channels.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	2026-05-30	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	2026-06-02	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	2026-06-30	Ongoing
Audit all non-ACME channels for similar SAN augmentation	Prevent	CF #1	Audit confirms no unrequested SANs in any channel	2026-07-15	Ongoing
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	2026-08-31	Ongoing

Appendix

Certificate list is attached.

Comment 2

[Naveen Kumar ML]

Attachment: Certificate List.xlsx

Comment 3

[Naveen Kumar ML]

We are working on the action items, and we will provide the update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	2026-05-30	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	2026-06-02	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	2026-06-30	Ongoing
Audit all non-ACME channels for similar SAN augmentation	Prevent	CF #1	Audit confirms no unrequested SANs in any channel	2026-07-15	Ongoing
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	2026-08-31	Ongoing

Comment 4

[Ben Wilson]

While reviewing this report, I noticed that the RCA and Action Items focus primarily on comparing the SANs in the issued certificate with those in the CSR, but spend relatively little time discussing the domain validation aspect of the incident.

I also found myself wondering about the interaction between the current TLS BR provisions relating to Authorization Domain Names (ADNs) and the ACME validation methods in Section 3.2.2.4. (I realize this area has been somewhat difficult to follow, and I believe that is one of the motivations behind Ballot SC-101.)

In looking at the incident report, I noted the references to ACME, but I may have missed which exact ACME validation method(s) were used.

As I read the current TLS BRs, the ACME methods themselves do not explicitly refer to ADNs. Also, Section 3.2.2.4.19 (Agreed-Upon Change to Website - ACME) includes the following note:

"The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods."

With that in mind, could eMudhra clarify or restate, for the ACME validation method(s) used in this incident, what domain name(s) were actually validated and whether the automatically-added www identifier was separately validated before issuance? More generally, did the implementation rely on the assumption that validation of the base domain was sufficient for issuance of the corresponding www FQDN?

I'm not asking eMudhra to analyze or comment on the changes proposed in Ballot SC-101. Rather, I'm seeking clarification on how the implementation satisfied the then-applicable domain validation requirements for each identifier ultimately included in the certificate. That would also help clarify whether this incident was limited to a subscriber authorization issue (i.e., issuance of names not requested by the subscriber), or whether it also involved the FQDN-checking process. If the latter, it may be appropriate to update the RCA to address any contributing factors relating to the domain validation process and to expand the Action Items to include preventive and detective controls that address those factors.

Thanks.

Comment 5

[Naveen Kumar ML]

(In reply to Ben Wilson from comment #4)

While reviewing this report, I noticed that the RCA and Action Items focus primarily on comparing the SANs in the issued certificate with those in the CSR, but spend relatively little time discussing the domain validation aspect of the incident.

I also found myself wondering about the interaction between the current TLS BR provisions relating to Authorization Domain Names (ADNs) and the ACME validation methods in Section 3.2.2.4. (I realize this area has been somewhat difficult to follow, and I believe that is one of the motivations behind Ballot SC-101.)

In looking at the incident report, I noted the references to ACME, but I may have missed which exact ACME validation method(s) were used.

As I read the current TLS BRs, the ACME methods themselves do not explicitly refer to ADNs. Also, Section 3.2.2.4.19 (Agreed-Upon Change to Website - ACME) includes the following note:

"The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs separate validations for each of those other FQDNs using authorized methods."

With that in mind, could eMudhra clarify or restate, for the ACME validation method(s) used in this incident, what domain name(s) were actually validated and whether the automatically-added www identifier was separately validated before issuance? More generally, did the implementation rely on the assumption that validation of the base domain was sufficient for issuance of the corresponding www FQDN?

I'm not asking eMudhra to analyze or comment on the changes proposed in Ballot SC-101. Rather, I'm seeking clarification on how the implementation satisfied the then-applicable domain validation requirements for each identifier ultimately included in the certificate. That would also help clarify whether this incident was limited to a subscriber authorization issue (i.e., issuance of names not requested by the subscriber), or whether it also involved the FQDN-checking process. If the latter, it may be appropriate to update the RCA to address any contributing factors relating to the domain validation process and to expand the Action Items to include preventive and detective controls that address those factors.

Thanks.

Thank you for your review and the detailed question.
The domain validation method used for the affected certificates was DNS TXT record-based validation. We have reviewed the domain validation records for the affected certificates and can confirm that domain control was properly established for all domains prior to issuance.
The incident was limited to a subscriber authorization issue — the www subdomain was included in the issued certificate without the subscriber’s explicit request or consent, in violation of BR Section 4.2.1. The domain validation process itself was compliant with the applicable requirements.
It is worth noting that in our other issuance channels, subscribers have an explicit opt-in option to include the www variant; this opt-in mechanism was not present in the ACME implementation, which is what led to this incident.
We will update the incident report to explicitly reference the DCV method used.

Comment 6

[Naveen Kumar ML]

Full Incident Report

Summary

• CA Owner CCADB unique ID: A005678
• Incident description: During a review prompted by a customer inquiry, it was identified that the ACME issuance workflow automatically included the www subdomain in the Subject Alternative Name (SAN) extension when a certificate request was submitted for a base domain only. This behavior occurred without explicit subscriber authorization and was determined to be inconsistent with CA/Browser Forum Baseline Requirements governing the inclusion of domain names in certificates. It is noted that the option to include the www subdomain is a legitimate and configurable feature available via eMudhra's web portal and REST API channels, where the subscriber must explicitly opt in. The issue was specific to the ACME implementation, which applied this addition unconditionally without subscriber consent.
• Timeline summary:
  • Non-compliance start date: 02 May 2026
  • Non-compliance identified date: 30 May 2026
  • Non-compliance end date: 30 May 2026
• Relevant policies: CA/Browser Forum Baseline Requirements Section 4.2.1 (Performing Identification and Authentication Functions); BR requirements governing inclusion and validation of all domain names in issued certificates.
• Source of incident disclosure: Customer complaint. A subscriber identified that their issued certificate contained www.\<domain\> in the SAN despite not having requested or authorized that domain name.

Impact

• Total number of certificates: 239 subscriber certificates affected
• Total number of "remaining valid" certificates: 239 certificates were valid at time of identification. All 239 were revoked by 02 June 2026, 19:15 UTC.
• Affected certificate types: TLS/SSL DV and OV end-entity certificates issued via ACME protocol
• Incident heuristic: Certificates where the issued certificate SAN contained www.\<domain\> but the corresponding CSR SAN did not include www.\<domain\>, confirming the www entry was added by the CA without subscriber authorization. Determined by direct CSR-to-certificate SAN comparison for each affected certificate.
• Was issuance stopped in response to this incident, and why or why not?: Yes. The unconditional www auto-addition logic in the ACME pipeline was disabled on 30 May 2026, the same day the issue was identified. The www subdomain option remains available via eMudhra's web portal and REST API channels as an explicit subscriber opt-in, which is BR-compliant.
• Analysis: Affected certificates were identified by cross-referencing the SAN of each issued certificate against the original CSR submitted by the subscriber. Certificates where www.\<domain\> appeared in the issued SAN but not in the CSR were classified as misissuances. Certificates belonging to eMudhra's own domains were excluded from the subscriber impact count. Domain control validation for the affected certificates was performed using the DNS TXT record method prior to certificate issuance.
• Additional considerations: N/A

Affected certificates were identified by cross-referencing the SAN of each issued certificate against the original CSR submitted by the subscriber. Certificates where www.<domain> appeared in the issued SAN but not in the CSR were classified as misissuances. Certificates belonging to eMudhra's own domains were excluded from the subscriber impact count. Domain control validation for the affected certificates was performed using the DNS TXT record method prior to certificate issuance.

Timeline

Date / Time (UTC)	Event
02 May 2026 07:29	Earliest affected subscriber certificate issued via ACME pipeline.
29 May 2026 11:50	Latest affected subscriber certificate issued.
30 May 2026 00:30	Customer complaint triaged. Internal investigation initiated.
30 May 2026 07:00	Raised the internal incident to analyse further with the affected certificates.
30 May 2026 11:15	ACME www auto-addition logic was corrected.
30 May 2026 15:20	Preliminary Incident Report filed on Bugzilla CA Public Forum.
30 May 2026 - 02 Jun 2026	Full inventory analysis. Affected certificates identified via CSR-to-SAN comparison.
02 June 2026 11:30	Revocation initiated based on the certificate replacement confirmation by customers.
02 June 2026 19:15	Revocation of all 239 valid affected certificates completed.
09 June 2026	Full Incident Report prepared and submitted.

Related Incidents

Bug	Date	Description
Bug 1712120	2021-05-20	Sectigo: Inadequate DCV. A single-domain www subdomain order using email DCV could result in issuance where domain control of the relevant name had not properly occurred. Related www-vs-apex validation-scope theme.

Root Cause Analysis

Contributing Factor 1: ACME Pipeline www Auto-Addition Logic

• Description: The ACME issuance pipeline contained logic that unconditionally appended www.\<domain\> to the SAN of any certificate request containing a bare domain, without verifying whether the subscriber had explicitly requested the www variant. This logic was introduced recently as part of a pipeline update and was not present in earlier versions of the ACME implementation. The www opt-in feature is legitimate and compliant in eMudhra's portal and REST API channels; it was ported to ACME without preserving the subscriber consent mechanism. The change was not caught during QA and the feature was released to production.
• Timeline: Active from at least 02 May 2026. Disabled 30 May 2026.
• Detection: Detected via customer complaint on 30 May 2026.
• Interaction with other factors: No other contributing factors identified. This was a self-contained pipeline configuration issue.
• Root Cause Analysis methodology used: 5 Whys: The ACME pipeline applied www unconditionally → the opt-in feature was recently ported from portal/REST API without preserving the consent requirement → the change missed QA gates → no CSR-vs-SAN validation gate existed in ACME → pre-issuance controls did not include SAN-vs-CSR alignment checks → this requirement was not incorporated during the ACME pipeline design phase.

Lessons Learned

• What went well: The issue was identified and the pipeline fix deployed within the same day as the customer complaint. All 239 valid affected certificates were revoked within 5 days, meeting BR Section 4.9.1.1.
• What didn't go well: The www opt-in feature was ported from portal/REST API to ACME without preserving the subscriber consent requirement. This was a recently introduced change that was not present in earlier versions of the ACME implementation. The change missed QA gates as pre-issuance compliance checks were not included in the test suite at the time. No pre-issuance CSR-vs-SAN validation gate existed in the ACME pipeline.
• Where we got lucky: A customer complaint surfaced the issue while the scope was still limited to 239 subscriber certificates. All CSR data was retained, enabling accurate scope determination.
• Additional: This incident reinforces that any automatic SAN augmentation logic, even where the underlying feature is legitimate, must preserve subscriber consent mechanisms across all issuance channels.

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	30 May 2026	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	02 Jun 2026	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	30 Jun 2026	Complete
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	31 Aug 2026	Planned

Appendix

Certificate details published as attachment.

Comment 7

[Naveen Kumar ML]

The above Full Incident Report has been updated as per Comment 5

Comment 8

[Naveen Kumar ML]

We are working on the action items, and we will provide the update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	2026-05-30	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	2026-06-02	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	2026-06-30	Complete
Audit all non-ACME channels for similar SAN augmentation	Prevent	CF #1	Audit confirms no unrequested SANs in any channel	2026-07-15	Ongoing
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	2026-08-31	Ongoing

Comment 9

[Naveen Kumar ML]

Status Update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	2026-05-30	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	2026-06-02	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	2026-06-30	Complete
Audit all non-ACME channels for similar SAN augmentation	Prevent	CF #1	Audit confirms no unrequested SANs in any channel	2026-07-15	Complete
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	2026-08-31	Ongoing

Comment 10

[Naveen Kumar ML]

Remediation items are still ongoing. We would like to request that the Next Update field be set to 2026-08-31, the date when our next action item will be due.

Comment 11

[Naveen Kumar ML]

Status Update

Action Items

Action Item	Kind	Corresponding Root Cause(s)	Evaluation Criteria	Due Date	Status
Disable ACME www auto-addition logic	Prevent	CF #1	No certificates issued with unrequested www SAN via ACME	2026-05-30	Complete
Revoke all 239 valid affected subscriber certificates	Mitigate	CF #1	CRL and OCSP confirm revocation	2026-06-02	Complete
Implement pre-issuance SAN vs CSR validation gate in ACME	Prevent	CF #1	SAN content must match CSR-requested domains for all ACME issuances	2026-06-30	Complete
Audit all non-ACME channels for similar SAN augmentation	Prevent	CF #1	Audit confirms no unrequested SANs in any channel	2026-07-15	Complete
Deploy automated post-issuance monitoring for SAN outside CSR scope	Detect	CF #1	Alert fires within 24h for any cert issued with SAN not in CSR	2026-08-31	Complete

Comment 12

[Naveen Kumar ML]

Report Closure Summary

• Incident description:
  Between 02 May 2026 and 30 May 2026, eMudhra's ACME issuance pipeline automatically appended the corresponding “www.<domain>” label to the SAN extension of certificate requests submitted for a base domain, without the subscriber having requested or authorized that identifier. The behaviour was inconsistent with CA/Browser Forum TLS BR Section 4.2.1. The issue was reported by an external complaint on 30 May 2026, and 239 subscriber certificates (DV and OV TLS end-entity certificates issued via ACME) were affected. Domain control for all identifiers, including the added “www” label, was validated using the DNS TXT record method prior to issuance. The incident was therefore limited to a subscriber authorization defect rather than a domain validation failure; this was clarified in response to the review question.

• Incident Root Cause(s):
  The “www” inclusion option is a legitimate, BR-compliant feature offered as an explicit subscriber opt-in through eMudhra's web portal and REST API channels. During a pipeline update it was ported to the ACME implementation without carrying over the subscriber consent mechanism, so the label was appended unconditionally. Two separate gaps allowed the change to reach production: pre-issuance compliance checks were not part of the ACME QA test suite, and no runtime gate existed to verify that the SAN content of an issued certificate matched the identifiers requested in the corresponding CSR

• Remediation description:
  The unconditional “www” auto-addition logic was disabled in the ACME pipeline on 30 May 2026, the same day the complaint was triaged. Affected certificates were scoped by direct CSR-to-certificate SAN comparison, and all 239 remaining valid certificates were revoked by 02 June 2026 19:15 UTC, within the BR Section 4.9.1.1 timeline. A pre-issuance SAN-vs-CSR validation gate was implemented in the ACME pipeline on 30 June 2026, blocking issuance of any identifier not present in the subscriber's request. An audit of all non-ACME issuance channels for comparable SAN augmentation behaviour was completed on 15 July 2026 and confirmed no unrequested SANs in any channel. Automated post-issuance monitoring that alerts within 24 hours on any certificate containing a SAN entry outside CSR scope was deployed on 31 August 2026. All five action items are Complete.

• Commitment summary:
  eMudhra will maintain the pre-issuance SAN-vs-CSR validation gate and the post-issuance SAN monitoring alert as permanent production controls across all issuance channels. Any feature that augments certificate contents will preserve its subscriber consent mechanism when ported between issuance channels, and pre-issuance compliance checks are now a required element of the QA test suite for changes to any issuance pipeline. Subscriber-facing options such as www inclusion remain available only as an explicit opt-in.

All Action Items disclosed in this report have been completed as described, and we request its closure.

Comment 13

[incident-reporting]

This is a final call for comments or questions on this Incident Report.

Otherwise, it will be closed on approximately 2026-09-14.