Review Reports

Round 1

Reviewer 1 Report

Comments and Suggestions for Authors

-Please explain how study selection, charting, and coding were independently verified.
-Please define explicitly how the Strong, Moderate, and Limited evidence categories were assigned.
-Please provide a transparent evidence-to-architecture mapping showing how the reviewed sources support each of the seven proposed layers and the principal cross-layer failure modes, and clarify how the authors determined that particular functions warranted separate architectural layers.
Please distinguish more clearly between findings directly supported by the reviewed corpus and the authors’ proposed architectural synthesis.

Author Response

Response to Reviewer 1

Manuscript: Secure and Privacy-Aware Networked Architectures for Monitoring Dual-Use Items and Technologies: A Scoping Review

We thank the reviewer for the detailed suggestions. We revised the methods description, defined claim-level evidence-strength criteria, added an explicit evidence-to-architecture crosswalk and a boundary-failure matrix, and clarified which statements are direct source findings, comparative inferences, or original architectural design decisions. Our point-by-point responses follow.

Comment 1

Reviewer comment: Please explain how study selection, charting, and coding were independently verified.

Authors' response: During August 2026, E.M., D.-F.C. and M.G. each participated in source assessment and in checking co-authors' judgments. Independent verification operated as a separate source-level check by another team member before the decision was consolidated. For selection, a co-author re-examined the full text against the eligibility rules in Table S7, including architectural relevance, evidence suitability, source authority and version precedence. Differences were reconciled against the relevant passages; final inclusion decisions matched the 86-source inventory in Table S3. For charting, a co-author checked recorded attributes against the original document using the fields in Table S4 (entity, evidence object, assurance mechanism, trust assumptions, deployment context and claim scope). For coding, the authors checked one another's assignments of assurance function, evidence-strength category, lifecycle layer and failure mode against the source material and common definitions. Divergent readings were discussed and resolved before consolidating the synthesis. The procedure separated initial judgments, cross-author scrutiny and team reconciliation. An additional revision-stage check reconciled the 86 unique source identifiers with the claim and architecture mappings in Tables S8-S10. Section 2.2 and the account following Supplementary Table S4 describe this procedure; Section 4.2 summarizes its contribution to interpretive consistency.

Changes in the revised manuscript: Sections 2.2 and 4.2; Supplementary description after Table S4, supported by Tables S3-S4 and S7-S10; Author Contributions.

Comment 2

Reviewer comment: Please define explicitly how the Strong, Moderate, and Limited evidence categories were assigned.

Authors' response: We have defined Strong, Moderate, and Limited as claim-level categories, evaluated by directness of evidence, independence of primary evidential lines, source authority, and context. Strong is applied to normative or legal propositions directly specified within the remit of a definitive authoritative instrument, or to comparable empirical findings corroborated by independent primary lines. Moderate applies to direct empirical or documented operational observations under explicit platform or field constraints. Limited applies to indirect, provisional or extrapolated claims lacking corresponding direct validation. We also aligned the examples with these criteria: EPCIS and ISO 22095 are classified as Strong for the semantics of the models they define, while documented field investigations are used as Moderate, case-bounded operational evidence. The limitations of every illustrative inference are recorded in Supplementary Table S8.

Changes in the revised manuscript: Section 2.2; Supplementary Table S8; heading correction in Supplementary Table S3 ("Source type").

Comment 3

Reviewer comment: Please provide a transparent evidence-to-architecture mapping showing how the reviewed sources support each of the seven proposed layers and the principal cross-layer failure modes, and clarify how the authors determined that particular functions warranted separate architectural layers.

Authors' response: We have documented the source-to-architecture mapping and the rule used to distinguish the seven logical functions. The unit of separation is a distinct assurance question, evidence object, authority or trust assumption, and failure condition at the receiving interface. Supplementary Table S9 links each function to representative source evidence and the authors' rationale for its boundary; Supplementary Table S10 links the six adjacent interfaces and cross-cutting issues to source-defined guarantees, required downstream checks and inferred failures. Tables 1 and 3 summarize the technical objects and diagnostic consequences. We also tested the explanatory granularity against explicit nested alternatives in Section 3.4: five groups, (L1+L2), L3, (L4+L5), L6 and L7; and four groups, (L1+L2), L3, (L4+L5+L6) and L7. The five-group model hides a separate entity/credential check and a separate event/receipt check unless their internal evidence contracts remain visible. The four-group model additionally obscures the boundary between registered evidence and policy authorization. The worked input variants make the distinction traceable: V1 fails because transfer T9 is absent even though unrelated event F4 has a valid receipt (K4/K5), whereas V2 has a valid T9 receipt but conflicting recipient evidence (K6; Tables 7-8 and S11-S12). These are analytical comparisons of verification responsibility, not empirical proof that fewer deployed components cannot provide the same guarantees. The seven-layer composition and interface controls remain the authors' design synthesis; published sources support their constituent functions and stated assurance limits.

Changes in the revised manuscript: Sections 3.3 and 3.4, including the explicit five- and four-layer comparison; Tables 1 and 3; Figure 2 and its caption; Section 3.5, Tables 5 and 7-8; Supplementary Tables S9-S12.

Comment 4

Reviewer comment: Please distinguish more clearly between findings directly supported by the reviewed corpus and the authors' proposed architectural synthesis.

Authors' response: We now separate three evidentiary levels across the manuscript. The reviewed standards, implementations and field reports establish bounded claims about identity, measurement, event representation, registration, disclosure and verification within their stated assumptions. Comparing those claims exposes additional checks needed when evidence is used by a different function, such as a required-event match for a receipt or an independent recipient comparison before authorization; these checks are comparative inferences. The seven-layer partition, its interface contracts and the suggested governance and privacy controls are our proposed architectural synthesis. The revised Abstract and Introduction avoid implying that the reviewed sources establish a statistical concentration of attacks at interfaces; Section 3.3 explicitly treats such failures as defined scenarios rather than incident-rate findings. Section 3.4 identifies the partition as an analytical design decision, while the staged synthetic cases in Section 3.5 show the scope of the checks and distinguish a controlled logical demonstration from measured operational effectiveness. Tables 2 and S8 identify the claim-strength boundaries; Tables S9-S10 document the source-to-design chain.

Changes in the revised manuscript: Abstract and Introduction; Sections 2.2, 3.1-3.5, 4.2 and 5; Tables 1-3 and 7-8; Supplementary Tables S8-S12.

Reviewer 2 Report

Comments and Suggestions for Authors

The manuscript is a scoping review that synthesizes mechanisms for maintaining evidentiary continuity in dual-use item/technology monitoring. It is a well-organized, ambitiously cross-domain synthesis with genuine engineering content. The writing is dense but precise. The main concerns are about methodological transparency and clarifying what is genuinely novel synthesis versus recombination of existing modular standards.

1. The Author Contributions state that E.M. alone carried out selection, charting, and coding, with D.-F.C. and M.G. reviewing only the "comparative synthesis and claim scope". For a scoping review following JBI/PRISMA-ScR, dual independent screening is standard practice and directly affects reproducibility. This should either be corrected (if screening was in fact dual) or explicitly acknowledged as a limitation in Section 4.2, which currently discusses evidence-maturity limitations but not review-process limitations.
2. Table S6 gives exact, reproducible query strings for PubMed and IEEE Xplore only. The peer-reviewed literature route additionally draws on ACM, USENIX, Springer Nature, Elsevier, and MDPI "via publication or proceedings routes," and citation tracing is described only qualitatively. For the non-database routes, please report either the platform-specific query syntax used or, if searches were manual/citation-chaining only, say so explicitly rather than implying a comparable level of reproducibility to the two documented databases.
3. The manuscript cites the PRISMA-ScR guidance [52], but the supplementary package does not include the completed checklist, which is normally expected as a standalone supplementary item for a scoping review claiming PRISMA-ScR compliance.
4. The Methods promise that claims are calibrated by source type, evidential independence, and evidence-inference fit, but no claim in Section 3 is tagged with its calibration level, and there's no summary table showing the distribution. Thread this calibration through the Results explicitly (e.g., inline tags or a summary table).
5. RATS already separates Attester/Verifier/Relying Party; PROV already separates entities/activities/agents; SCITT already layers registration over attestation. The architecture's real contribution seems to be the explicit composition and boundary/failure-mode mapping across these existing separations (Table 1, Figure 3) rather than a new primitive. The authors must state more directly what would break if this specific seven-layer decomposition were replaced with, e.g., a four-layer or five-layer, to substantiate that the granularity chosen is load-bearing rather than expository.
6. The manuscript requires at least one illustrative trace of a real or realistic dual-use item through all seven layers showing where in a real transition a specific failure mode from Table 1/Figure 3 would actually manifest. Currently, the architecture is validated only by citation coverage, not by demonstration.
7. Several sentences are long with multiple embedded clauses. For readability, consider splitting them.
8. Figures 3 and 4 would be better presented as a table.
9. All abbreviations must be written in their full form at first occurrence.

Author Response

Response to Reviewer 2

Manuscript: Secure and Privacy-Aware Networked Architectures for Monitoring Dual-Use Items and Technologies: A Scoping Review

We thank the reviewer for the detailed assessment. We have revised the manuscript and supplementary materials accordingly. Our point-by-point responses follow.

Comment 1

The Author Contributions state that E.M. alone carried out selection, charting, and coding, with D.-F.C. and M.G. reviewing only the "comparative synthesis and claim scope". For a scoping review following JBI/PRISMA-ScR, dual independent screening is standard practice and directly affects reproducibility. This should either be corrected (if screening was in fact dual) or explicitly acknowledged as a limitation in Section 4.2, which currently discusses evidence-maturity limitations but not review-process limitations.

Response: The original Author Contributions understated D.-F.C.'s and M.G.'s participation. All three authors participated in selection, charting, coding and synthesis during August 2026. Section 2.2 describes co-author checking of recorded decisions against primary sources and shared criteria before team reconciliation. The reported documentation lacks paired initial eligibility decisions for all 120 candidates; therefore, fully duplicate-independent first-pass screening and inter-reviewer agreement cannot be reconstructed from those records. Section 4.2 now acknowledges this auditability limitation. Author Contributions and Supplementary Tables S3-S4 and S7-S10 document the collaborative workflow and evidence traceability.

Revisions: Sections 2.2 and 4.2; Author Contributions; Tables S3-S4 and S7-S10; PRISMA-ScR Item 20.

Comment 2

Table S6 gives exact, reproducible query strings for PubMed and IEEE Xplore only. The peer-reviewed literature route additionally draws on ACM, USENIX, Springer Nature, Elsevier, and MDPI "via publication or proceedings routes," and citation tracing is described only qualitatively. For the non-database routes, please report either the platform-specific query syntax used or, if searches were manual/citation-chaining only, say so explicitly rather than implying a comparable level of reproducibility to the two documented databases.

Response: We have distinguished reproducible database searches from manual source identification. Table S6 reports the retained PubMed and IEEE Xplore queries. For ACM, USENIX, Springer Nature, Elsevier and MDPI, sources were identified through manual examination of publication and proceedings pages and backward/forward citation tracing. No platform-specific Boolean query strings or route-level retrieval counts were retained for these five routes; therefore, we do not claim database-equivalent reproducibility. Section 2.2 and Table S5 state this distinction explicitly. Included sources were assessed against the same eligibility criteria (Table S7) and classified in Table S3.

Revisions: Section 2.2; Supplementary Tables S5-S6.

Comment 3

The manuscript cites the PRISMA-ScR guidance [24], but the supplementary package does not include the completed checklist, which is normally expected as a standalone supplementary item for a scoping review claiming PRISMA-ScR compliance.

Response: Supplementary File S1 now contains a standalone 22-item PRISMA-ScR checklist, including the optional items, with expanded reporting requirements and updated locations. It identifies partial reporting for the narrative abstract, protocol availability, exclusion reasons, individual-source results and funding of included sources (items 2, 5, 14, 17 and 22). It also documents the limitations of collaborative checking (items 9, 10 and 20) and distinguishes claim-level calibration from formal source appraisal (items 12 and 16).

Revisions: Supplementary File S1 (updated PRISMA-ScR checklist).

Comment 4

The Methods promise that claims are calibrated by source type, evidential independence, and evidence-inference fit, but no claim in Section 3 is tagged with its calibration level, and there's no summary table showing the distribution. Thread this calibration through the Results explicitly (e.g., inline tags or a summary table).

Response: We have calibrated ten focal propositions in Table 2 (four Strong, three Moderate, three Limited), with their inference boundaries specified in Supplementary Table S8. Strong covers directly defined authoritative role, format, event and receipt semantics within each source's scope; RFC 9334 is Informational, so the Strong rating concerns its role model rather than Standards Track status or field effectiveness. Moderate applies to bounded experimental and operational findings, and Limited to cross-mechanism inferences and unvalidated integration claims. Section 3.5 now distinguishes CAR's documented field evidence (Moderate) from retrospective layer mapping and the deterministic V0-V2 replay, which do not establish operational detection performance. The four/three/three distribution applies only to the ten appraised propositions in Table 2.

Revisions: Sections 2.2, 3.3-3.5 and Table 2; Supplementary Table S8.

Comment 5

RATS already separates Attester/Verifier/Relying Party; PROV already separates entities/activities/agents; SCITT already layers registration over attestation. The architecture's real contribution seems to be the explicit composition and boundary/failure-mode mapping across these existing separations (Table 1, Figure 3) rather than a new primitive. The authors must state more directly what would break if this specific seven-layer decomposition were replaced with, e.g., a four-layer or five-layer, to substantiate that the granularity chosen is load-bearing rather than expository.

Response: The contribution is a traceable integration of source-defined evidence functions and their distinct verification responsibilities, rather than a new security primitive. Section 3.4 now specifies and compares three coherent partitions. The seven-layer model keeps observation, identity, appraisal, custody events, registration, authorization and governance individually accountable. An explicit five-layer alternative groups (L1+L2), L3, (L4+L5), L6 and L7; this hides the entity/credential and event/receipt distinctions if the merged layers expose only an aggregate decision. An explicit four-layer alternative groups (L1+L2), L3, (L4+L5+L6) and L7; it additionally hides the boundary between a valid registration receipt and recipient authorization. The worked cases expose why these distinctions matter: V1 has a valid receipt for F4 but no required transfer T9 (K4/K5), whereas V2 has a valid T9 receipt but conflicting recipient evidence (K6; Tables 7-8). Fewer deployed services could retain all seven internal checks; our claim concerns diagnostic traceability and assignment of assurance responsibilities, not the necessity of exactly seven physical components. Supplementary Tables S9-S10 provide the evidence-to-layer and boundary-to-source mappings.

Revisions: Section 3.4 and the comparison of seven-, five- and four-layer logical groupings; Tables 3 and 7-8; Supplementary Tables S9-S12.

Comment 6

The manuscript requires at least one illustrative trace of a real or realistic dual-use item through all seven layers showing where in a real transition a specific failure mode from Table 1/Figure 3 would actually manifest. Currently, the architecture is validated only by citation coverage, not by demonstration.

Response: Section 3.5 now provides two complementary applications of the seven-layer analysis. First, Table 6 maps a documented Conflict Armament Research investigation of European-origin GNSS anti-interference modules recovered from weaponised UAVs in Myanmar [18] to all seven assurance functions, distinguishing evidence the published field account supports from technical attestation, registration and policy records that it does not report. Second, Tables 5 and 7 present a fully specified illustrative industrial-control-module trace with independent validation questions for L1-L7 and three alternative custody records governed by policy P3. The complete case V0 produces AUTHORIZE. In V1, an omitted signed transfer T9 fails K4/K5 despite a valid receipt for an unrelated firmware event F4; the result is HOLD. In V2, the T9 receipt is valid but an independent manifest names a different recipient, so K6 fails and the result is HOLD. Table 8 compares these outcomes across K1-K3, K1-K5 and K1-K6, revealing which extra evidence detects each mismatch; Supplementary Tables S11-S12 specify the inputs and rules for reproduction. The retrospective field mapping and deterministic worked trace show how the proposed controls would evaluate available evidence. They do not claim a deployed end-to-end system or measured detection performance.

Revisions: Section 3.5; Tables 5-8; corresponding interpretation in Section 4.1; Supplementary Tables S10-S12.

Comment 7

Several sentences are long with multiple embedded clauses. For readability, consider splitting them.

Response: We split four long sentences in Sections 3.1, 3.4 and 5 to clarify the RQ1 claims, V1/V2 outcomes, five-layer grouping and CAR/synthetic conclusions. Technical meaning and citations are retained. Earlier readability edits remain unchanged.

Revisions: Sections 1, 3.1, 3.4, 3.5, 4.1 and 5.

Comment 8

Figures 3 and 4 would be better presented as a table.

Response: We converted the content of the former Figures 3 and 4 into editable manuscript Tables 3 and 4. These tables retain the cross-layer boundary/failure/mitigation information and the domain-by-layer prioritization, respectively. The remaining privacy diagram has been renumbered Figure 3 to keep numbering sequential.

Revisions: Tables 3-4, Section 3.4; Figure 3, Section 4.1.

Comment 9

All abbreviations must be written in their full form at first occurrence.

Response: We expanded PROV, TPM, VRASED, C-FLAT, CAR and GNSS at first occurrence and defined C2PA in the Table 4 caption. Supplementary Tables S2-S5 now explain technical and institutional abbreviations; database query strings in Tables S5-S6 are unchanged. Existing first-use definitions, including PUF, were retained.

Revisions:  Introduction; Sections 3.1, 3.2 and 3.5; Table 4; Supplementary Tables S2-S5.

Reviewer 3 Report

Comments and Suggestions for Authors

Major revisions are required concerning following problems:

1. The proposed seven-layer lifecycle-control architecture is nowhere applied.
2. Most of the figures are not readable.
3. Conclusions should be rewritten. This section is full of fuzzy texts like this one: The contribution of the present work lies in the explicit integration of entity and observation, identity and trust anchors, attestation and evidence normalization, provenance and lifecycle events, registry and transparency, policy and verification, and governance feedback into one lifecycle model. NO, this contribution is not well discussed in previous sections. The word lifecycle is used 46 times in this manuscript, and almost everywhere in non-IT style. Presumably this is a result of rephrasing different standards and common sense documents far from the real dual use topics. Only once a cybersecurity and lifecycle are applied in one place. The authors didn't show an experience with cybersecurity projects.
4. Same remarks are valid for the term AI
5. There is no research evidence for many of the allegations like this one: Regarding RQ4, the review finds that recurrent constraints and failure modes concentrate at transitions between layers and domains, where evidence changes representation, authority, or temporal contex
6. Most of the considered resuts are trivial or incompletely described, like this one: Regarding RQ1, the analysis shows that identity binding is a lifecycle relation that must remain connected to enrollment, measured state, credentials, policy, and registration as the monitored entity changes over time.

Comments on the Quality of English Language

The style should be improved aiming to improve the impact

In many cases the style is so poor that it might be a result of a rapid work with a rephraser and/or other AI tool

In many places the text contains typos/errors, e,g,: EAT structures the claims that are exchanged [11]...

Author Response

Response to Reviewer 3

Manuscript: Secure and Privacy-Aware Networked Architectures for Monitoring Dual-Use Items and Technologies: A Scoping Review

Comment 1

Reviewer comment: The proposed seven-layer lifecycle-control architecture is nowhere applied.

Authors' response: We have expanded Section 3.5 to apply the proposed architecture to two complementary evidence sets. The first is a retrospective analysis of the 2025 Conflict Armament Research investigation of European-origin GNSS anti-interference modules documented in weaponised UAVs in Myanmar [18]. New Table 6 assesses each of the seven functions against the reported field evidence and distinguishes documented observations, end-use discrepancies and functions that cannot be verified from the published record. This application identifies a concrete monitoring consequence: the divergence between civil-use commitments and observed military integration supports an end-use review, while the record does not establish technical attestation or tamper-evident registration. The second application is a reproducible seven-layer decision trace for a controlled industrial module. New Table 7 and Supplementary Tables S11-S12 specify a complete synthetic input record, an event-specific verification policy and three variations: complete evidence (V0), an omitted transfer event (V1) and conflicting custodian records (V2). Their evaluated results are AUTHORIZE, HOLD and HOLD, respectively. The missing-event case demonstrates why a valid registry receipt for an unrelated statement cannot substitute for transfer evidence; the conflicting-recipient case shows how a correctly registered event may still fail the authorization check. The supplementary material states each input and predicate so the decision outcomes can be reproduced. We specify which findings are documented field observations and which are results from the deterministic synthetic replay. The revised Discussion relates these applications to the distinct assurance responsibilities of the seven layers.

Changes in the revised manuscript: Section 3.5 and Tables 5-7; related passage in Section 4.1; Supplementary Tables S11-S12 and their documented decision rule.

Comment 2

Reviewer comment: Most of the figures are not readable.

Authors' response: We replaced Figures 1-3 with high-resolution monochrome diagrams and larger labels. Figure 1 retains the documented source-selection counts and corpus composition. Figure 2 shows the seven-layer architecture, evidence and feedback paths, and cross-cutting properties. Figure 3 separates the six-stage disclosure workflow, retention strategy, residual privacy risks and safeguards into readable panels. Figure captions and substantive findings are preserved.

Changes in the revised manuscript: Figures 1–3 replaced with enlarged monochrome diagrams; figure captions retained.

Comment 3

Reviewer comment: Conclusions should be rewritten. This section is full of fuzzy texts like this one: The contribution of the present work lies in the explicit integration of entity and observation, identity and trust anchors, attestation and evidence normalization, provenance and lifecycle events, registry and transparency, policy and verification, and governance feedback into one lifecycle model. NO, this contribution is not well discussed in previous sections. The word lifecycle is used 46 times in this manuscript, and almost everywhere in non-IT style. Presumably this is a result of rephrasing different standards and common sense documents far from the real dual use topics. Only once a cybersecurity and lifecycle are applied in one place. The authors didn't show an experience with cybersecurity projects.

Authors' response: We revised the Introduction, Discussion and Conclusions to state three concrete outputs: the source-to-function mapping (Supplementary Table S9), six source-linked hand-off checks (Table 3; S10), and a seven/five/four-layer comparison (Section 3.4). Section 3.5 applies these checks to CAR's documented end-use discrepancy [18] and a controlled P3 trace. V1 fails K4/K5 because T9 is absent despite a valid F4 receipt; V2 fails K6 because valid T9 registration conflicts with recipient evidence (Tables 6-8; S11-S12). The replay identifies missing evidence under stipulated inputs; field detection, causes and operational effectiveness remain untested. We replaced broad 'lifecycle' phrases with custody, item-history and verification terms. The Conclusions report these results and limits.

Changes in the revised manuscript: Introduction; Sections 3.5, 4.1 and 5; targeted terminology. Evidence: Tables 3 and 6-8; Supplementary Tables S9-S12.

Comment 4

Reviewer comment: Same remarks are valid for the term AI

Authors' response: We have clarified that AI is a prospective application domain rather than a validated result. The Introduction limits AI artefacts to specific monitoring or control obligations. Table 4 now evaluates software supply-chain mechanisms without extending its ratings to AI; Section 3.4 separately discusses AI secure-development and misuse-risk guidance [65,66]. Section 4.2 explains that neither application in Section 3.5 tests model-version, training-data or runtime evidence.

Changes in the revised manuscript: Introduction; Section 3.4 and Table 4; Section 4.2.

Comment 5

Reviewer comment: There is no research evidence for many of the allegations like this one: Regarding RQ4, the review finds that recurrent constraints and failure modes concentrate at transitions between layers and domains, where evidence changes representation, authority, or temporal contex

Authors' response: We have developed RQ4 into a source-linked analysis of six distinct verification obligations at the architectural hand-offs. Each derives from the explicitly documented scope of an upstream mechanism and the evidence needed for a downstream decision. This replaces the previous general statement about the 'concentration' of failures with testable technical propositions. Section 3.3 now explains, for each hand-off, what the cited technical mechanism actually establishes and which additional evidence or decision predicate the next function needs. For example, RFC 9334 [8] separates evidence appraisal from relying-party authorization, EPCIS [4] defines event representation, SCITT [28] supplies statement-specific registration receipts, and RFC 9162 [19] defines inclusion and consistency proofs. Their specified guarantees make it possible to derive precise checks for target binding, freshness, event association, receipt-to-event correspondence, authorized recipient, and retrospective audit. We revised Tables 1 and 3 to identify the source basis, required check and diagnostic consequence of a failure; Supplementary Table S10 records the property-to-inference chain for each boundary. These propositions are further illustrated in Section 3.5: synthetic case V1 fails at K4/K5 because the only valid receipt concerns event F4 rather than the required transfer T9; case V2 fails at K6 because a valid T9 receipt is paired with a conflicting recipient manifest. The retrospective field investigation [18] supplies real-world evidence of an end-use discrepancy while identifying the technical records unavailable for an attestation or transparency assessment. We updated the Discussion and Conclusions to report these attributable, testable results rather than an unsupported prevalence claim.

Changes in the revised manuscript: Section 3.3; Tables 1 and 3; the evidence interpretation in Section 4.1; and the relevant Conclusions paragraphs. Supplementary Materials: cross-layer explanation and Table S10, aligned with the existing Tables S11-S12.

Comment 6

Reviewer comment: Most of the considered resuts are trivial or incompletely described, like this one: Regarding RQ1, the analysis shows that identity binding is a lifecycle relation that must remain connected to enrollment, measured state, credentials, policy, and registration as the monitored entity changes over time.

Authors' response: We have made the RQ1 result explicit through distinct evidence predicates and a reproducible comparison. We have revised Sections 3.1 and 3.2 around the independently checkable claims supplied by the reviewed mechanisms and the further predicates required by the proposed application. For RQ1, the cited item-identification and PUF mechanisms establish bounded entity association [3,5,14,25], whereas RATS/EAT, TPM-based evidence and attestation implementations address state and appraisal under different assumptions [8,9,26,29,30]. Authorization remains an additional relying-party decision [8,27]. The revised text states the resulting entity, state, event and policy references that must be retained across the interfaces, and explicitly distinguishes reported mechanism properties from design inferences. For RQ2, we distinguish the existence of a required EPCIS/PROV-style custody event [4,21], registration of the exact signed statement under SCITT [28] and recipient consistency under the declared policy P3. The three fully specified input variants permit a reproducible staged comparison in new Table 8, calculated directly from Supplementary Tables S11-S12: K1-K3 pass in V0, V1 and V2; K4-K5 distinguish missing transfer T9 in V1 despite the valid unrelated F4 receipt; and K6 distinguishes the conflicting manifest in V2 despite a valid T9 receipt. The final outcomes remain AUTHORIZE, HOLD and HOLD, with evidence and exception records preserved under K7. Section 3.2 also clarifies the distinct technical scopes of selective disclosure [10], authorization [27] and retained audit evidence as a proposed privacy design, without claiming to have implemented or benchmarked it. We updated the Discussion and the related Conclusions references. The comparison is a deterministic result on constructed cases; field detection rates, statistical significance and end-to-end system effectiveness are outside the evidence reported in this review. The source-to-architecture traceability and evidence grades in Tables 1-3 and S8-S10 remain applicable, consistent with Reviewer 1's and Reviewer 2's requests.

Changes in the revised manuscript: Sections 3.1, 3.2 and 3.5; new Table 8 (staged predicate comparison); Section 4.1 and corresponding Conclusions references. Supplementary Materials: interpretation of Table S12 and its link to the staged comparison.

Round 2

Reviewer 1 Report

Comments and Suggestions for Authors

The answers addresses reviewer concerns, and the corresponding revisions are visible in the revised manuscript. The manuscript now provides explicit claim-level evidence-strength rules, separates source-supported findings from comparative inference and author-designed architecture. 

Author Response

Authors’ response:

We thank the reviewer for their positive assessment and for acknowledging that the revisions adequately address the previous concerns. We appreciate the reviewer’s recognition of the clarified claim-level evidence-strength criteria and the explicit distinction between source-supported findings, comparative inferences, and our proposed architectural synthesis.

Reviewer 2 Report

Comments and Suggestions for Authors

The authors have addressed the concerns, and the manuscript is ready for publication.

Author Response

Authors’ response:

We thank the reviewer for their positive assessment and for confirming that the previous concerns have been adequately addressed. We appreciate the reviewer’s recommendation that the manuscript is ready for publication.

Reviewer 3 Report

Comments and Suggestions for Authors

This manuscript is significantly improved. Few more comments are written aiming at better impact:

1. Typos are found like whichillustrate. Please proofread this text again.
2. Everything concerning AI applications is not concrete. It is written generally as AI like in company ads.
3. Conclusions describe what is done and not the advantage of the manuscript. This should be improved.
4. The original and foreign results are mixed in one place. This diminishes the overall esmination of the proposed architecture and its applications.

Author Response

Response to Reviewer 3

Manuscript: Secure and Privacy-Aware Networked Architectures for Monitoring Dual-Use Items and Technologies: A Scoping Review

Comment 1

Reviewer comment: Typos are found like whichillustrate. Please proofread this text again.

Authors' response: We thank the reviewer for this observation. We have carefully proofread the revised manuscript and the Supplementary Materials, correcting typographical and grammatical errors, duplicated wording, punctuation, and inconsistencies in terminology. We also checked and harmonized reference numbering between the main manuscript and the supplementary tables. These editorial revisions improve clarity and consistency throughout the documents.

Changes in the revised manuscript: Editorial and terminological corrections throughout the main manuscript and Supplementary Materials, including the tables; reference numbering synchronized across both documents.

Comment 2

Reviewer comment: Everything concerning AI applications is not concrete. It is written generally as AI like in company ads.

Authors' response: We thank the reviewer for identifying the need for a more technically specific treatment of AI applications. We expanded the corpus with four peer-reviewed conference publications [89–92] addressing malicious code in model hubs (MalHug), cryptographically linked checkpoint provenance and transparency records (Atlas), hardware-assisted attestations of training and inference properties (Laminator), and model signing and dataset-property claims. The revised analysis identifies the corresponding evidence objects and verification checks: checkpoint hashes, attested execution context, fine-tuning and dataset lineage, signed provenance statements, registry receipts, and recipient-specific release decisions. In Section 3.5, the new Application C maps these published mechanisms to the seven-layer architecture and examines concrete illustrative failure cases involving malicious model-loading code and a missing link between a released checkpoint and attested training. The revised evidence-to-architecture mapping distinguishes results reported by the cited studies from cross-layer verification obligations proposed by the authors.

Changes in the revised manuscript: Abstract and Introduction; Sections 2.1–2.2, 3.4–3.5 and 4.2; Figure 1; Table 4; References [89–92]; Supplementary Tables S1–S5 and S8–S10.

Comment 3

Reviewer comment: Conclusions describe what is done and not the advantage of the manuscript. This should be improved.

Authors' response: We thank the reviewer for this observation. We have rewritten Section 5 to clarify the scientific contribution and the advantages of the proposed seven-layer architecture. The Conclusions now explain how source-traceable evidence contracts and checks at six architectural hand-offs expose gaps between otherwise valid identity, attestation, provenance, registration and authorization claims. The custody-based applications demonstrate this diagnostic value through distinct HOLD conditions and the evidence needed to resolve them. The AI-model comparison extends the same analysis to checkpoint lineage, attested model properties and release decisions. The revised Conclusions emphasize decision reconstruction and informative audit trails, with each contribution grounded in the reported evidence.

Changes in the revised manuscript: Section 5 (Conclusions), three paragraphs revised to emphasize diagnostic specificity, cross-layer evidence continuity, decision reconstruction and applicability to AI-model provenance.

Comment 4

Reviewer comment: The original and foreign results are mixed.

Authors' response: We have clarified the provenance of the findings in the evidence synthesis and application tables. Source-reported mechanism properties, implementation measurements and field observations remain attributed to the published works, while the seven-layer mapping, interface checks and cross-source interpretations are identified as the authors' analytical contributions. In Section 3.5, the retrospective CAR assessment, the synthetic custody-policy replay and the AI-model comparison have distinct evidence bases. Table 3 identifies author-proposed checks and illustrative outcomes; Tables 6–8 identify the authors' retrospective mapping and calculated policy decisions. Supplementary Table S2 distinguishes published measurements from calculations and deployment-control proposals, and Table S3 labels the lifecycle assignments as the authors' classification. This makes the origin of each type of finding explicit without changing the underlying scientific claims.

Changes in the revised manuscript: Sections 3.3–3.5; Tables 3 and 6–8; Supplementary Tables S2–S3 and the accompanying table note.