AI-Enabled Technical Exposure Risk (ATER): From Public Technical Disclosures to Exposure Intelligence for Cybersecurity Resilience

Abstract

Public technical disclosures support transparency, certification, procurement, interoperability, and cybersecurity governance, but AI-assisted open-source intelligence (OSINT) can make dispersed records easier to connect and reuse. This article introduces AI-Enabled Technical Exposure Risk (ATER), a disclosure-review framework for deciding how public technical detail should be reported when aggregation and linkage increase its security relevance. The framework is developed through a cutover-bounded corpus of public EUCC/Common Criteria certification artifacts available through the ENISA certificate portal by 15 April 2026. This study combines conceptual framing, descriptive corpus screening, and pilot feasibility checking of the disclosure-review workflow. The results show that public certification artifacts can contain recurring traceability signals, candidate technology linkages, version or scope uncertainty, evaluation-boundary indicators, and related security-relevant disclosure patterns that become more visible when reorganized at aggregate level. A practical disclosure-risk flowchart was derived from the study codebook and pilot-calibrated against evidence-tier and disclosure-decision categories in the corpus. The analysis characterizes aggregate publication-review patterns rather than inferring product-specific vulnerabilities. The resulting model offers authors, evaluators, and governance teams a structured basis for routing technical detail toward aggregate reporting, abstraction, contextual caveating, internal evidence retention, or further legal, certification, or security review.

1. Introduction

Public technical information supports transparency, accountability, procurement, interoperability, certification, and cybersecurity governance. Within linked public corpora, it can also create an exposure problem when dispersed records become easier to search, compare, and correlate through AI-assisted open-source intelligence (OSINT). Public procurement records, certification artifacts, regulatory disclosures, vendor documentation, and technical specifications can each support legitimate oversight and security review. Machine-assisted analysis changes their aggregate value by making security-relevant patterns more visible across sources [1,2,3,4].

We use AI-Enabled Technical Exposure Risk (ATER) to examine how a selected aggregate set of public EUCC/Common Criteria certification artifacts can become disclosure-relevant when public records are aggregated, correlated, and interpreted through AI-assisted methods. The analysis characterizes selected-set disclosure-exposure patterns and derives a publication-review flowchart while keeping product-vulnerability assessment, named-system evaluation, and operational risk-reduction validation outside the study scope. This European case is relevant because the Cybersecurity Act created a Union-wide certification framework, and the EUCC scheme operationalizes a Common Criteria-based path for ICT products [5,6,7,8].

The practical motivation follows from the dual use of the same public record. Critical infrastructure operators, supply-chain security teams, procurement authorities, regulators, and defenders rely on public technical information to interpret technology-related disclosure context, supplier and technology relationships, certification scope, and resilience obligations [3,4,9]. In hybrid threat contexts, that information can also support adversarial situational awareness when AI-assisted OSINT makes dispersed records easier to connect across registries, procurement documents, certification artifacts, and vendor documentation [3]. ATER treats aggregation itself as a disclosure-relevant condition while retaining the governance value of transparency and assurance.

EUCC carries forward core Common Criteria and Common Evaluation Methodology logic while adapting that logic to the European regulatory setting [10,11,12]. Public artifacts such as certificates, certification reports, protection profiles, and security targets sit inside that institutional process rather than outside it. They record what evaluators examined, how certification scope was drawn, and which security assumptions and objectives framed the assurance case [13,14,15,16]. Once published, those documents support transparency, but they also preserve details that can be searched, compared, and linked across products and certification packages.

Recent work has begun to examine this transparency-governance function more directly. The sec-certs research stream shows that Common Criteria artifacts can be collected at scale and mined for relationships among certified products, certificate references, and vulnerability information [17,18]. In related AI-assisted cybersecurity research, large language models and adjacent methods are used to extract entities, normalize structure, and condense long technical documents for threat intelligence, log analysis, incident response, and security-analysis support [4,19,20,21,22,23,24]. Certification-focused AI studies follow another path by emphasizing document generation, requirement selection, or certification-oriented risk reasoning [25,26]. These streams establish that certification corpora can be structured and queried, and that technical documents can be reorganized through structured extraction and summarization workflows. They do not yet explain how AI-assisted aggregation changes the governance meaning of public technical disclosures when certification artifacts form one case within a broader OSINT exposure surface.

The broader ATER problem includes multiple categories of public technical disclosure. In this article, the empirical layer consists of an aggregate review of what public EUCC/Common Criteria certification packages make analytically visible across linked records, together with a disclosure-flowchart model derived from that selected set. ATER therefore operates here as disclosure-exposure analysis. We examine how public certification documents, considered together, make traceability patterns, cross-document references, scope exclusions, and version uncertainty analytically visible as public technical information becomes easier to process through AI-assisted OSINT. The same public information can help stakeholders interpret supplier claims, certification coverage, and declared scope boundaries within responsible-use boundaries.

The governance setting reinforces this narrower problem. AI governance work explains why accountability, impact assessment, standardization, and human oversight matter when organizations rely on generative systems [27,28,29,30,31,32]. Supply-chain and resilience research shows why public security information can matter beyond the original certification event [3,4]. Common Criteria research, in turn, shows that certification artifacts already encode structured security and assurance information [15,17,33]. The unresolved issue is narrower than a general claim about AI and transparency: the literature does not yet explain how AI-assisted reorganization changes the practical governance meaning of public technical disclosures when analysts compare many records, follow document-to-document references, and isolate recurring scope boundaries within a selected-set review.

The main research question follows from this gap:

RQ0: How can publicly available EUCC/Common Criteria certification documents be organized into an aggregate ATER analytical surface that supports disclosure-risk categorisation without making product-specific vulnerability claims?

The supporting research questions are:

• RQ1: What forms of public traceability, candidate linkage, and version-or-scope uncertainty emerge when EUCC/Common Criteria certification packages are screened at aggregate level?
• RQ2: What governance concerns arise when public certification artifacts become easier to reorganize, compare, and correlate through AI-assisted processing?
• RQ3: How can evidence-tier and disclosure-decision categories derived from the selected EUCC/Common Criteria set be translated into a practical ATER flowchart model for organizational publication review?

We treat this study as a selected-set analysis of public EUCC/Common Criteria disclosure patterns and a calibrated ATER disclosure-review model. The article asks what the selected public artifacts make analytically visible when screened together, and how those observations can support publication-review decisions. General measurement of exposure risk across arbitrary IT systems, software stacks, organizations, or deployment contexts remains outside the study design.

The study develops an aggregation-focused ATER construct, screens linked EUCC/Common Criteria artifacts at aggregate level, and proposes a publication-review flowchart. In this framing, public certification artifacts serve as a case body for examining document structure, technical detail, evaluation boundaries, governance utility, and sensitivity [10,17]. The independent-coder consistency checks and AI-output review procedures support the screening design and keep AI-assisted extraction tied to source checking. The flowchart translates selected-set evidence tiers and disclosure decisions into practical publication-review routes. Together, these elements show how, within the selected public corpus, transparency, AI-mediated aggregation, responsible analytical use, and publication-review decisions intersect.

The article next develops the certification, EUCC/Common Criteria, AI-governance, AI-assisted extraction, and dual-use disclosure background. It then describes the corpus construction, processing workflow, codebook, ATER flowchart derivation, validation checks, analysis approach, and ethical boundaries. Section 4 reports the aggregate screening and disclosure-flowchart calibration findings. Section 5 interprets their implications for ATER, certification transparency, AI-mediated security knowledge, supply-chain governance, and publication review, and Section 6 summarizes limitations and future research directions.

2. Literature Review and Conceptual Background

2.1. Cybersecurity Certification as Governance and Transparency

Cybersecurity certification is often presented as technical assurance, but its institutional effect is equally important: it creates public claims that procurement actors, regulators, suppliers, auditors, and users can reuse after evaluation. The EU Cybersecurity Act established the European certification framework and assigned ENISA a central role in scheme development and implementation [5,7]. EUCC extends that framework through a Common Criteria-based scheme for ICT products [6,8]. Certification documents therefore operate as conformance records and governance artifacts across markets and oversight settings.

This wider role matters because transparency is not equivalent to resilience. NIS2 and the Cyber Resilience Act broaden the compliance environment in which certification evidence may be read, reused, and compared [9,14,34,35]. Ferguson’s legal analysis supplies an important corrective: certification policy may strengthen trust signaling without ensuring organizational resistance and recovery from cyber incidents [36]. This distinction sets the article’s boundary. Certification artifacts matter for governance, but public certification disclosure cannot be treated as a direct measure of security performance. The narrower issue is how these documents organize security-relevant information, and what changes when AI tools compare it across public artifact sets.

2.2. EUCC and Common Criteria Implementation

EUCC builds on Common Criteria within a European regulatory architecture. Yener emphasizes that EUCC preserves the established certification structure while strengthening lifecycle attention to patch management, vulnerability management, and disclosure [10]. ENISA’s implementation documents for certification bodies and ITSEFs emphasize accreditation, competence, independence, transition rules, and institutional responsibility [11,12]. Andrukiewicz and Krawiec add a testing-laboratory perspective, stressing disciplined, reproducible evaluation practice over abstract legal design alone [13].

Common Criteria scholarship clarifies this continuity at document level. Sun et al. explain how protection profiles and security targets translate security requirements into certifiable form, while noting adoption barriers and implementation difficulty [15]. Kang and Kim show the same logic in a product setting: Security Target and protection-profile structures formalize product boundaries, assumptions, and security claims rather than describe a device in marketing terms [16]. Sun et al.’s later work on cyber assurance adds an organizational layer by examining why firms adopt these mechanisms [33]. These studies establish certification artifacts as structured technical documents, but say less about their secondary analytical value once public.

Disclosure exposure also has an incentive dimension. Security investment has been modeled as a cost-benefit problem involving potential loss, threat probability, vulnerability, and protection cost [37]. Market-reaction studies of security-breach announcements show that public security information can be examined as an event with organizational consequences [38]. Research in another decision domain has examined peer effects in long-term savings choices [39]. These sources do not show that EUCC artifacts create market effects. They support treating aggregation-aware disclosure review as an allocation and governance problem in which publication decisions preserve assurance value while accounting for recombination by later users.

The clearest evidence on secondary use comes from the sec-certs research line. Janovsky et al. show that Common Criteria and FIPS 140 artifacts can be collected, normalized, linked, and analyzed at scale [17]. Their later work on certificate references shows that public artifacts expose dependency and relationship structures not obvious from isolated reading [18]. The debate therefore moves beyond whether certification artifacts are machine-processable toward what security-relevant inference becomes available when EUCC/Common Criteria documents are processed as a public corpus.

2.3. Sectoral and Supply-Chain Certification

Sectoral certification research broadens this problem by showing that certification rarely stays confined to one assurance event. In supply-chain settings, certification design is tied to service dependency, supplier assurance, and governance coordination [40,41]. Healthcare and composite-system studies show that schemes must adapt to domain-specific risks, interdependencies, and layered architectures [42,43,44]. Colabuono et al. similarly treat sector-specific security problem definition as part of scheme design rather than as a peripheral concern [45].

This work strengthens the governance framing but leaves a limit: most sectoral studies ask how certification should be designed or applied, not what follows when outputs become public artifacts that can be mined, cross-referenced, and aggregated. Procurement research helps close part of that gap. Ruohonen and Pandey show that public purchasing records can reveal cybersecurity-relevant patterns and omissions when analyzed as corpora rather than isolated administrative files [1,2]. Parlov’s supply-chain governance work extends the point to AI-enabled digital ecosystems, where documentation becomes part of the control surface [3]. For EUCC/Common Criteria, public certification documentation matters because it can inform supplier review, risk governance, disclosure review, and defensive interpretation across organizational boundaries, not because it proves secure products.

That downstream role links certification artifacts to the governance problem addressed next. When scope statements, evaluation boundaries, and assumptions remain traceable to source text, public certification records may support regulatory interpretation, procurement comparison, supplier review, compliance documentation, and technology-risk management [1,2,3,9]. AI-assisted text reorganization makes dispersed technical disclosures easier to compare across certification, procurement, compliance, and risk-management contexts, while increasing the importance of accountability, human oversight, and source-anchor verification [30,31,32,46].

2.4. AI Governance and Responsible Use of Generative AI

AI governance literature is more than contextual background here. Regulatory and standards sources converge on a practical point: when AI outputs shape organizational judgment, documentation, accountability, and human oversight remain necessary [27,28,29,30,31,32,46]. The EU AI Act and FRIA-oriented work emphasize accountability obligations in decision contexts [28,46], while ISO/IEC 42001, ISO/IEC 23894, and the NIST Generative AI Profile translate that concern into risk-control practice [30,31,32]. Applied to certification artifacts, this logic requires AI-assisted outputs to remain auditable against source text.

This requirement is not just regulatory formalism. In cybersecurity, unsupported AI output can convert a source-grounded document into a misleading analytical product. Explainable AI research makes this point clearly: analysts need to understand why a system surfaced a conclusion before relying on it in review, accountability, or governance interpretation [47,48]. This article therefore treats generative AI as an extraction and structuring aid, not as an autonomous evaluator of certified-product security. The methodological boundary is that AI-assisted interpretation remains dependent on anchor-based verification.

2.5. Generative AI for Cybersecurity Knowledge Extraction

The cybersecurity literature shows that generative AI can reorganize messy text into structured analytical representations. Researchers have used LLM-assisted workflows to extract attack techniques from cyber threat intelligence and build CTI knowledge graphs [19,20,21]. Other studies apply similar methods to log-template identification, incident-response playbook drafting, and OSINT support [22,23,49]. Across these studies, long, uneven, partly structured text is converted into entities, relations, categories, or summaries.

That transformation is relevant because certification artifacts share a practical obstacle with CTI and incident-response documents: they are public, often lengthy, partly standardized, and difficult to compare as a corpus. The analogy still has limits. Threat-intelligence reports and incident logs support immediate operational interpretation, whereas certification artifacts document assurance claims, evaluation scope, and formal boundaries. The literature supports transfer of method, not equivalence of purpose.

Research on AI in governance and misuse-sensitive cybersecurity contexts sharpens the dual-use issue. Studies of generative-AI safety evaluation, LLM threat modeling, and LLM-enabled cybersecurity workflows indicate that the same systems can support different security interpretations [24,50,51,52]. Reviews of LLMs for cybersecurity and generative AI for critical-infrastructure protection generalize that point: capability claims and governance risks must be assessed together [4,53]. What remains unclear is whether certification transparency creates a comparable dual-use governance pattern once documents are aggregated and reorganized.

2.6. AI and Certification-Oriented Automation

A smaller literature brings AI closer to certification itself, but still stops short of the present problem. Chen et al. use machine learning and expert-system logic to support Common Criteria document generation, including Security Functional Requirement selection and Evaluation Assurance Level prediction [25]. Islam et al. propose a hybrid AI framework for dynamic risk assessment and explainable conformity reasoning in composite-product certification [26]. Both studies show that certification workflows can be computationally supported.

Their orientation is upstream. Chen et al. help produce certification documents, whereas Islam et al. help interpret certification status within risk-assessment processes. Neither study directly examines what happens after certification artifacts enter the public domain for secondary analysis by outsiders. The disclosure stage remains underdeveloped because aggregation and AI-assisted correlation may affect transparency risk only after publication. This article addresses that downstream stage by focusing on already-published EUCC/Common Criteria artifacts and the conditions under which their disclosed content may become relevant to governance and misuse-sensitive interpretation.

2.7. ATER as a Disclosure-Exposure Model

The synthesis above positions ATER as a disclosure-exposure evaluation model for AI-assisted analysis of public technical artifacts. Certification transparency supplies the institutional setting. Common Criteria corpus analysis shows that public certification records can be collected and linked, AI-assisted cybersecurity extraction supports structured conversion of long technical texts, and AI risk-governance literature sets the accountability and human-oversight boundary. On this basis, the article treats public certification artifacts as assurance records that also carry technical detail, evaluation boundaries, and formalized assumptions. The core proposition is that AI-assisted extraction and correlation can change how disclosed information is organized for later governance analysis. That proposition synthesizes the cited sources rather than a claim established by any single study.

The proposed model begins with publication, not vulnerability. Certification governance produces public artifacts because transparency is part of assurance communication. Those artifacts contain varying amounts of technical detail, security content, evaluation scope, and usage assumptions. Greater standardization may make disclosed content more amenable to structured aggregation and cross-document interpretation, while greater specificity may make the same content relevant to governance and misuse-sensitive readings of certification scope, dependencies, and assumptions. In this model, dual-use concern emerges only when those conditions coincide with information that remains sensitive after aggregation.

This synthesis avoids two overbroad assumptions. It does not assume that transparency is harmless because certification documents are public, or that disclosure is harmful by default. In this manuscript, dual-use risk depends on the interaction among document structure, information content, AI-processability, and analyst purpose. The article’s variables are derived from these interactions rather than from any prior assumption that one document type is already proven superior in the selected corpus.

The ATER disclosure-decision categories used later are not prior-established. They are this article’s model contribution, derived from the selected EUCC/Common Criteria screening workflow and calibrated against the selected evidence-tier set. The categories separate material suitable for anonymized aggregate publication from material requiring abstraction, caveats, restriction to internal evidence logs, or further review. Prior certification, corpus-analysis, AI-extraction, and AI-governance literature supports traceability, aggregation awareness, source anchoring, and human oversight, but does not establish these exact categories as universal for all organizations or disclosure contexts.

Conceptually, the model starts from public artifacts generated by certification governance. Their structure affects AI-processability, and their technical or evaluative specificity shapes interpretive relevance. Disclosure exposure emerges when that relevance intersects with information sensitivity, especially when AI-assisted extraction reorganizes dispersed public records into structured outputs. Figure 1 connects this sequence to the article’s package-level workflow, including traceability coding, evidence-tier review, source-anchor checking, aggregate screening, and ATER flowchart development.

Figure 1. Conceptual model linking certification-document structure, security-relevant content, AI-processability, interpretive relevance, disclosure exposure, and governance implications. Source: Author’s work.

3. Materials and Methods

3.1. Research Design

A hybrid empirical case-study design was used to examine AI-Enabled Technical Exposure Risk (ATER) through public EUCC/Common Criteria certification artifacts. The study was framed as a selected-set state-of-affairs analysis of public certification disclosure patterns and as a calibrated disclosure-review model. It was not designed to validate a general method for measuring exposure risk across arbitrary IT systems, software stacks, organizations, or deployment contexts.

The artifacts were examined through structured content analysis, aggregate corpus screening, ATER disclosure-flowchart derivation, calibration, consistency checking, and AI-output source-quality review. Codebook checking, independent second-coder review, and source-anchor review were included in the validation layer. Qualitative interpretation was combined with descriptive quantification. Reporting was limited to corpus-composition summaries, aggregate screening results, ATER disclosure-flowchart calibration, and consistency and source-quality findings. Broader document-type inference, cross-domain ATER comparison, and manual-versus-AI timing analysis were not included. Figure 2 summarizes the selected-set workflow from corpus construction through consistency and source-quality review.

Figure 2. ATER case-study methodology workflow for the selected EUCC/Common Criteria set, including pilot consistency and AI-output source-quality review. Source: Author’s work.

3.2. Corpus Construction

The corpus frame was defined as publicly accessible EUCC/Common Criteria certification packages for ICT products and protection profiles disclosed through official or scheme-linked publication channels. Relevant document classes and provenance fields were delimited with reference to Common Criteria practice and EUCC implementation documents [10,11,12,14,15].

The corpus was delimited by a predefined public-availability cutover date of 15 April 2026. Packages were retained when the relevant certification artifacts were publicly available through the ENISA certificate portal, https://certification.enisa.europa.eu/certificates_en (accessed on 20 May 2026), by that date. The later working collection and indexing window, from 9–20 May 2026, was used only to retrieve, verify, de-duplicate, and freeze the reporting snapshot. For provenance control, each retained package was indexed by certification subject, vendor or certificate holder, issuing body, scheme, year, document type, language, assurance level where available, source URL, registry identifier, and availability status.

A package was included when a publicly listed certification subject could be linked to at least one available certificate-related artifact with sufficient metadata. Packages were excluded when documents were unavailable or inaccessible, when the item was only a marketing text without certification status, when linkage to a specific subject could not be established, or when the package was a verified duplicate. Identifying metadata were used for internal indexing and provenance control, not for product-specific article claims.

The inclusion criteria were intentionally tight: source-verifiable package linkage, public availability at the 15 April 2026 cutover, and safe aggregate reporting were prioritized over maximizing corpus size. The resulting corpus should therefore be read as a bounded, source-verifiable EUCC/Common Criteria document set for ATER model development, not as a representative statistical sample of EUCC/Common Criteria certifications.

Duplicate checking was performed at package and document levels. Records were treated as verified duplicates when the same certification subject, certificate identifier, issuer, and document type appeared more than once, or when file hashes and metadata indicated identical content under different download paths. Verified duplicates were excluded from the analyzed corpus. Items that showed partial metadata overlap but could not be confirmed as duplicates at the freeze date were retained as duplicate-candidate packages and were flagged separately from verified duplicates. When multiple versions were available, the version current at the freeze date was retained.

Language was recorded for every document. English-language documents were coded directly. Non-English documents were retained when certification status and document type could still be verified, and translation support was used only where needed for coding. Any decision affected by ambiguous terminology or translation uncertainty was noted in the coding record.

3.3. Unit of Analysis

The primary unit of analysis was the certification package. The secondary unit was the individual document within that package. Package-level interpretation was thereby enabled while document-level comparison across certificates, certification reports, and security targets was preserved. When a package lacked one or more core document types, the package was retained, and each missing type was recorded as absent for corpus-completeness calculation and document-availability evaluation. For discussion purposes, AI agents using AI-assisted open-source intelligence (OSINT) could have been applied as an additional discovery procedure to search for and download candidate missing public documents. That procedure was not exercised for this article, and absence was therefore evaluated only against the document sources used in the defined corpus-construction workflow.

The unit hierarchy was fixed before analysis to avoid treating documents, packages, mapping rows, products, and vendor groups as interchangeable denominators. Table 1 summarizes the hierarchy and its inference limits.

Table 1. Unit-of-analysis hierarchy and inference limits.

Analytical Level	Count	How Observations Were Collapsed	What Was Not Inferred
Individual document	86	Counted as certificates, reports, or security targets inside packages	Product, component, or vulnerability prevalence
Certification package	31	Grouped by certification subject and public package linkage	Representativeness beyond the portal and cutover frame
Complete triplet	23	Identified when all three core document types were present	Mapping availability or traceability strength
Mapped screening row	43	Derived from package-linked component, technology, library, or device-class observations	Unique products, components, or vulnerabilities
Mapped product	23	Collapsed from linked rows to anonymized product-level summaries	Product-specific exposure or exploitability
Mapped package	23	Collapsed from linked rows to package-level strongest tier	Equivalence to complete-triplet status, despite the same count
Vendor/manufacturer group	9	Collapsed to anonymized group-level strongest tier	Organization-specific security posture

3.4. Document Processing

PDF artifacts were converted into analyzable text through a staged extraction procedure. Page-level text was first extracted with PyMuPDF and linked to page numbers. Documents with complex layout, poor reading order, or table-heavy structure were then reprocessed with marker-pdf. When tables remained ambiguous, pdfplumber or direct PDF inspection was used for checking.

The extracted text was compared against the source PDF for page order, heading loss, table loss, OCR defects, and language-related distortion. Defects that could affect coding were recorded in the coding notes. Source provenance was retained through URLs, registry identifiers where available, extraction tool, and extraction date.

3.5. Codebook

Documents were coded with a predefined codebook derived from the research questions and from the study objective of describing what public certification artifacts expose, how clearly they expose it, and how readily that content can be transformed into structured analytical output. The active variables used in this manuscript are summarized in Table 2.

Table 2. Active coding variables and scales.

Domain	Variables	Scope	Scale
Identification	document_type, certification_subject, vendor_or_holder, certification_body, scheme_or_authority, year_or_certificate_id, language	Identify the document, certification subject, issuer, and publication context	nominal or text
Structure	structural_standardization, ai_processability	Capture format regularity and extraction ease	1–5
Technical detail	toe_description, architecture_detail, interface_detail, cryptographic_information	Capture product boundary and technical specificity	TOE description: 0–2; others: 0–3
Security content	security_functions, security_objectives, threats, assumptions, secure_use_limitations	Capture explicit security content and environmental conditions	0–3
Evaluation content	evaluation_scope, evaluation_boundaries, evaluation_specificity	Capture what was evaluated, excluded, and how specifically it was described	scope and boundaries: 0–3; specificity: 1–5
Blue-team value	hardening_utility, monitoring_utility, governance_utility	Capture defensive and governance usefulness	1–5
Red-team analytical value	attack_surface_utility, weakness_hypothesis_utility, scope_gap_utility	Capture non-exploitative analytical usefulness	1–5
Dual-use and sensitivity	dual_use_potential, information_sensitivity	Capture overlap between defensive value and exposure risk	1–5
Evidence control	citation_or_document_anchor, coder_note	Preserve traceability and uncertainty handling	text

For 0–3 content scales, 0 denoted absence, 1 generic presence, 2 moderate specificity, and 3 clear operational detail. For 1–5 value scales, 1 denoted very low presence or value and 5 denoted very high presence or value. When uncertainty remained, the lowest defensible score was assigned and documented.

Several terms were fixed before coding. AI-processability was defined as the ease with which relevant information could be extracted from document text by a fixed AI procedure with only formatting correction and source-anchor verification. Operationally useful detail was defined as content specific enough to support a concrete analytical interpretation without unsupported external inference. Utility and sensitivity variables remained part of the codebook framework, but those scores were not reported as study outcomes in this manuscript.

3.6. Component-Signal Screening and Evidence-Tier Coding

A linked component-signal screening dataset was derived from the certification-package inventory. One screening row was generated when a package-linked component, software or firmware item, library reference, physical component class, or technology class could be identified from the public certification artifacts and retained without product-identifying disclosure. When a precise component name was not stated but a relevant technology class was described, the observation was coded as a package-technology mapping rather than as a package-component mapping. Because multiple documents from the same package could support one row, and because the same broad component or technology could appear in more than one package-linked row, screening rows were treated as mapping observations rather than as counts of globally unique products, components, or vulnerabilities.

For category-level reporting, each screening row was assigned to one primary reporting category. Software application, operating-system, software-module, and software-on-device rows were grouped as Software. Explicit firmware and hardware-firmware rows were grouped as firmware-oriented rows. Library references were grouped as library rows. Physical secure-element, secure-microcontroller, TPM, and comparable device-class rows were merged as physical device classes.

The mapped screening set was limited to packages for which at least one package-component or package-technology mapping could be coded. It was analytically distinct from both the full 31-package corpus inventory and the 23 complete certificate-report-security-target triplets. Denominator changes were therefore reported explicitly: corpus composition was reported at document and package levels, component-signal screening was reported at mapping-row level, and integrated anonymized summaries were produced at product, package, and manufacturer levels. Identifying fields were retained only for internal provenance control and were not used for product-specific article claims.

Each screening row was assigned one public-traceability evidence tier. The tier captured the strongest public linkage observable from certification artifacts and public vulnerability or advisory metadata. Direct public evidence denoted a publicly observable documentary linkage. It was not interpreted as evidence that a vulnerability affected the evaluated product, evaluated configuration, certified version, or certification scope. Table 3 summarizes the applied thresholds.

Table 3. Public-traceability evidence-tier coding thresholds.

Evidence Tier	Coding Threshold
Direct public evidence	An explicit public linkage was present between the package-linked component, technology, product family, or stated version context and one or more public vulnerability or advisory identifiers. Version or scope applicability could still remain unresolved.
Family-level vulnerability signal	A public CVE or advisory signal was observable for the same product, component, or technology family, but no direct match was available for the exact evaluated version, configuration, or certification scope.
Technology-class signal	A public signal was observable for the broader technology class, protocol class, library class, or device class, but no direct product-family or evaluated-version linkage was established.
Adjacent or historical signal	A public signal was observable only through an adjacent or historical relationship, such as a predecessor, related product line, prior certification context, or legacy technology association.
Context only	Contextual technology or component information from public certification documents was present, but no public vulnerability or advisory signal meeting the preceding thresholds was recorded.

For integrated anonymized reporting, the strongest evidence tier observed across linked rows was assigned to each anonymized product, package, and manufacturer. The assignment was made after row-level signals had been linked to the relevant anonymized reporting unit and ordered by the evidence-tier hierarchy. The hierarchy, from strongest to weakest public traceability, was direct public evidence, family-level vulnerability signal, technology-class signal, adjacent or historical signal, and context only. The inclusive "any signal" category combined all tiers except context only. The "heuristic signal" category combined family-level vulnerability, technology-class, and adjacent or historical signals. These categories were used only to summarize public-traceability patterns and were not used to infer vulnerability applicability for any evaluated product, evaluated configuration, certified version, or certification scope.

3.7. ATER Disclosure-Flowchart Derivation and Calibration

An ATER disclosure-risk flowchart was derived from the selected EUCC/Common Criteria screening workflow to support publication review of technical detail. The model was specified as a disclosure-exposure evaluation model, not as a product-vulnerability model, product-risk score, or validated risk-reduction intervention. It was applied to already public or publication-bound technical information. One proposed technical detail, or one set of related technical details, was treated as the model input. Candidate inputs included component categories, interface descriptions, version statements, certification-boundary statements, maintenance notes, and vulnerability-evidence categories when such information appeared in public certification artifacts or in aggregate screening records.

The flowchart was constructed from the codebook variables, evidence-tier thresholds, and publication-safety controls used in the aggregate screening. Decision nodes were organized around seven main questions. These addressed disclosure necessity, linkable identifiers, correlation with public vulnerability or advisory intelligence and other public datasets, version or scope uncertainty, operational targeting value, preservation of analytical value through aggregation or abstraction, and post-publication governance controls.

Five disclosure-decision categories were defined for article-facing interpretation. Aggregate publication covered anonymized counts, proportions, or categories. Abstracted publication covered details for which identifiers or exact versions were generalized before publication. Caveated publication preserved version, configuration, certification-boundary, or maintenance uncertainty. Internal-only restriction covered details retained in restricted internal evidence logs. Hold for review covered details requiring legal, certification, vendor, or security review before publication.

Calibration was performed over the 43 reviewed package-component or package-technology mapping rows in the selected screening dataset. The calibration linked each evidence tier to a disclosure decision and an article-safe public output form. Because the flowchart was derived from and calibrated on the same reviewed rows, this step assessed internal coherence and feasibility rather than transfer to later registry snapshots, other product domains, organizations, or disclosure-review teams. The calibration used only aggregate row counts and category-level summaries. Product names, vendor names, certificate identifiers, component names, exact versions, CVEs, source URLs, exploit-status fields, and source-linked row anchors were excluded from article-facing outputs.

Publication-safety controls were applied before model outputs were considered article-safe. Direct public-evidence rows were restricted to aggregate counts with caveats. Family-level and adjacent-historical signals were converted into anonymized correlation categories with uncertainty statements. Technology-class signals were retained only as class-level aggregate signals. Context-only rows were treated as minimal context or omitted when they were not needed for the aggregate argument. Row-level ATER registers, source-linked evidence logs, direct vulnerability-mitigation matrices, and operational prompt text were retained as restricted internal or future-extension records and were not included in the current supplementary release.

Operationalization of ATER

ATER was operationalized as a framework for reviewing aggregation-sensitive technical disclosures in public or publication-bound technical information. Within this study, aggregate certification-evidence patterns were translated into article-safe publication choices by making linkage, aggregation, and version or scope uncertainty explicit before publication. The approach was positioned as a structured pre-publication check for aggregation-sensitive information and was not treated as a substitute for legal, certification, vendor, or security review.

Each candidate disclosure item was processed through the operational decision sequence summarized in Table 4. The item could be a single technical statement or a related set of statements. The decision sequence was applied only at the level needed for article-safe categorization. Identifying details were removed or generalized before public reporting when linkage, public vulnerability intelligence, version uncertainty, or operational sensitivity was present.

Table 4. Operational ATER decision sequence for publication review.

Step	Operational Question	If Yes	If No
1	Is disclosure required for assurance, reproducibility, governance, or accountability?	Continue to Step 2	Internal-only restriction
2	Does disclosure contain linkable identifiers for a technical object?	Continue to Step 3	Continue to Step 6
3	Can the object be correlated with public vulnerability or advisory intelligence or other public datasets?	Continue to Step 4	Continue to Step 6
4	Is version, configuration, certification-scope, or boundary uncertainty present?	Caveated publication and continue to Step 5	Continue to Step 5
5	Could publication increase operational targeting value when combined with other public records?	Hold for review or restrict internal detail	Continue to Step 6
6	Can analytical value be preserved through aggregation, abstraction, or minimal contextual reporting?	Aggregate, abstracted, or minimal-context publication and continue to Step 7	Hold for review or restrict internal detail
7	Are post-publication governance controls available?	Publication with the selected control from Steps 1 through 6	Hold for review until control ownership is assigned

The same seven-step sequence is visualized in Figure 3, with implementation checks for linkage confirmation, minimal-context sufficiency, abstraction, source-anchor retention, monitoring, and control-owner assignment.

Figure 3. ATER disclosure-exposure workflow showing the seven publication-review decisions and nested implementation checks. Source: Author’s work.

Table 5 provides sanitized routing examples used to clarify the operational rule without exposing product-, vendor-, version-, vulnerability-, certificate-, URL-, or internal-evidence details.

Table 5. Sanitized ATER routing examples.

Generic Disclosure Pattern	ATER Routing Output
Generic technology class with no linkable object	Aggregate publication
Linkable component family with unresolved evaluated-version applicability	Abstracted publication with a caveat
Direct public advisory or vulnerability linkage with unresolved version or certification-scope applicability	Aggregate-only publication with a caveat and internal evidence retention
Exact linkable object that could not be safely generalized	Hold for legal, certification, or security review

When linkage, version or scope, public-safety uncertainty, or technology-risk management impact could not be resolved, the less specific output was selected or the item was held for legal, certification, or security review.

The sequence was implemented conservatively. Public output was limited to the least specific form that preserved the manuscript’s aggregate analytical purpose. Caveated publication was used when version, configuration, certification-boundary, or maintenance uncertainty had to remain visible to readers. Internal-only restriction or hold for review was used when publication value was not established, when linkable technical detail could not be safely generalized, or when an appropriate post-publication governance control was unavailable.

Analyst judgments were checked against the same sequence. The candidate disclosure item, applicable evidence tier, and presence of linkage and version or scope uncertainty were recorded before the public output form was selected. Generic classes were retained when they were non-identifying. Exact product, vendor, component, certificate, CVE, source URL, exploit status, and source anchor mappings were retained only in restricted internal records.

3.8. Manual Coding Procedure

A 12-document pilot subset was used to test the codebook before broader execution. The subset was balanced across the three core document types, with 4 certificates, 4 certification reports, and 4 security targets drawn from 4 complete certification-document triplets. Variation in issuer, language, and extraction difficulty was sought so that the scoring rules would be tested against both straightforward records and records affected by layout, OCR, or table-recovery problems.

Evidence anchors were recorded for substantive scores. Page numbers, section labels, table identifiers, or short anchored excerpts were used so that each coding decision could be traced back to the source text. During this coding step, variable definitions and score thresholds were refined where repeated ambiguity appeared. A calibration memo was maintained for borderline cases, multilingual passages, and mixed-format records.

A 12-document second-coder check was then used for consistency review. The documents were reviewed independently by two coders against the adjudicated reference coding, codebook fields, and retained anchors. Discrepancies were resolved through source-anchor review rather than by averaging scores. Timing was recorded during the review but was retained in this manuscript only as workload-planning metadata. The 45% timing spread was a planning assumption around the 12-document review midpoint, not an observed uncertainty interval. These timing fields were not treated as manual-versus-AI benchmark evidence.

Manual coding was limited to public document content and to the variables defined in the codebook. Product probing, vulnerability testing, and inference of exploitability were not performed.

3.9. AI-Assisted Extraction Procedure

AI-assisted extraction was implemented as a fixed, codebook-aligned procedure rather than as open-ended prompting. Common Criteria artifacts have been shown to be amenable to machine-assisted structuring or automated mining, but human verification remains necessary because generated outputs may be incomplete, over-generalized, or inconsistent [17,25,54].

The AI-supported pass was completed on the same 12-document subset used for manual coding. Extraction targets included TOE or product description, security functions, architecture and interface detail, cryptographic information where stated, threats, assumptions, objectives, evaluation scope, exclusions, and secure-use limitations. AI outputs were treated as candidate extractions only. A claim was accepted into the validation record only after it had been checked against the source document and, when necessary, corrected to the human-verified anchor.

The procedure was designed to assess whether public certification documents could be transformed into structured analytical knowledge without treating model output as evidence. Detailed run logs and local workflow identifiers were kept in the reproducibility record and were not reported in the article text.

3.10. Consistency Check and Validity

Two source-anchored checks were used to keep the workflow auditable: an independent second-coder consistency check and a document-level source-quality review of AI-assisted extractions. The second-coder check covered all 12 documents. Coder-level agreement and anchor-agreement fields were recorded against the adjudicated reference coding so that disagreements could be traced and adjudicated. Internal coding discipline and workflow feasibility were supported by these records. Because the pilot remained small and was not designed as a full reliability study, no formal inter-coder coefficient was estimated for this manuscript.

AI-output source-quality review was carried out against human-adjudicated evidence anchors on the same subset. Unsupported outputs were classified as hallucinated, mislocated, or over-generalized. For each document-task pair, a binary source-quality status, together with counters for unsupported claims and missing fields, was recorded. These records were used to summarize AI source-quality review without reproducing row-level extraction logs.

Construct validity was supported by separating descriptive technical-detail variables from the study-specific utility and sensitivity variables. The risk that longer or denser documents would be treated as more important solely because they contained more text was reduced by this separation.

3.11. Statistical Analysis

The analysis was designed to describe what became visible when public certification artifacts were organized as a linked disclosure corpus. Counts and percentages were therefore used to summarize corpus composition, public-traceability tiers, candidate-linkage signals, version or scope caveats, and disclosure-decision categories. No composite utility score, dual-use score, or manual-versus-AI timing benchmark was calculated, because the study did not test a scoring model or compare analyst performance.

Wilson 95% confidence intervals were calculated for selected direct-evidence proportions by the standard Wilson score method without continuity correction. These intervals were used only as a small-sample uncertainty anchor for proportions reported from the screened dataset. They were not interpreted as population estimates for EUCC/Common Criteria certifications more broadly. Reporting for the 12-document subset was likewise kept descriptive and was limited to sample composition, independent-coder check status, document-level AI source-quality status, raw error-category counts, and workload-planning timing metadata.

Inferential comparisons were not performed. The coded sample was assembled to support aggregate disclosure screening and ATER flowchart calibration, not to test document-type differences or causal relationships. The relationship between structural standardization and AI-processability was therefore treated as a future research question rather than as a statistical result in this manuscript.

3.12. Ethical and Security Boundary

The ethical boundary was defined around responsible use of already public certification information. Public artifacts were examined as disclosure evidence, not as starting points for product testing or vulnerability validation. Exploitation, scanning, probing, reverse engineering, bypass attempts, and other product-directed security tests were not performed. Product-specific offensive interpretations were therefore not reported as vulnerabilities or as evidence of affected certified products.

The reporting boundary was designed to preserve the governance value of public technical disclosure while reducing the chance that the article would help reconstruct product-level mappings, component exposure, or attack paths. When a detail appeared more sensitive after aggregation with other public information, the analytical category was retained but the operationally specific detail was withheld from manuscript reporting. Red-team-oriented observations were consequently abstracted into disclosure-review categories and were not presented as procedural instructions.

3.13. Reproducibility Materials

Reproducibility was addressed by preserving the audit trail needed to understand how the public-document corpus was assembled and screened. The original certification materials were accessed through the ENISA certificate portal, https://certification.enisa.europa.eu/certificates_en (accessed on 20 May 2026), and document-level metadata were retained for corpus accounting. Internal records were maintained for the corpus inventory, inclusion and exclusion decisions, duplicate checks, corpus freeze, extraction provenance, subset coding sheets, independent-coder consistency sheets, AI-validation sheets, and calibration notes.

The reproducibility package was designed to support review of the analytical workflow rather than reconstruction of product-specific attack paths. A reduced audit package was therefore defined for supplementary release. It retains aggregate tables, coding definitions, validation summaries, and calibration information, while withholding third-party documents, product-identifying row-level mappings, source-linked anchor logs, raw AI outputs, operational prompts, and other material restricted by legal, contractual, or security considerations.

Three reproducibility categories were therefore separated. Public methodological transparency and aggregate-result inspection are supported by the article and sanitized supplementary tables. Confidential auditability may be supported, if journal policy permits, through editor- or reviewer-only inspection of restricted provenance material. Public release was withheld for material that could reconstruct product, component, vulnerability, exploit-status, mitigation, source-anchor, or row-level ATER mappings.

4. Results

Results are reported across four aggregate layers: corpus composition, screening signals, ATER calibration, and validation checks. The corpus results establish the document and package base. The screening results describe how traceability signals, version or scope caveats, reviewed-unit denominators, and category-level linkage patterns appeared in the mapped subset. The calibration and validation results report how those observations were routed into article-safe disclosure decisions and checked against source-grounded coding records. Product-identifying and source-linked details are withheld throughout under the disclosure boundary defined in the Methods.

4.1. Corpus Overview

Table 6 summarizes the document base used for later screening and calibration. The inventory contained public certification artifacts grouped by package and core document type, so the analysis treated certificates, certification reports, and security targets as linked records where package structure allowed it. The table reports corpus composition and document availability only. Later denominators are narrower reviewed units and are reported separately where used.

Table 6. Composition of the analyzed EUCC/Common Criteria corpus inventory.

Corpus Dimension	Result
Certification packages	31
Individual documents	86
Certificates	28
Certification reports	30
Security targets	28
Complete packages	23
Incomplete packages	5
Duplicate-candidate packages	3
Languages represented	2
English-language documents	50
French-language documents	36

4.2. Public-Traceability Tier Distribution in the Component-Signal Screening Dataset

From the 31-package corpus inventory, a mapped screening subset was formed where public certification artifacts supported at least one package-component or package-technology mapping. This subset contained 43 reviewed mapping rows. Each row represented one package-linked component, technology class, library reference, or device-class mapping, not one document, one globally unique component, or one vulnerability. Five public-traceability evidence tiers were retained for this selected-set analysis: direct public evidence, family-level vulnerability signal, technology-class signal, adjacent or historical signal, and context only. Table 7 reports their row-level distribution.

Table 7. Public-traceability and linkage-signal tier distribution in the component-signal screening dataset.

Evidence Tier	Rows	Share (%)
Direct public evidence	11	25.58
Family-level vulnerability signal	8	18.60
Technology-class signal	12	27.91
Adjacent or historical signal	1	2.33
Context only	11	25.58

At mapping-row level, heuristic signals outnumbered direct public evidence. The inclusive direct-or-heuristic share was 74.42%, and the heuristic-to-direct ratio was 1.91. These measures describe how often public artifacts supported traceability or correlation signals in the screened set. They should not be read as confirmation of version-specific exposure.

4.3. Aggregate Distribution Across Reviewed Units

The 43 mapping observations were also summarized across higher-level anonymized units: mapping rows, mapped products, mapped packages, and vendor/manufacturer groups. The product and package denominators were both 23, but they refer to distinct aggregation levels. Here, the package denominator means packages with at least one component or technology mapping. It is not the same analytical condition as the 23 complete certificate-report-security-target triplets reported in Section 4.1. For each higher-level unit, the strongest observed public-traceability tier was retained. Table 8 summarizes the resulting distribution.

Table 8. Aggregate public-traceability tier distribution across reviewed units.

Unit	N	Direct Tier	Any Signal	Context	Direct (%)	Any (%)
Mapping rows	43	11	32	11	25.58	74.42
Products	23	5	20	3	21.74	86.96
Packages	23	5	20	3	21.74	86.96
Vendor groups	9	2	7	2	22.22	77.78

Traceability was common after rows were collapsed into higher-level units, but direct evidence remained less frequent than broader signal presence. The direct-evidence rate was 25.58% at mapping-observation level, with a Wilson 95% confidence interval of approximately 0.15 to 0.40. At mapped product and mapped package levels, the corresponding rate was 21.74%, with Wilson 95% confidence intervals of approximately 0.10 to 0.42. These intervals are descriptive uncertainty summaries for the selected anonymized screening dataset only. They are not population estimates for European ICT certifications or for EUCC/Common Criteria certifications.

4.4. Category-Level Patterns

Table 9 reports the category-level pattern after small row types were merged under the predefined reporting rules. Software includes application, operating-system, module, and software-on-device rows. Firmware-oriented rows combine firmware and hardware-firmware entries. Library rows retain library references, and physical device classes group secure-element, secure-microcontroller, TPM, and comparable device-class mappings. The heuristic column combines family-level, technology-class, and adjacent-historical signals.

Table 9. Category-level distribution and candidate-signal share.

Category	Rows	Direct Tier	Heuristic	Context	Direct (%)	Any (%)
Software	18	5	8	5	27.78	72.22
Firmware-oriented rows	6	5	0	1	83.33	83.33
Library	9	0	5	4	0.00	55.56
Physical device classes	10	1	8	1	10.00	90.00

The visual matrix in Table 10 provides a compact view of the same Table 9 distribution. The matrix summarizes the uneven distribution of linkage strength across anonymized screening categories without implying product-level vulnerability counts.

Table 10. Visual matrix of category-level public-traceability signal strength.

Category	Direct Tier	Heuristic	Context
Software	5	8	5
Firmware-oriented rows	5	0	1
Library	0	5	4
Physical device classes	1	8	1

Signal strength varied by category. Firmware-oriented rows had the highest direct public-evidence rate, whereas library rows had no direct-tier entries and retained a larger contextual share. Physical device classes showed high inclusive signal coverage but low direct-evidence coverage. Physical device classes accounted for 10 of 43 reviewed rows, or 23.26%.

4.5. Package-Level Strongest-Tier Profile

Package-level reporting in this subsection includes only the 23 mapped screening packages. This denominator is important because it aligns numerically with the 23 complete triplets reported in Section 4.1, while representing a different analytic basis. In Section 4.1, inclusion was determined by document completeness. Here, inclusion required available package-component or package-technology mappings, so the denominator identifies the packages for which public traceability could be assessed at package level. Table 11 reports the strongest public-traceability tier observed for each mapped package.

Table 11. Strongest public-traceability tier observed per reviewed package.

Strongest Package Tier	Package Count	Share (%)
Direct public evidence	5	21.74
Family-level vulnerability signal	5	21.74
Technology-class signal	10	43.48
Context only	3	13.04

At package level, the strongest-tier result was concentrated most clearly in technology-class signals, which represented the largest share of mapped screening packages. This pattern is analytically important because it shows that the package-level evidence base was driven primarily by signals tied to technological characteristics, while direct public evidence appeared in 5 mapped packages and 3 packages remained contextual only.

4.6. Public CVE and CISA Known Exploited Vulnerabilities (KEV) Correlation Profile

Within the direct public-evidence tier, 22 CVE mentions and 12 distinct CVE identifiers were recorded. Two rows in that tier also carried a KEV signal. Table 12 summarizes the public CVE and KEV correlation profile.

Table 12. Public CVE and KEV correlation profile.

Metric	Result
Rows in direct-public-evidence tier	11
Total CVE mentions	22
Distinct CVE identifiers	12
Mean CVE mentions per direct-public-evidence row	2.00
Direct-public-evidence rows with KEV signal	2
Direct-public-evidence rows still needing version or scope confirmation	10

Direct public evidence coexisted with substantial unresolved applicability. KEV signals were rare, and most rows in this tier retained version or scope caveats. The table separates public vulnerability-record correlation from a confirmed match to the evaluated product version or certification scope.

4.7. Version and Scope Uncertainty

Version or scope caveats were frequently observable in the screening dataset. Overall, 32.56% of reviewed rows carried mapping or applicability gaps in the analyst notes. Table 13 reports caveat rates by evidence tier.

Table 13. Version or scope caveat rate by evidence tier.

Evidence Tier	Rows in Tier	Rows with Mapping Gap	Gap Rate (%)
Direct public evidence	11	10	90.91
Family-level vulnerability signal	8	1	12.50
Technology-class signal	12	0	0.00
Adjacent or historical signal	1	1	100.00
Context only	11	2	18.18

The highest caveat burden appeared in the direct public-traceability rows: 10 of the 11 direct public-evidence rows still carried a mapping gap. Across the screening dataset, public traceability and confirmed applicability remained separate descriptive states.

4.8. ATER Disclosure-Flowchart Calibration

The ATER disclosure-risk flowchart was calibrated over the 43 reviewed mapping rows used in the component-signal screening layer. Each evidence tier was routed to a conservative disclosure decision and public output form, and only the aggregate decision distribution was retained for the manuscript. Product-identifying and source-linked details remained restricted under the reporting boundary.

Table 14 reports the aggregate disclosure-flowchart calibration over the reviewed mapping rows.

Table 14. Aggregate ATER disclosure-flowchart calibration over the reviewed mapping rows.

Disclosure Decision	Evidence Tier	Rows	Public Output Form	Flowchart Terminal
Aggregate-only publication with caveat	Direct public evidence	11	Aggregate count with caveat	Restrict internal detail and publish aggregate signal
Abstracted publication with caveat	Family-level vulnerability signal	8	Anonymized correlation category	Publish abstracted category with limitation
Technology-class aggregate publication	Technology-class signal	12	Technology-class aggregate	Publish class-level aggregate
Abstracted publication with caveat	Adjacent or historical signal	1	Anonymized correlation category	Publish abstracted category with limitation
Minimal-context publication or omission	Context only	11	Context or appendix aggregate	Publish minimal context or omit

The calibration routed direct-evidence rows to the most restrictive public-output category and used less specific public forms for heuristic or contextual tiers. Across the 43 reviewed rows, the resulting distribution was 11 aggregate-only publications with caveats, 9 abstracted and caveated publications, 12 technology-class aggregate publications, and 11 minimal-context publications or omissions. These counts describe how the selected-set evidence tiers were routed into disclosure decisions. They do not establish product exposure, cross-organizational validity, or organizational risk reduction.

4.9. Pilot Consistency Check and AI-Output Source-Quality Review

A separate 12-document pilot subset, drawn from 4 certification packages, supported the screening workflow. The subset retained the planned balance across certificates, certification reports, and security targets, as well as the language distribution reported in Table 15. Across the subset, 71 evidence anchors were retained.

Table 15. Compact pilot consistency check and AI-output source-quality review summary.

Validation Dimension	Result
Documents in subset	12
Packages in subset	4
Certificate documents	4
Certification report documents	4
Security target documents	4
English-language documents	8
French-language documents	4
Retained evidence anchors in validation log	71
Second-coder check documents	12
Independent coders	2
Populated coder-level checks against adjudicated reference coding	222
Pre-adjudication agreement entries	218
Pre-adjudication non-matching entries	4
Descriptive agreement rate	98.20%
Review timing midpoint, workload metadata	72 min per coder
Timing range with 45% planning spread, workload metadata	40–104 min per coder
Document-task rows passing source-quality review	12 of 12
Hallucinated outputs	0
Corrected mislocated outputs	1
Over-generalized outputs	0
Missing mandatory fields	0
Unsupported claims	0

Note: The 222 coder-level checks comprise 111 comparisons per coder against the adjudicated reference coding. They do not represent 222 distinct document variables or pairwise coder–coder comparisons. Timing values are reported only as workload-planning metadata, not as validation outcomes or a manual-versus-AI benchmark.

The consistency check covered all 12 documents and used two independent coders. Each coder contributed 111 populated variable-level comparisons against the adjudicated reference coding, yielding $111\times 2=222$ populated coder-level checks. Of these checks, 218 matched before source-anchor adjudication and 4 did not, giving a descriptive agreement rate of $218/222=98.20\%$. The 4 non-matching entries were resolved through anchor review.

The pilot remained a compact workflow check rather than a formal reliability study. AI-output source-quality review was completed for all 12 documents, and all 12 passed document-level acceptance after source-anchor review. The retained validation counters recorded 0 hallucinated outputs, 1 corrected mislocated output, 0 over-generalized outputs, 0 missing mandatory fields, and 0 unsupported claims.

5. Discussion

This discussion interprets AI-Enabled Technical Exposure Risk (ATER) as a disclosure-review response to a concrete property of public certification records: once certification artifacts are grouped as packages, they become easier to compare, correlate, and reuse as aggregate technical evidence. The selected EUCC/Common Criteria corpus illustrates that problem through 86 documents grouped into 31 certification packages and a 43-row package-component or package-technology review. Candidate linkage appeared more often than isolated, low-context disclosure, indicating that the corpus’s analytical value lies less in any single document than in relations among certificates, certification reports, security targets, identifiers, scope statements, and technical descriptors. The disclosure-flowchart calibration extends that result into publication practice by connecting evidence tiers with aggregate, abstracted, caveated, restricted, or review-held output decisions. The validation layer identifies where source anchors, rechecks, and conservative adjudication were needed before aggregate interpretation. Within these boundaries, the study contributes a governance-oriented model for reviewing public technical detail before publication, without making product-specific vulnerability claims or treating ATER as a validated risk-reduction intervention.

5.1. Principal Interpretation

The package structure in the screened corpus points to the main interpretive result: when public certification artifacts are read as packages rather than as stand-alone files, they make a denser information surface visible than any single document suggests. In ATER terms, exposure does not arise from one disclosed statement alone. It emerges when public technical details, identifiers, boundaries, and metadata can be aggregated into security-relevant context. Common Criteria practice depends on security targets, protection profiles, security requirements, and evaluation logic intended to support assurance and trust [15,33]. EUCC builds on that foundation and adds a European implementation layer around accreditation, vulnerability management, and conformity-assessment practice [10,11,12,14].

Within that setting, this study connects certification-transparency research with exposure-governance concerns. The aggregate results show that public certification artifacts can be inventoried, grouped into packages, and screened for component-linked public signals while anonymity, source uncertainty, and scope caveats remain explicit. Because certification evidence increasingly supports machine-assisted retrieval and comparison, ATER adds a publication-review layer: it treats public certification detail as assurance evidence whose reuse value depends on aggregation context, evidence strength, and disclosure granularity.

5.2. Certification Transparency as an Information Surface

Prior Common Criteria research shows that public certification artifacts can be collected and analyzed as machine-processable security data, including through large-scale analysis of certified-product records, vulnerabilities, and certificate references [17,18]. That literature supports analysis beyond ordinary human reading, but does not by itself prove an EUCC-wide dual-use effect.

Here the corpus structure matters. The inventory contained 86 documents grouped into 31 certification packages, close to balanced across certificates, certification reports, and security targets. That composition made package-based analysis feasible. Analysts do not need one unusually detailed file if identifiers, component descriptions, certification boundaries, and metadata can be recombined across several documents in the same package. Because this screening pass did not score document types separately, the discussion does not claim that security target, certification report, or certificate documents are empirically richer than the others.

5.3. AI-Assisted Correlation

The validation results characterize AI-assisted analysis as a controlled correlation aid. Public certification artifacts contain repeated structures, component identifiers, package relationships, and evaluation-boundary language, so AI tools may support searching, summarizing, comparing, and reorganizing those public elements across documents [4]. Here, that capability supported aggregate component-signal statistics and disclosure-flowchart calibration, while source-anchor review determined whether candidate outputs could enter the analysis.

The source-quality checks define the practical standard for such use. All 12 AI-output source-quality rows passed only after source-anchor review, one mislocated output required correction, and adjudicated disagreements remained visible instead of being converted into a stronger reliability claim. These results position AI assistance as part of a governed review workflow: useful for organizing public evidence, but dependent on human source recovery, conservative adjudication, and explicit publication boundaries.

5.4. Aggregation-Aware Transparency Governance

The component-signal screening dataset provides the clearest basis for discussing ATER and aggregation-aware transparency governance. Across 43 reviewed package-component or package-technology rows, 11 reached the strongest public-traceability tier and 32 carried either direct or heuristic candidate linkage. The pattern persists when the denominator changes: 20 of 23 reviewed packages contained at least one direct-or-heuristic candidate linkage, and 7 of 9 reviewed manufacturers did so. These figures describe public traceability and candidate linkage only. They do not establish product compromise, exploit validation, or affected product versions.

Aggregation gives those counts their governance significance. A single certification document may contain only a modest component, interface, dependency, or evaluation-boundary detail, but recurring details across products and vendors form a machine-organizable governance surface. Repeated component names, boundary statements, and stable metadata fields make cross-package linkage easier than isolated reading would suggest. AI-assisted correlation could reorganize legitimate public disclosures into reusable component-level knowledge, although this paper does not show that AI performs that task faster or better than manual review.

The article therefore frames certification transparency as an assurance mechanism within a more searchable and aggregable information environment. Public information can support supplier review, hardening, procurement, conformity assessment, and defensive monitoring. ATER focuses on the resulting publication-review problem: high-detail component or boundary information may require different treatment when repeated across packages, product families, or registries than when read as an isolated assurance statement. That distinction helps governance processes preserve useful public evidence while calibrating abstraction, caveats, and restricted evidence handling.

The ATER disclosure-flowchart calibration gives that governance issue a publication-review form. In the 43-row calibration, direct public-evidence rows were routed to aggregate-only publication with caveats, family-level and adjacent-historical rows to abstracted and caveated publication, technology-class rows to class-level aggregate publication, and context-only rows to minimal contextual use or omission. This distribution supports a practical interpretation: the model preserves analytical utility through counts, evidence tiers, and disclosure decisions, while limiting unnecessary linkage by excluding product-identifying mappings, source-linked evidence, and row-level vulnerability details from public outputs.

Relationship Between ATER and Exposure Intelligence

ATER sits next to cyber threat intelligence (CTI), attack surface management (ASM), asset intelligence, and exposure management, but it addresses an earlier publication-governance decision point. CTI-oriented work structures threat reports, attack-technique descriptions, and related security narratives into entities and relationships for defensive use [19,20,21]. ATER instead asks how public or publication-bound technical disclosures should be represented when their aggregation may create linkable exposure-relevant context.

This distinction gives ATER a narrower and complementary role. It supports governance-oriented disclosure review by preserving analytical value through aggregation, abstraction, caveating, restricted evidence logs, or further review. Product-risk scoring, vulnerability applicability, attack-path modelling, operational exposure reduction, and routine measurement of deployed systems remain separate validation designs and operational disciplines.

5.5. Governance Implications

The screened sample does not support broad secrecy claims. Public certification artifacts and other public technical disclosures still support trust, procurement, accountability, and market transparency. The narrower AI-era governance question is whether publication workflows should review recurring high-detail signals for aggregation effects while preserving public assurance value. That step fits broader AI-governance work, which treats risk as emerging at boundaries between heterogeneous data sources, technical systems, human interpretation, and governance controls, not only from isolated technical artifacts [55,56].

In this dataset, that question attaches most clearly to recurring component identifiers, boundary statements, version or maintenance-lineage markers, and other package-linkable metadata. Some detail will remain necessary for reproducibility, certification accountability, and downstream assurance. If similar recurrence appears in larger registries or across additional product families, publishers may need to explain the disclosure rationale more explicitly or calibrate abstraction levels more carefully.

The ATER framing is relevant to publication-review questions in critical infrastructure protection, supply-chain security, cyber resilience, and hybrid threat analysis. In those settings, public technical disclosures can help authorized actors interpret disclosure context, candidate supplier and technology linkages, certification coverage, and scope caveats. The same disclosures may become useful to malicious actors when AI-assisted OSINT enables correlation across registries, procurement records, certification artifacts, and vendor documentation. The governance task is not to suppress public information by default, but to identify where recurring high-detail disclosures create aggregation effects that should be assessed, justified, abstracted, or held for further review.

The selected-set results support a bounded governance implication. If similar disclosure patterns recur across registries, firms, public procurement records, certification schemes, and product families, publication practice may benefit from an aggregation-aware review step. The issue is cumulative rather than document-specific. Individually legitimate disclosures can become reusable component-level knowledge when public artifacts are standardized, searchable, and processed with AI-assisted tools. Regulators and scheme operators should therefore separate what must be disclosed, how rigorously products are evaluated, how post-certification vulnerabilities are handled, and how downstream operators use public technical data. Related work on cybersecurity incident reporting makes a similar governance point: disclosure regimes can support both short-term threat detection and longer-term policy learning only when reporting obligations, response processes, and learning mechanisms are kept analytically distinct [57].

5.6. Limitations

Several limitations constrain the interpretation. The study analyzes public documentation and public-source correlation rather than product implementations, so its findings concern disclosure structure, candidate linkage, and aggregation context. The corpus was bounded by public availability at the 15 April 2026 cutover and by source-verifiable package linkage. The screened package-component rows therefore provide selected-set evidence rather than a representative statistical estimate of EU-wide prevalence. Version and scope caveats also remain important, especially inside the strongest public-traceability tier.

The analysis leaves several validation tasks for future work. It does not establish a finalized hierarchy across certificates, certification reports, and security targets. The supporting validation layer remains methodologically narrow: the independent-coder consistency check covered the 12-document subset, no formal coefficient was estimated, and the design was not large enough to establish mature inter-coder reliability. The selected-set screening also leaves comparative AI performance outside scope, including measured time gain, accuracy gain, and changes in required expertise. Finally, the ATER disclosure-flowchart model still requires cross-organizational, cross-domain, and longitudinal validation before stronger transfer or outcome claims can be made.

5.7. Future Research

Future research should deepen the empirical base before extending the model’s claims. A larger screening pass could complete corpus coding, compare document types directly, and use a stronger reliability design with independent reviewers. That work would clarify whether certificates, certification reports, and security targets contribute different kinds of aggregation-sensitive evidence, and whether reviewers apply ATER categories consistently.

The next validation step should also move beyond certification records. Procurement, regulatory, vendor, and infrastructure documentation provide useful comparison settings because they combine technical detail, legal status, and operational relevance. Cross-organizational case studies and longitudinal publication-review exercises could examine whether ATER is associated with different publication-review decisions over time while preserving its disclosure-review role. Comparative work with CTI, ASM, asset intelligence, and exposure-management practices would clarify where ATER adds publication-review value and where existing operational processes already address similar concerns. A controlled AI-versus-manual comparison remains appropriate only if the study objective expands from aggregation characterization to workflow evaluation.

6. Conclusions

This study shows that AI-Enabled Technical Exposure Risk (ATER) adds a practical governance layer to public technical disclosure: it turns aggregation-sensitive certification evidence into traceable publication-review decisions while preserving the assurance value of transparency. The selected EUCC/Common Criteria packages illustrate why that layer matters. When public certification artifacts are read as linked records rather than isolated files, they expose a structured analytical surface in which traceability signals, candidate technology linkages, version or scope uncertainty, and evaluation-boundary statements can be reviewed before public reuse.

The selected-set evidence supports that conclusion. The analysis organized 86 documents from 31 certification packages and screened 43 package-component or package-technology mapping rows. Within that screening layer, 32 of 43 reviewed rows carried either direct or heuristic signal, and 20 of 23 reviewed packages contained at least one such linkage. The ATER disclosure-flowchart calibration translated those patterns into publication-review outcomes that preserved aggregate analytical value while avoiding product-identifying mappings and row-level security interpretation. The validation layer showed that anchor-based review, independent-coder checking, and document-level source-quality review could identify and correct coding issues before final interpretation.

ATER therefore provides a concrete, empirically grounded disclosure-review model for certification transparency in an AI-assisted OSINT environment. It offers reviewers a structured basis for deciding when public technical detail should remain aggregate, require abstraction or caveating, stay in restricted evidence logs, or receive further expert review. The model remains deliberately bounded. It does not assess named products, infer product-specific vulnerabilities, validate operational exposure reduction, or establish cross-organizational performance. Future work should test whether independent reviewers can apply ATER consistently across additional settings and refine its governance value without turning it into a product-vulnerability or risk-scoring model.