IDEHA Trust Framework

IDEHA-IG-GOV-FRM-001: Framework Instrument Development, Validation and Controlled Publication

IDEHA-IG-GOV-SCH-001 Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the preparation, validation, adoption readiness and controlled publication of Framework Instruments established under the Trust Framework.

2. This Guideline applies to Responsible Actors preparing Framework Instruments assigned to them under the applicable Framework provisions.

3. This Guideline establishes requirements for:

1. preparation of Framework Instrument development records;

2. allocation of requirements to the appropriate Framework Instrument;

3. validation of normative content;

4. identification of dependencies and references;

5. preparation of publication information;

6. maintenance of historical development records.

4. This Guideline does not:

1. establish Framework Instrument categories;

2. establish Decision Competence;

3. assign Instrument Status;

4. create Controlled Effects;

5. establish Trust Service Categories or Trust Object Categories;

6. replace requirements established by the Main Framework or Annexes.

Framework Instrument development basis

Article 2

1. A Responsible Actor shall prepare a Framework Instrument only where an enabling provision permits or requires its development.

2. Before preparing a Framework Instrument, the Responsible Actor shall establish a development basis.

3. The development basis shall identify:

1. the enabling Framework provision;

2. the Framework Instrument category;

3. the intended subject matter;

4. the responsible drafting Actor;

5. the affected Framework Instruments;

6. the applicable Controlled Terms;

7. the applicable Recognised Standards, where relevant.

Article 3

1. The Responsible Actor shall maintain a requirement allocation record during the preparation of a Framework Instrument.

2. The requirement allocation record shall identify:

1. each requirement included in the draft;

2. the normative basis for the requirement;

3. the Framework Instrument responsible for the requirement;

4. dependencies on other Framework Instruments;

5. applicable Profiles and Technical Specifications.

3. A requirement shall not be included in a Framework Instrument where its normative ownership belongs to another Framework Instrument.

Normative content and allocation

Article 4

1. A Framework Instrument shall contain only requirements necessary for the implementation of its assigned subject matter.

2. A Framework Instrument shall not repeat requirements already established by:

1. the Main Framework;

2. Annexes;

3. another Framework Instrument.

3. Where a requirement is established by another Framework Instrument, the draft shall reference that requirement and specify only the additional implementation conditions necessary for its application.

Article 5

1. The Responsible Actor shall ensure that the draft Framework Instrument remains within its assigned scope.

2. The Responsible Actor shall verify that the draft does not:

1. introduce a new category of Actor;

2. introduce a new Trust Service Category;

3. introduce a new Trust Object Category;

4. establish a new Status;

5. establish a new Qualified Status;

6. modify Controlled Effects;

7. assign Decision Competence.

3. Where the implementation of a requirement requires a new category, Status, Controlled Effect or Decision Competence, the matter shall be addressed through the applicable Main Framework amendment route.

Controlled Terms and references

Article 6

1. A Framework Instrument shall use Controlled Terms established by the Trust Framework.

2. A Framework Instrument shall not introduce a new capitalised term where an applicable Controlled Term already exists.

3. Where a new term is required for implementation purposes, the Responsible Actor shall determine whether:

1. the term is an implementation expression limited to that Framework Instrument; or

2. the term requires inclusion in the Controlled Terms through the applicable amendment process.

Article 7

1. A Framework Instrument shall identify dependencies on:

1. Main Framework provisions;

2. Annexes;

3. other Framework Instruments;

4. Profiles;

5. Technical Specifications;

6. Recognised Standards.

2. References shall identify the applicable scope and Version where required.

3. A reference to another Framework Instrument shall not incorporate requirements outside the identified scope.

Draft validation

Article 8

1. Before submission through the applicable adoption route, the Responsible Actor shall validate the draft Framework Instrument.

2. The validation shall confirm that:

1. the draft remains within its enabling provision;

2. the requirements are allocated to the correct normative layer;

3. Controlled Terms are used consistently;

4. dependencies are identified;

5. referenced standards are identified;

6. technical detail is assigned to Technical Specifications where required.

Article 9

1. The Responsible Actor shall perform a duplication assessment before submission.

2. The duplication assessment shall consider:

1. duplication with the Main Framework;

2. duplication with Annexes;

3. duplication with other Framework Instruments;

4. duplication of horizontal controls;

5. duplication of technical requirements.

3. Where duplication is identified, the Responsible Actor shall:

1. remove the duplicated requirement; or

2. retain only the implementation condition necessary for applying the existing requirement.

Standards and technical boundary

Article 10

1. Where a Framework Instrument requires the application of Recognised Standards, those standards shall be identified in accordance with the applicable standards-management requirements.

2. The standards reference shall identify:

1. issuing organisation;

2. reference identifier;

3. title;

4. applicable edition or Version;

5. implementation purpose;

6. applicable scope;

7. approved adaptations or exclusions.

Article 11

1. A Framework Instrument shall not contain:

1. technical schemas;

2. message structures;

3. protocol definitions;

4. algorithm specifications;

5. cryptographic parameters;

6. interface definitions;

7. test vectors;

8. deployment configurations.

2. The matters referred to in paragraph 1 shall be established through Technical Specifications where required.

Publication and lifecycle records

Article 12

1. The Responsible Actor shall prepare the information required for controlled publication following adoption of a Framework Instrument.

2. The publication information shall include:

1. Instrument Identifier;

2. title;

3. Version;

4. Effective Date;

5. applicable Annexes;

6. applicable references.

Article 13

1. The Responsible Actor shall maintain records demonstrating the preparation and validation of a Framework Instrument.

2. The records shall include:

1. development basis;

2. requirement allocation record;

3. duplication assessment;

4. validation results;

5. dependency assessment;

6. standards assessment;

7. draft Versions;

8. publication information.

Article 14

1. Changes to a Framework Instrument shall be implemented through the applicable Change Control process.

2. The Responsible Actor shall maintain records identifying:

1. the changed Framework Instrument;

2. the new Version;

3. affected dependencies;

4. affected Standards;

5. transition conditions.

3. Previous Versions shall remain identifiable for Historical State purposes.

Applicable standards

Article 15

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission;

5. Controlled Reliance.

Annex I

Applicable standards

Reference	Application
ISO 15489-1:2016	Records management principles applicable to Framework Instrument development and lifecycle records
ISO 23081-1:2017	Metadata principles applicable to Framework Instrument lifecycle information
ISO 8601-1:2019	Date and time representation for Framework Instrument metadata

IDEHA-IG-GOV-SCH-001: Scheme Development and Operations

IDEHA-IG-GOV-SCH-001

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the establishment, operation, modification and closure of Schemes under the Trust Framework.

2. This Guideline applies to Responsible Actors assigned responsibility for preparing or operating a Scheme.

3. This Guideline shall apply within the scope established by the applicable Framework provisions.

4. This Guideline does not:

1. establish Trust Service Categories;

2. establish Trust Object Categories;

3. assign Status or Qualified Status;

4. establish Decision Competence;

5. create Controlled Effects;

6. replace requirements established by the Main Framework, Annexes or other Framework Instruments.

Scheme establishment

Article 2

1. A Responsible Actor preparing a Scheme shall establish a Scheme development record before submitting the Scheme for approval.

2. The Scheme development record shall contain:

1. the Scheme identifier;

2. the enabling Framework provision;

3. the intended purpose and governed context;

4. the participating Actors;

5. the applicable Trust Services, Trust Objects or Sources;

6. the applicable Profiles and Technical Specifications;

7. the applicable Reliance Conditions;

8. the applicable safeguards and limitations.

Article 3

1. A Scheme shall define its operational scope.

2. The Scheme scope shall identify:

1. the governed purpose;

2. the participating Actors;

3. the applicable Federation Domains;

4. the applicable Trust Services, Trust Objects or Sources;

5. the permitted reliance context;

6. applicable limitations.

3. A Scheme shall not extend the scope or effect of a Trust Service, Trust Object or Source beyond the conditions established by the applicable Framework Instruments.

Scheme governance

Article 4

1. The Responsible Actor shall establish governance arrangements necessary for operation of the Scheme.

2. The governance arrangements shall identify:

1. responsible governance functions;

2. operational responsibilities;

3. participation responsibilities;

4. monitoring responsibilities;

5. review responsibilities.

3. The governance arrangements shall remain within the Decision Competence and responsibility allocation established by the Trust Framework.

Participation and operational conditions

Article 5

1. Participation in a Scheme shall be recorded and maintained by the Responsible Actor.

2. The participation record shall identify:

1. participating Actor;

2. assigned Role where applicable;

3. participation scope;

4. effective date;

5. restrictions or limitations.

3. Participation in a Scheme shall not by itself establish:

1. Trust Service Status;

2. Qualified Trust Service Status;

3. Qualified Trust Object Status;

4. Authorisation;

5. Controlled Reliance.

Article 6

1. A Scheme may identify implementation conditions applicable within its scope.

2. Those conditions may include:

1. applicable Profiles;

2. applicable Technical Specifications;

3. applicable Recognised Standards;

4. applicable Assurance Conditions;

5. applicable Security Conditions;

6. applicable Accessibility Conditions.

3. A Scheme shall not redefine requirements established by the Main Framework or Annexes.

Scheme operation and monitoring

Article 7

1. The Responsible Actor shall maintain operational information necessary for Scheme operation.

2. Operational information shall include:

1. current Version;

2. applicable Profiles;

3. applicable Technical Specifications;

4. participating Actors;

5. operational dependencies;

6. applicable restrictions.

3. The Responsible Actor shall ensure that operational information remains consistent with the authoritative Framework Instruments.

Article 8

1. The Responsible Actor shall monitor whether the Scheme continues to operate within its approved scope.

2. Monitoring shall consider:

1. changes affecting participating Actors;

2. changes affecting Trust Services, Trust Objects or Sources;

3. changes affecting Profiles or Technical Specifications;

4. changes affecting Security Conditions;

5. changes affecting Protected-Person Safeguards;

6. changes affecting Reliance Conditions.

Scheme modification and closure

Article 9

1. A proposed modification to a Scheme shall be assessed before implementation.

2. The assessment shall identify:

1. affected Framework Instruments;

2. affected participating Actors;

3. affected Trust Services, Trust Objects or Sources;

4. affected Profiles;

5. affected Technical Specifications;

6. transition requirements.

Article 10

1. Where a Scheme no longer operates within its approved scope, the Responsible Actor shall implement corrective measures.

2. Corrective measures may include:

1. modification of operational conditions;

2. restriction of Scheme scope;

3. temporary Suspension;

4. closure of the Scheme.

3. Closure shall identify:

1. effective closure date;

2. affected Actors;

3. affected Trust Services, Trust Objects or Sources;

4. transition arrangements;

5. records retention requirements.

Records and evidence

Article 11

1. The Responsible Actor shall maintain records demonstrating:

1. Scheme establishment;

2. governance arrangements;

3. participation decisions;

4. operational changes;

5. monitoring activities;

6. Reviews;

7. closure activities.

2. Records shall enable reconstruction of the Scheme lifecycle.

Applicable standards

Article 12

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only within the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create Status, Qualified Status, Controlled Effects or Decision Competence.

Annex I

Applicable standards

Reference	Application
ISO/IEC 24760-2	Identity-management architecture considerations where a Scheme includes identity-related functions
ISO/IEC 29146	Access-management architecture considerations where a Scheme includes controlled access arrangements
ISO/IEC 27001	Security-management controls applicable to Scheme operation
ISO/IEC 27701	Privacy-management controls where personal data processing is performed within the Scheme

IDEHA-IG-GOV-PRF-001: Profile Development and Controlled Selection Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the preparation, selection, validation, publication and maintenance of Profiles established under the Trust Framework.

2. This Guideline applies to Responsible Actors preparing or maintaining Profiles assigned to them under the applicable Framework provisions.

3. This Guideline establishes requirements for:

1. identifying the implementation context for a Profile;

2. selecting applicable requirements, options and conditions;

3. defining dependencies on Framework Instruments;

4. validating Profile consistency;

5. maintaining Profile lifecycle information.

4. This Guideline does not:

1. establish new Trust Service Categories;

2. establish new Trust Object Categories;

3. assign Status or Qualified Status;

4. create Controlled Effects;

5. modify requirements established by the Main Framework or Annexes;

6. replace Technical Specifications.

Profile development basis

Article 2

1. A Responsible Actor shall prepare a Profile only where an enabling provision permits or requires the selection of implementation requirements.

2. Before preparing a Profile, the Responsible Actor shall establish a Profile development basis.

3. The Profile development basis shall identify:

1. the enabling Framework provision;

2. the subject matter to which the Profile applies;

3. the applicable Framework Instrument;

4. the intended implementation context;

5. the responsible drafting Actor;

6. the applicable Trust Services, Trust Objects, Sources or other Controlled Matters.

Article 3

1. The Responsible Actor shall identify the purpose of the Profile.

2. The purpose shall specify:

1. the implementation context;

2. the applicable Actors;

3. the applicable Trust Services, Trust Objects or Sources;

4. the intended Assurance Conditions;

5. the applicable Reliance Conditions.

3. A Profile shall not expand the purpose or scope established by the enabling Framework provision.

Selection of requirements

Article 4

1. A Profile shall identify the requirements selected for its applicable implementation context.

2. A Profile may select:

1. optional requirements;

2. implementation classes;

3. Assurance Conditions;

4. Security Conditions;

5. Accessibility Conditions;

6. lifecycle conditions;

7. technical implementation options.

3. A Profile shall identify the source Framework Instrument for each selected requirement.

Article 5

1. The Responsible Actor shall ensure that selected requirements remain consistent with:

1. the Main Framework;

2. applicable Annexes;

3. applicable Implementation Guidelines;

4. applicable Technical Specifications.

2. A Profile shall not:

1. remove mandatory requirements;

2. reduce applicable Security Conditions;

3. remove Protected-Person Safeguards;

4. alter Status requirements;

5. change Decision Competence.

Profile content

Article 6

1. A Profile shall specify the implementation conditions applicable within its scope.

2. The Profile shall identify, where applicable:

1. applicable Trust Service or Trust Object category;

2. applicable Actors;

3. applicable Source categories;

4. applicable Assurance Conditions;

5. applicable Security Conditions;

6. applicable Accessibility Conditions;

7. applicable Validation requirements;

8. applicable lifecycle conditions.

3. The Profile shall identify requirements that remain subject to a Technical Specification.

Article 7

1. A Profile shall identify dependencies on:

1. Framework Instruments;

2. other Profiles;

3. Technical Specifications;

4. Recognised Standards.

2. Dependencies shall identify:

1. the dependent instrument;

2. the applicable scope;

3. the applicable Version;

4. the effect of the dependency.

Article 8

1. Where a Profile requires technical implementation choices, those choices shall be defined through the applicable Technical Specification.

2. A Profile shall identify the Technical Specification required for:

1. data structures;

2. formats;

3. protocols;

4. interfaces;

5. algorithms;

6. parameters;

7. testing requirements.

3. A Profile shall not contain detailed technical requirements assigned to a Technical Specification.

Assurance and qualification conditions

Article 9

1. Where a Profile specifies Assurance Conditions, it shall identify:

1. the applicable Assurance Domains;

2. the applicable Assurance Levels;

3. the required evidence;

4. the assessment conditions.

2. Where a Profile applies to Qualified Trust Services or Qualified Trust Objects, it shall identify the qualified conditions established by the applicable Framework provisions.

3. A Profile shall not establish Qualified Status.

Article 10

1. A Profile requiring Conformity Assessment shall identify:

1. the subject of assessment;

2. the applicable requirements;

3. the required evidence;

4. the assessment scope.

2. A Profile shall not determine the outcome of a Conformity Assessment.

3. A Profile shall not assign Qualified Status or another Status.

Validation and publication

Article 11

1. Before publication, the Responsible Actor shall validate the Profile.

2. The validation shall confirm that:

1. the Profile remains within its enabling provision;

2. selected requirements are complete;

3. dependencies are identified;

4. terminology is consistent;

5. no higher-ranking requirement is modified;

6. no technical requirement has been incorrectly allocated.

Article 12

1. The Responsible Actor shall maintain records demonstrating:

1. Profile development;

2. requirement selection;

3. dependency analysis;

4. validation results;

5. consultation where applicable;

6. Version history.

Profile lifecycle

Article 13

1. Changes to a Profile shall be assessed before implementation.

2. The assessment shall identify:

1. affected Framework Instruments;

2. affected Technical Specifications;

3. affected Recognised Standards;

4. affected implementations;

5. transition requirements.

3. Previous Profile Versions shall remain identifiable for Historical State purposes.

Article 14

1. A Profile may be restricted, withdrawn or replaced where:

1. requirements are no longer applicable;

2. dependencies have changed;

3. security conditions require modification;

4. transition to a replacement Profile is completed.

2. Restriction, withdrawal or replacement shall not modify Status already established under the applicable Framework provisions unless determined through the applicable Decision Competence.

Applicable standards

Article 15

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission;

5. Controlled Reliance.

Annex I

Applicable standards

Reference	Application
ISO/IEC 24760-2:2025	Identity-management architecture considerations where Profiles select identity-related implementation conditions
ISO/IEC 29146:2024	Access-management architecture considerations where Profiles select access-control conditions
ISO/IEC 27001:2022	Security-management controls applicable to Profile governance where required
ISO/IEC 27701:2025	Privacy-management controls where Profiles include personal-data processing conditions

IDEHA-IG-GOV-STD-001: Standards Selection and Technical Reference Management Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the evaluation, selection, registration, maintenance and transition of Recognised Standards and technical references used within the Trust Framework.

2. This Guideline applies to Responsible Actors performing standards-management functions assigned under the applicable Framework provisions.

3. This Guideline establishes requirements for:

1. assessment of proposed standards and technical references;

2. recording of recognised standards;

3. identification of applicable editions and Versions;

4. management of dependencies, adaptations and exclusions;

5. transition between standards;

6. maintenance of standards lifecycle information.

4. This Guideline does not:

1. create technical requirements for Trust Services, Trust Objects or Sources;

2. replace subject-specific requirements established by other Implementation Guidelines;

3. define technical specifications, protocols, schemas, algorithms or parameters;

4. create Status, Qualified Status or Controlled Effects through recognition of a standard.

Standards evaluation basis

Article 2

1. A Responsible Actor proposing a standard or technical reference for recognition shall establish a standards evaluation record.

2. The standards evaluation record shall identify:

1. the proposed standard or technical reference;

2. the issuing organisation;

3. the intended implementation function;

4. the applicable Framework Instrument;

5. the responsible evaluation Actor;

6. the affected Trust Services, Trust Objects, Sources or other Controlled Matters.

Article 3

1. The evaluation of a proposed standard shall consider:

1. suitability for the intended implementation purpose;

2. technical maturity;

3. security characteristics;

4. interoperability considerations;

5. lifecycle management arrangements;

6. compatibility with applicable Framework requirements;

7. availability of conformity evidence.

2. The evaluation shall identify whether the standard is:

1. mandatory;

2. conditionally applicable;

3. an approved option;

4. informative.

Standards reference management

Article 4

1. A Recognised Standard shall be recorded with sufficient information to identify its identity and applicability.

2. The standards record shall contain:

1. issuing organisation;

2. standard identifier;

3. title;

4. edition or Version;

5. publication date where relevant;

6. implementation purpose;

7. applicable Framework Instrument;

8. applicable scope;

9. dependencies;

10. transition information.

Article 5

1. Where only part of a standard applies, the applicable scope shall be identified.

2. The standards record shall identify, where applicable:

1. applicable clauses;

2. applicable annexes;

3. applicable profiles;

4. applicable conformance classes;

5. applicable policy requirements;

6. applicable implementation options.

3. A general reference to a standards family shall not establish an implementation requirement.

Article 6

1. Where a Recognised Standard requires adaptation for use within the Trust Framework, the adaptation shall be recorded.

2. The adaptation record shall identify:

1. the affected standard provision;

2. the reason for the adaptation;

3. the applicable Framework requirement;

4. the resulting implementation condition;

5. the responsible approval function.

3. An adaptation shall not modify the scope or Controlled Effects established by the Main Framework.

Standards dependencies

Article 7

1. A Recognised Standard shall identify normative dependencies necessary for its implementation.

2. The dependency record shall identify:

1. the dependent standard;

2. the dependency purpose;

3. the applicable Version;

4. the effect of dependency failure.

3. A dependency shall not be interpreted as creating automatic applicability outside the identified implementation scope.

Article 8

1. Where multiple Recognised Standards apply to the same implementation function, the Responsible Actor shall identify their relationship.

2. The relationship shall specify:

1. primary standard;

2. supporting standards;

3. optional standards;

4. superseded standards;

5. incompatible standards where applicable.

Standards lifecycle management

Article 9

1. The Responsible Actor shall monitor Recognised Standards for:

1. new editions;

2. security concerns;

3. technical obsolescence;

4. interoperability impacts;

5. withdrawal or replacement.

2. Monitoring results shall be recorded in the standards lifecycle record.

Article 10

1. A new edition or Version of a standard shall not automatically replace an existing Recognised Standard.

2. Before adoption of a replacement Version, the Responsible Actor shall assess:

1. changes in requirements;

2. security impacts;

3. implementation impacts;

4. conformity impacts;

5. transition requirements.

Article 11

1. Where a Recognised Standard is replaced, the transition decision shall identify:

1. the previous standard;

2. the replacement standard;

3. the effective date;

4. the transition period;

5. coexistence conditions;

6. affected Framework Instruments;

7. affected Technical Specifications.

2. The previous standard shall remain identifiable for Historical State purposes.

Standards application

Article 12

1. A subject-specific Framework Instrument applying a Recognised Standard shall identify:

1. the Recognised Standard;

2. the applicable implementation function;

3. the applicable scope;

4. the required conformity evidence.

2. A Recognised Standard shall apply only within the scope identified by the applicable Framework Instrument.

3. Recognition of a standard shall not by itself establish:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission;

5. Authorisation;

6. Controlled Reliance.

Article 13

1. Where a Recognised Standard defines conformity requirements, the applicable Framework Instrument shall identify the required conformity evidence.

2. Conformity evidence may include:

1. certification;

2. assessment reports;

3. testing evidence;

4. declarations;

5. implementation records.

3. The existence of conformity evidence shall not replace any required Framework Decision or Status determination.

Records and publication

Article 14

1. The Responsible Actor shall maintain the Standards Register.

2. The Standards Register shall contain:

1. recognised standards;

2. applicable Versions;

3. lifecycle Status;

4. implementation scope;

5. dependencies;

6. adaptations;

7. transition information.

3. The Standards Register shall enable historical reconstruction of standards applicability.

Applicable standards

Article 15

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the standards-management functions identified in that Annex.

3. The standards referenced in Annex I shall not determine the technical requirements of subject-specific implementations.

Annex I

Applicable standards

Reference	Application
ISO/IEC 17000:2020	Conformity assessment vocabulary and general principles
ISO/IEC 17065:2012	Requirements for bodies certifying products, processes and services where certification evidence is used
ISO/IEC 17021-1:2015	Requirements for bodies providing management-system audits and certification where applicable
ISO/IEC 17025:2017	Competence requirements for testing and calibration laboratories where applicable
ISO/IEC 27001:2022	Security-management considerations for standards lifecycle information

IDEHA-IG-ACT-PAR-001: Participation, Roles, Mandates and Representation Implementation

IDEHA-IG-ACT-PAR-001

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the registration, assignment, maintenance and lifecycle management of Participation, Roles, Mandates and representation relationships within the Trust Framework.

2. This Guideline applies to Responsible Actors managing Participation records, Role assignments, Mandates or representation relationships under an applicable Framework Instrument.

3. This Guideline establishes requirements for:

1. recording Participation;

2. assigning Roles;

3. recording Mandates;

4. managing representation relationships;

5. maintaining lifecycle evidence;

6. supporting Validation of authority and representation.

4. This Guideline does not:

1. establish Actor categories;

2. establish Participation rights;

3. create Decision Competence;

4. create Authorisation Outcomes;

5. establish legal capacity or authority;

6. replace requirements established by the Main Framework, applicable Schemes or applicable Profiles.

Participation records

Article 2

1. A Responsible Actor shall maintain a Participation record for each Actor participating within an applicable Framework context.

2. The Participation record shall identify:

1. the participating Actor;

2. the applicable Scheme, Federation Domain or Framework context;

3. the participation scope;

4. the applicable effective period;

5. the assigned Roles where applicable;

6. restrictions or limitations;

7. lifecycle Status.

3. A Participation record shall not by itself establish Authorisation to perform a specific Action.

Article 3

1. Before activating Participation, the Responsible Actor shall verify the information required by the applicable Scheme or Framework Instrument.

2. The verification shall consider, where applicable:

1. Actor identity;

2. organisational information;

3. authority information;

4. applicable Source information;

5. required Assurance Conditions;

6. applicable Security Conditions.

3. Evidence supporting Participation shall be maintained according to the applicable records-management requirements.

Role assignment

Article 4

1. A Responsible Actor assigning a Role shall record:

1. the Actor receiving the Role;

2. the Role identifier;

3. the Role scope;

4. the applicable context;

5. the effective period;

6. restrictions or conditions.

2. A Role assignment shall not be interpreted as creating permission to perform an Action.

3. A Role may be used as an input to an Authorisation Service where the applicable Authorisation Policy requires such input.

Article 5

1. Where a Role depends on qualifications, Attributes, Mandates or other conditions, the Responsible Actor shall identify those dependencies.

2. The Role record shall identify, where applicable:

1. required evidence;

2. validating Source;

3. applicable Status;

4. validity period;

5. reassessment requirements.

3. A Role shall cease to be relied upon where the conditions supporting that Role are no longer valid.

Mandates and delegated authority

Article 6

1. A Mandate shall identify the authority granted by one Actor to another Actor within an identified scope.

2. A Mandate record shall contain:

1. Mandating Actor;

2. Mandated Actor;

3. permitted scope;

4. permitted Actions where applicable;

5. limitations;

6. effective period;

7. revocation conditions;

8. supporting evidence.

3. A Mandate shall not extend beyond the authority available to the Mandating Actor.

Article 7

1. A Responsible Actor shall verify the validity of a Mandate before relying on it.

2. The verification shall determine:

1. identity of the Mandating Actor;

2. identity of the Mandated Actor;

3. existence of authority to grant the Mandate;

4. scope compatibility;

5. validity period;

6. revocation or restriction Status.

3. Where a Mandate is used as an input to an Authorisation decision, the Mandate shall be evaluated together with the applicable Authorisation Policy.

Representation relationships

Article 8

1. A representation relationship shall identify the relationship between a Representing Actor and a Represented Person or Actor.

2. The representation record shall identify:

1. representing Actor;

2. represented Person or Actor;

3. representation basis;

4. permitted scope;

5. effective period;

6. limitations;

7. evidence supporting the representation.

3. A representation relationship shall not alter the identity, Status or obligations of the represented Person or Actor.

Article 9

1. A Responsible Actor shall distinguish between:

1. legal representation;

2. organisational representation;

3. delegated representation;

4. operational assistance;

5. emergency representation;

6. other representation categories established by an applicable Profile.

2. The applicable Profile shall define the conditions under which each representation category may be used.

Lifecycle management

Article 10

1. Participation, Role, Mandate and representation records shall maintain lifecycle information.

2. Lifecycle information shall include, where applicable:

1. creation;

2. activation;

3. modification;

4. suspension;

5. expiration;

6. revocation;

7. withdrawal;

8. historical state.

3. Previous states shall remain identifiable where required for Historical State determination.

Article 11

1. Changes affecting Participation, Roles, Mandates or representation shall be assessed before implementation where they may affect:

1. Authorisation;

2. Controlled Reliance;

3. Trust Service operation;

4. Source access;

5. Federation participation.

2. The assessment shall identify:

1. affected Actors;

2. affected Services;

3. affected Policies;

4. transition requirements.

Validation and evidence

Article 12

1. Participation, Role, Mandate and representation information shall be capable of Verification and Validation where relied upon by another Framework Actor.

2. Verification shall determine:

1. record integrity;

2. identifier consistency;

3. completeness of required information.

3. Validation shall determine:

1. current Status;

2. effective period;

3. supporting evidence;

4. applicable scope;

5. historical validity where required.

Article 13

1. The Responsible Actor shall maintain evidence sufficient to reconstruct:

1. the basis for Participation;

2. Role assignment decisions;

3. Mandate creation and modification;

4. representation relationships;

5. Validation decisions;

6. lifecycle changes.

2. Evidence shall be protected against unauthorised alteration and disclosure.

Security and safeguards

Article 14

1. Participation, Role, Mandate and representation information shall be protected according to its classification and sensitivity.

2. Access to such information shall be limited according to:

1. assigned Role;

2. Authorisation Policy;

3. purpose;

4. minimum necessary disclosure.

3. Special safeguards shall apply where the information concerns Protected Persons or representation involving vulnerable individuals.

Applicable standards

Article 15

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Participation;

2. Role;

3. Mandate;

4. Authorisation;

5. Controlled Reliance.

Annex I

Applicable standards

Reference	Application
ISO/IEC 24760-1:2025	Identity concepts, identity information and relationship between identity information and Actors
ISO/IEC 24760-2:2025	Identity-management architecture considerations for Actor and representation relationships
ISO/IEC 24760-3:2025	Operational management of identity information and lifecycle activities
ISO/IEC 11179-3:2023	Metadata registration for Role, Mandate and relationship-related data elements
ISO/IEC 29146:2024	Access-management architecture where Role and Mandate information is evaluated for access decisions

IDEHA-IG-FED-DOM-001: Federation Domain and Cross-Domain Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the establishment, operation, maintenance and lifecycle management of Federation Domains and cross-domain arrangements under the Trust Framework.

2. This Guideline applies to Responsible Actors establishing or operating Federation Domains, Federation Agreements or cross-domain trust arrangements.

3. This Guideline establishes requirements for:

1. Federation Domain registration;

2. governance and responsibility allocation;

3. participation management;

4. cross-domain trust arrangements;

5. operational coordination;

6. lifecycle and transition management.

4. This Guideline does not:

1. establish Federation Domains as new Actor categories;

2. create Trust Service Categories;

3. create Trust Object Categories;

4. assign Status or Qualified Status;

5. create Controlled Effects;

6. replace requirements established by the Main Framework, Schemes, Profiles or Technical Specifications.

Federation Domain establishment

Article 2

1. A Responsible Actor proposing a Federation Domain shall establish a Federation Domain development record.

2. The development record shall identify:

1. the proposed Federation Domain Identifier;

2. the responsible governance function;

3. the purpose and scope;

4. participating Actors;

5. participating Federation Domains where applicable;

6. applicable Trust Services, Trust Objects and Sources;

7. applicable Schemes, Profiles and Technical Specifications.

3. The Federation Domain shall operate only within the scope established through the applicable Framework decision route.

Article 3

1. A Federation Domain shall define its operational boundaries.

2. The boundaries shall identify:

1. participating jurisdictions, organisations or operational domains;

2. permitted Trust Services;

3. permitted Sources;

4. permitted Trust Objects;

5. permitted exchange relationships;

6. applicable Reliance Conditions.

3. A Federation Domain shall not modify the Status, scope or obligations of participating Actors, Trust Services, Trust Objects or Sources.

Federation governance

Article 4

1. A Federation Domain shall maintain governance arrangements sufficient for its operation.

2. The governance arrangements shall identify:

1. responsible governance Actors;

2. operational responsibilities;

3. participation management responsibilities;

4. security responsibilities;

5. incident coordination responsibilities;

6. Review responsibilities.

3. Governance arrangements shall remain consistent with the Decision Competence established by the Trust Framework.

Article 5

1. A Federation Domain shall maintain a record of participating Actors.

2. The participation record shall identify:

1. Actor Identifier;

2. participation scope;

3. assigned Roles;

4. applicable Trust Services, Trust Objects or Sources;

5. effective period;

6. restrictions or limitations.

3. Participation in a Federation Domain shall not by itself create:

1. Trust Service Status;

2. Qualified Trust Service Status;

3. Authorisation;

4. Controlled Reliance.

Federation Agreements

Article 6

1. A Federation Agreement shall define the conditions under which participating Actors cooperate within a Federation Domain.

2. A Federation Agreement shall identify:

1. participating Actors;

2. responsibilities;

3. permitted interactions;

4. applicable Trust Services;

5. applicable Sources;

6. security conditions;

7. safeguards;

8. dispute and escalation arrangements.

3. A Federation Agreement shall not replace:

1. Framework requirements;

2. Source governance;

3. Trust Service requirements;

4. Authorisation decisions;

5. data-sharing arrangements between Actors.

Article 7

1. Where a Federation Domain includes cross-domain interactions, the responsible Actors shall establish cross-domain trust arrangements.

2. Cross-domain trust arrangements shall identify:

1. participating Federation Domains;

2. trust anchors;

3. applicable Trust Lists or equivalent Status information;

4. Validation requirements;

5. applicable Profiles;

6. Technical Specifications.

3. Cross-domain trust shall not establish automatic acceptance of all Trust Services, Trust Objects or Sources.

Cross-domain operation

Article 8

1. A Federation Domain shall define the conditions for cross-domain reliance.

2. Those conditions shall identify, where applicable:

1. accepted Trust Services;

2. accepted Trust Objects;

3. accepted Sources;

4. required Validation;

5. required Status verification;

6. applicable Assurance Conditions;

7. applicable Security Conditions.

3. A Relying Actor shall apply its Local Trust Acceptance Policy where required by the Main Framework.

Article 9

1. Federation Domains shall maintain information necessary for operational discovery.

2. Discovery information may include:

1. Federation Domain Identifier;

2. participating Actor identifiers;

3. Trust Service identifiers;

4. Source identifiers;

5. Endpoint information;

6. applicable Profiles;

7. Technical Specification references.

3. Discovery information shall not disclose information beyond the permitted publication scope.

Security and continuity coordination

Article 10

1. A Federation Domain shall establish coordination arrangements for:

1. security events;

2. Trust Service disruptions;

3. Source availability issues;

4. compromise events;

5. continuity measures.

2. Coordination arrangements shall identify:

1. responsible Actors;

2. notification conditions;

3. communication channels;

4. evidence requirements;

5. recovery coordination.

Article 11

1. A Federation Domain shall define transition arrangements where changes affect cross-domain operation.

2. Transition arrangements shall consider:

1. changes to Trust Services;

2. changes to Trust Objects;

3. changes to Sources;

4. changes to Standards;

5. changes to Technical Specifications;

6. cessation of participating Actors.

3. Transition arrangements shall preserve Historical State where required.

Lifecycle management

Article 12

1. The Responsible Actor shall monitor whether the Federation Domain continues to operate within its approved scope.

2. Monitoring shall consider:

1. participation changes;

2. security events;

3. changes to applicable Profiles;

4. changes to applicable Standards;

5. changes affecting Reliance Conditions.

3. Material changes shall be assessed before implementation.

Article 13

1. A Federation Domain may be restricted, suspended or closed where:

1. operational conditions are no longer satisfied;

2. security conditions are no longer sufficient;

3. governance requirements cannot be maintained;

4. transition to a replacement arrangement is completed.

2. Closure shall identify:

1. effective closure date;

2. affected Actors;

3. affected Trust Services, Trust Objects and Sources;

4. transition arrangements;

5. records retention requirements.

Records and evidence

Article 14

1. The Responsible Actor shall maintain records demonstrating:

1. Federation Domain establishment;

2. governance arrangements;

3. participation decisions;

4. Federation Agreements;

5. cross-domain trust arrangements;

6. operational changes;

7. lifecycle decisions.

2. Records shall enable reconstruction of the Federation Domain lifecycle.

Applicable standards

Article 15

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Federation Domain Status;

2. Trust Service Status;

3. Qualified Status;

4. Authorisation;

5. Controlled Reliance.

Annex I

Applicable standards

Reference	Application
ISO/IEC 27001:2022	Information security management for Federation Domain governance and operation
ISO/IEC 27701:2025	Privacy information management where personal data is processed across Federation Domains
ISO/IEC 29146:2024	Access-management architecture where cross-domain access decisions are performed
ISO/IEC 24760-2:2025	Identity-management architecture considerations for cross-domain identity relationships
ETSI TS 119 612 V2.4.1	Trusted-list structures where Federation Domains rely on Trust List publication
ETSI TS 119 615 V1.4.1	Interpretation and use of Trust List information across domains

IDEHA-IG-SRC-ASO-001: Source and Authoritative Source Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the recognition, registration, operation, maintenance and lifecycle management of Sources and Authoritative Sources within the Trust Framework.

2. This Guideline applies to Responsible Actors managing Sources, Authoritative Sources and Qualified Authoritative Sources within an applicable Framework context.

3. This Guideline establishes requirements for:

1. Source identification;

2. Source Scope definition;

3. Source Basis management;

4. Attribute provenance and quality management;

5. Source verification;

6. Correction and lifecycle management.

4. This Guideline does not:

1. establish Sources as Trust Service Categories;

2. create Trust Service Status;

3. create Qualified Authoritative Source Status;

4. establish legal authority of a Source;

5. create Controlled Effects;

6. replace requirements established by the Main Framework, Schemes, Profiles or Technical Specifications.

Source registration and identification

Article 2

1. A Responsible Actor managing a Source shall maintain a Source record.

2. The Source record shall identify:

1. the Source Identifier;

2. the Source Holder;

3. the Source Steward;

4. the Source Scope;

5. the Source purpose;

6. the Attributes maintained by the Source;

7. the applicable jurisdiction or operational domain;

8. the effective period of the Source recognition.

Article 3

1. A Source Identifier shall uniquely identify the Source within the applicable identifier scope.

2. A Source Identifier shall not:

1. disclose personal information;

2. encode Source classification;

3. encode Status;

4. encode jurisdictional meaning unless required by the applicable identifier scheme.

3. The Responsible Actor shall maintain the relationship between the Source Identifier and the Source metadata required for Validation.

Source Scope and Attributes

Article 4

1. A Source shall define its Source Scope.

2. The Source Scope shall identify:

1. the Attributes maintained by the Source;

2. the Subjects to which the Attributes relate;

3. the applicable geographic, organisational or operational scope;

4. the applicable time period;

5. the conditions under which the Source is authoritative.

3. A Source shall not be considered authoritative for Attributes outside its Source Scope.

Article 5

1. A Source maintaining Attributes shall maintain semantic definitions for those Attributes.

2. Attribute definitions shall identify:

1. Attribute Identifier;

2. Attribute meaning;

3. value domain;

4. datatype;

5. permitted transformations;

6. quality requirements;

7. lifecycle conditions.

3. Attribute semantics shall remain separate from:

1. Attribute values;

2. Source identifiers;

3. Subject identifiers;

4. Trust Object identifiers.

Authoritative Source designation

Article 6

1. An Authoritative Source shall be designated only where the applicable Framework Instrument establishes that the Source has authority for the identified Source Scope.

2. The designation shall identify:

1. the Source Scope;

2. the Attributes covered;

3. the responsible Source Holder;

4. the applicable conditions;

5. the effective period.

3. Authoritative Source designation shall not establish Qualified Authoritative Source Status.

Article 7

1. A Qualified Authoritative Source shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall specify:

1. Assurance Conditions;

2. Security Conditions;

3. Data Quality Conditions;

4. Provenance requirements;

5. correction and lifecycle requirements;

6. Conformity Assessment requirements.

3. Qualified Authoritative Source Status shall apply only within the approved Source Scope.

Source data quality and provenance

Article 8

1. A Source shall maintain information sufficient to establish the origin and lifecycle of Attributes.

2. Provenance information shall identify, where applicable:

1. originating event;

2. originating Source process;

3. creation time;

4. modification history;

5. responsible Actor;

6. transformation or derivation activity.

3. Derived Attributes shall identify:

1. source Attributes;

2. derivation method;

3. applicable Version;

4. responsible processing function.

Article 9

1. A Source shall establish Data Quality controls appropriate to its Source Scope.

2. Data Quality controls shall address, where applicable:

1. accuracy;

2. completeness;

3. consistency;

4. timeliness;

5. uniqueness;

6. validity.

3. Data Quality requirements shall be specified by the applicable Profile where different Source Scopes require different conditions.

Source Verification and reliance

Article 10

1. A Source consumer shall verify that the Source information used is applicable to the intended purpose.

2. Verification shall determine:

1. Source identity;

2. Source Scope;

3. Attribute coverage;

4. Provenance availability;

5. applicable Version;

6. data freshness.

3. Validation of a Source shall determine, where applicable:

1. Source Status;

2. Authoritative Source Status;

3. Qualified Authoritative Source Status;

4. Historical State;

5. applicable restrictions.

Article 11

1. A Relying Actor shall not assume that an Attribute is authoritative solely because it originates from a recognised Source.

2. Reliance shall consider:

1. the Source Scope;

2. Attribute definition;

3. Freshness Condition;

4. Provenance;

5. Correction status;

6. applicable Reliance Conditions.

3. A Source shall not determine the legal effect of an Attribute outside the Source Scope assigned to it.

Correction and lifecycle management

Article 12

1. A Source shall maintain procedures for:

1. Attribute correction;

2. supersession;

3. historical preservation;

4. withdrawal of incorrect information;

5. notification where required.

2. Corrections shall preserve sufficient evidence to reconstruct:

1. previous values;

2. correction basis;

3. responsible Actor;

4. effective time;

5. affected reliance decisions.

Article 13

1. Changes affecting a Source shall be assessed where they affect:

1. Source Scope;

2. Attribute meaning;

3. Data Quality;

4. Provenance;

5. interoperability;

6. Qualified Authoritative Source conditions.

2. Material changes shall be managed through the applicable Change Control process.

Security and access

Article 14

1. Sources shall protect information according to its classification and applicable disclosure conditions.

2. Access to Source information shall be controlled through:

1. Authentication;

2. Authorisation;

3. Disclosure Conditions;

4. purpose limitations;

5. audit requirements.

3. Security requirements shall be applied according to the applicable Security Conditions.

Records and evidence

Article 15

1. The Responsible Actor shall maintain records demonstrating:

1. Source registration;

2. Source Scope;

3. Attribute definitions;

4. Provenance;

5. Data Quality assessments;

6. corrections;

7. lifecycle changes;

8. Qualification evidence where applicable.

2. Records shall enable reconstruction of the Source lifecycle and Historical State.

Applicable standards

Article 16

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Source authority;

2. Authoritative Source Status;

3. Qualified Authoritative Source Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ISO/IEC 11179-1:2023	Metadata registry framework for Source Attributes and semantic definitions
ISO/IEC 11179-3:2023	Registration and identification of metadata items
ISO/IEC 11179-31:2023	Description of data elements, value domains and data-element concepts
ISO/IEC 11179-6:2023	Registration authority and metadata lifecycle management
ISO/IEC 24760-1:2025	Identity information concepts and relationships
ISO/IEC 24760-2:2025	Identity-management architecture considerations
ISO/IEC 24760-3:2025	Identity-management operational processes
ISO/IEC 25012:2008	Data quality model
ISO/IEC 25024:2015	Data quality measurement
ISO 15489-1:2016	Records management principles
ISO 23081-1:2017	Metadata for records management
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy information management controls

IDEHA-IG-OBJ-GEN-001: Trust Object Common and Lifecycle Implementation

Version: 0.2

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the identification, creation, issuance, lifecycle management, protection, Validation support and historical reconstruction of Trust Objects.

2. This Guideline applies to Actors responsible for creating, issuing, managing, validating or relying upon Trust Objects within the scope established by the applicable Framework Instruments.

3. This Guideline establishes common implementation requirements for:

1. Trust Object identification;

2. Trust Object Metadata;

3. Trust Object lifecycle management;

4. Trust Object dependencies;

5. Trust Object evidence;

6. Historical State reconstruction.

4. This Guideline applies together with the applicable Trust Object specific Implementation Guideline.

5. This Guideline does not:

1. establish Trust Object Categories;

2. define the substantive meaning of a Trust Object Category;

3. assign Status or Qualified Status;

4. establish Controlled Effects;

5. replace requirements of a Trust Object specific Profile;

6. define technical formats, schemas, protocols or cryptographic parameters.

Trust Object identification

Article 2

1. Each Trust Object shall be assigned a Trust Object Identifier.

2. The Trust Object Identifier shall:

1. uniquely distinguish the Trust Object within its applicable scope;

2. remain stable throughout the Trust Object lifecycle;

3. not disclose personal information;

4. not encode Trust Object Status, Assurance Level or Qualified Status.

3. The Trust Object Identifier shall remain separate from:

1. Subject Identifiers;

2. Actor Identifiers;

3. Source Identifiers;

4. Trust Service Identifiers;

5. Serial Numbers.

4. The applicable Trust Object Profile shall define:

1. identifier generation;

2. uniqueness scope;

3. non-reuse conditions;

4. collision handling;

5. lifecycle treatment.

Article 3

1. Where a Trust Object contains an issuer-assigned Serial Number, the Serial Number shall identify the issued object within the issuer scope.

2. A Serial Number shall:

1. be unique within the issuer scope;

2. not be reused;

3. remain linked to the issuing Actor;

4. remain separate from the Trust Object Identifier.

3. The relationship between a Trust Object Identifier and a Serial Number shall be defined by the applicable Trust Object Profile or Technical Specification.

Trust Object Metadata

Article 4

1. A Trust Object shall contain or reference Metadata necessary for identification, Validation and lifecycle management.

2. Metadata shall include, where applicable:

1. Trust Object Identifier;

2. Trust Object Category;

3. Issuer or producing Actor;

4. creation time;

5. issuance time;

6. Version;

7. applicable Profile;

8. applicable Technical Specification;

9. Status reference;

10. dependency references;

11. Provenance information.

3. Metadata shall not be interpreted as creating Authenticity, Validity, Status or Controlled Reliance.

Article 5

1. The Issuer or producing Actor shall ensure that Trust Object Metadata remains consistent with the applicable Profile.

2. Changes to Metadata shall be controlled where they may affect:

1. Identification;

2. Validation;

3. Status determination;

4. Historical State;

5. Controlled Reliance.

Trust Object creation and issuance

Article 6

1. A Trust Object shall be created only by an Actor authorised to create that Trust Object within the applicable scope.

2. Creation shall include, where applicable:

1. determination of the Subject or matter to which the Trust Object relates;

2. evaluation of required evidence;

3. application of the applicable Profile;

4. creation of the Trust Object representation;

5. recording of creation evidence.

3. The creation process shall preserve the relationship between:

1. the Trust Object;

2. the Issuer or producing Actor;

3. the applicable Source Basis or evidence basis;

4. the applicable protection mechanism.

Article 7

1. Issuance of a Trust Object shall include recording:

1. issuance time;

2. issuing Actor;

3. applicable Service Scope;

4. applicable Profile Version;

5. applicable dependencies;

6. issuance evidence.

2. The issuance record shall enable reconstruction of the conditions existing at the time of issuance.

Trust Object protection

Article 8

1. A Trust Object shall be protected according to its category, purpose and applicable Profile.

2. Protection mechanisms may include:

1. Electronic Signature;

2. Electronic Seal;

3. encryption;

4. integrity mechanisms;

5. access controls;

6. other recognised protection methods.

3. The protection mechanism shall remain separate from the Trust Object Category unless the Main Framework establishes a specific relationship.

Article 9

1. Where a Trust Object depends on another Trust Object, the dependency shall be identified.

2. Dependency information shall identify:

1. dependent Trust Object;

2. dependency purpose;

3. required Status;

4. applicable Validation conditions;

5. dependency Version.

3. A dependent Trust Object shall not transfer its Status, Qualified Status or Controlled Effects to another Trust Object.

Trust Object lifecycle

Article 10

1. The lifecycle of a Trust Object shall include, where applicable:

1. creation;

2. issuance;

3. activation;

4. use;

5. Validation;

6. Suspension;

7. Revocation;

8. replacement;

9. supersession;

10. expiration;

11. archival;

12. closure.

2. The applicable Trust Object Profile shall define the lifecycle states applicable to each Trust Object Category.

Article 11

1. Lifecycle changes affecting a Trust Object shall be recorded.

2. The lifecycle record shall identify:

1. previous state;

2. new state;

3. effective time;

4. responsible Actor;

5. reason for change;

6. supporting evidence.

3. Lifecycle records shall enable determination of the Trust Object state at a previous point in time.

Validation and historical reconstruction

Article 12

1. A Trust Object shall be capable of Verification and Validation according to its applicable Profile.

2. Verification shall determine:

1. structural consistency;

2. integrity of representation;

3. presence of required Metadata;

4. format compliance.

3. Validation shall determine, where applicable:

1. Authenticity;

2. Validity;

3. Status;

4. Qualified Status conditions;

5. dependency validity;

6. Historical State.

Article 13

1. Where a Trust Object is relied upon after changes to its dependencies, Validation shall consider the Historical State applicable at the relevant time.

2. Historical State determination shall consider:

1. Trust Object Version;

2. dependency Status;

3. issuer or producing Actor Status;

4. applicable Standards;

5. applicable Profiles.

3. A current Status shall not automatically determine the historical Status of a Trust Object.

Correction, replacement and preservation

Article 14

1. A Trust Object lifecycle process shall define conditions for:

1. Correction;

2. replacement;

3. supersession;

4. withdrawal;

5. preservation.

2. Replacement or supersession shall create a new Trust Object Identifier unless the applicable Profile expressly provides another controlled mechanism.

3. Previous Trust Objects shall remain identifiable where required for Historical State determination.

Article 15

1. Trust Objects requiring long-term reliance shall be preserved according to the applicable Profile.

2. Preservation requirements may include:

1. Validation evidence preservation;

2. timestamp evidence;

3. cryptographic transition management;

4. historical dependency records;

5. integrity verification.

Records and evidence

Article 16

1. The Responsible Actor shall maintain records sufficient to reconstruct:

1. creation;

2. issuance;

3. protection;

4. Validation;

5. lifecycle changes;

6. dependency changes;

7. historical state.

2. Records shall be protected against unauthorised alteration and disclosure.

Applicable standards

Article 17

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Trust Object Category;

2. Status;

3. Qualified Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ISO/IEC 24760-1:2025	Identity and identifier concepts where Trust Objects relate to Subjects or Actors
ISO/IEC 11179-3:2023	Metadata registration principles for Trust Object Metadata
ISO 15489-1:2016	Records management principles for lifecycle evidence
ISO 23081-1:2017	Metadata principles for lifecycle and provenance information
ISO/IEC 27001:2022	Security management controls applicable to Trust Object lifecycle management
ISO/IEC 27002:2022	Security controls applicable to Trust Object protection

IDEHA-IG-OBJ-EAA-001: Electronic Attestation Implementation

IDEHA-IG-OBJ-GEN-001 Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for the creation, issuance, management, Validation support and lifecycle management of Electronic Attestations.

2. This Guideline applies to Trust Service Providers providing an Electronic Attestation Service and Actors creating, issuing, validating or relying upon Electronic Attestations.

3. This Guideline establishes requirements for:

1. Attestation Issuer responsibilities;

2. Attestation Statement implementation;

3. Source Basis and evidence handling;

4. Electronic Attestation creation and issuance;

5. Electronic Attestation lifecycle management;

6. Validation support.

4. This Guideline applies together with the applicable Electronic Attestation Profile.

5. This Guideline does not:

1. establish Electronic Attestation as a new Trust Service Category;

2. establish Qualified Electronic Attestation conditions;

3. assign Qualified Trust Service Status;

4. define Attribute semantics belonging to the Data Quality and Semantic Implementation Guideline;

5. define technical formats, schemas or protocols assigned to Technical Specifications.

Electronic Attestation scope and Profile

Article 2

1. An Electronic Attestation shall be created according to an applicable Electronic Attestation Profile.

2. The Electronic Attestation Profile shall identify:

1. the purpose of the Electronic Attestation;

2. the Subject or matter to which the Attestation Statement relates;

3. the applicable Attributes or statements;

4. the applicable Source Basis;

5. the applicable Assurance Conditions;

6. the applicable Security Conditions;

7. the applicable Validation requirements.

3. An Electronic Attestation shall not contain statements outside the scope established by the applicable Profile.

Attestation Issuer

Article 3

1. An Attestation Issuer shall be identified within each Electronic Attestation.

2. The Attestation Issuer information shall identify:

1. the issuing Trust Service Provider or Actor;

2. the Electronic Attestation Service;

3. the applicable Service Scope;

4. the applicable Version;

5. the applicable Profile.

3. The Attestation Issuer shall remain responsible for the creation and issuance process within its assigned scope.

4. The Attestation Issuer shall not assume responsibility for a Source beyond the Source Basis and verification activities performed.

Subject and Attestation Statement

Article 4

1. An Electronic Attestation shall identify the Subject or matter to which the Attestation Statement relates.

2. The Subject reference shall use an applicable Subject Identifier or another permitted reference defined by the applicable Profile.

3. A Subject Identifier shall:

1. remain opaque;

2. not disclose identity type;

3. not disclose demographic information;

4. not disclose Status or qualification information.

4. The Attestation Statement shall identify the Attribute, fact or relationship being attested.

Article 5

1. Attribute information included in an Electronic Attestation shall use controlled semantic definitions.

2. The Electronic Attestation shall identify, where applicable:

1. Attribute Identifier;

2. Attribute Version;

3. value domain;

4. Source Basis;

5. Provenance information;

6. applicable Freshness Condition.

3. Attribute values shall remain separate from:

1. Attribute identifiers;

2. Subject identifiers;

3. Trust Object identifiers.

Source Basis and evidence

Article 6

1. Where an Electronic Attestation is based on information obtained from a Source, the Source Basis shall be identified.

2. The Source Basis shall identify, where applicable:

1. Source Identifier;

2. Source Scope;

3. Source Holder;

4. Source Steward;

5. relevant evidence;

6. Provenance information.

3. An Electronic Attestation shall not be considered authoritative solely because it contains information originating from a Source.

Article 7

1. The Attestation Issuer shall evaluate the evidence basis before issuing an Electronic Attestation.

2. The evaluation shall determine, where applicable:

1. Source applicability;

2. Attribute scope;

3. Provenance;

4. Freshness;

5. integrity of received information;

6. applicable Assurance Conditions.

3. The evaluation result shall be retained as issuance evidence.

Electronic Attestation creation and issuance

Article 8

1. Before issuing an Electronic Attestation, the Attestation Issuer shall verify that:

1. the issuance request is authorised;

2. the Subject or matter is identified;

3. the Attestation Statement is within scope;

4. required evidence is available;

5. applicable conditions are satisfied.

2. The Electronic Attestation shall contain or reference:

1. Trust Object Identifier;

2. Attestation Issuer;

3. Attestation Statement;

4. issuance time;

5. applicable Profile;

6. applicable protection information;

7. Status information or Status reference where applicable.

Article 9

1. The Attestation Issuer shall protect the Electronic Attestation against unauthorised alteration.

2. Protection mechanisms may include:

1. Electronic Signature;

2. Electronic Seal;

3. another approved integrity mechanism.

3. Where an Electronic Attestation is qualified, the applicable Qualified Object Profile shall identify the required qualified protection dependencies.

Electronic Attestation lifecycle

Article 10

1. The lifecycle of an Electronic Attestation shall include, where applicable:

1. creation;

2. issuance;

3. activation;

4. use;

5. Validation;

6. correction;

7. replacement;

8. suspension;

9. revocation;

10. expiration;

11. withdrawal.

2. Lifecycle states shall be defined by the applicable Profile.

Article 11

1. The Attestation Issuer shall maintain Status information necessary for Validation.

2. Status information shall identify, where applicable:

1. current Status;

2. effective time;

3. reason for Status change;

4. responsible Actor;

5. supporting evidence.

3. Status information shall enable determination of the Electronic Attestation state at a relevant time.

Qualified Electronic Attestations

Article 12

1. A Qualified Electronic Attestation shall satisfy the requirements established by the applicable Qualified Object Profile.

2. The Qualified Object Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required Source Status where applicable;

4. required protection mechanisms;

5. required Assurance Conditions;

6. required Validation conditions.

3. Qualified Status shall apply only within the scope established by the applicable Qualified Profile.

4. Qualification of a dependency shall not automatically transfer Qualified Status to the Electronic Attestation.

Validation and reliance

Article 13

1. An Electronic Attestation shall support Validation according to its applicable Profile.

2. Validation shall determine, where applicable:

1. Attestation Issuer identity;

2. protection validity;

3. Attribute integrity;

4. Source Basis;

5. Status;

6. Historical State;

7. applicable limitations.

3. A Relying Actor shall apply its Local Trust Acceptance Policy before Controlled Reliance.

Article 14

1. An Electronic Attestation shall not by itself establish:

1. the underlying legal fact;

2. eligibility;

3. entitlement;

4. Authorisation;

5. a Source authority outside its assigned scope.

2. Reliance shall consider the purpose, scope and limitations of the Electronic Attestation.

Correction and replacement

Article 15

1. The Attestation Issuer shall maintain procedures for:

1. correction;

2. replacement;

3. supersession;

4. revocation;

5. withdrawal.

2. Replacement of an Electronic Attestation shall identify:

1. predecessor Trust Object Identifier;

2. replacement Trust Object Identifier;

3. reason for replacement;

4. effective time.

3. Previous Electronic Attestations shall remain identifiable where required for Historical State determination.

Records and evidence

Article 16

1. The Attestation Issuer shall maintain records sufficient to reconstruct:

1. issuance basis;

2. Source Basis;

3. evidence evaluation;

4. creation process;

5. protection process;

6. lifecycle changes;

7. Validation history.

2. Records shall be protected according to the applicable Security Conditions.

Applicable standards

Article 17

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Attestation Category;

2. Qualified Trust Service Status;

3. Qualified Trust Object Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 401:2024	General trust service provider implementation requirements
ETSI TS 119 461:2025	Identity proofing requirements where identity evidence is evaluated before issuance
ISO/IEC 11179-3:2023	Attribute metadata registration and semantic identification
ISO/IEC 11179-31:2023	Data-element concepts, value domains and semantic descriptions
ISO/IEC 24760-1:2025	Identity information concepts and relationships
ISO/IEC 27001:2022	Security management controls applicable to attestation issuance
ISO/IEC 27701:2025	Privacy management controls where personal data is processed

IDEHA-IG-OBJ-CRT-001: Certificate as Specialised Electronic Attestation Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Certificates issued as specialised Electronic Attestations within the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Certificate-related Electronic Attestation Services and Actors creating, issuing, validating or relying upon Certificates.

3. This Guideline establishes requirements for:

1. Certificate identification;

2. Certificate issuance;

3. Certificate content;

4. Certificate lifecycle management;

5. Certificate Status management;

6. Certificate Validation support.

4. This Guideline applies together with the applicable Certificate Profile and Technical Specification.

5. This Guideline does not:

1. establish Certificate as a separate Trust Object Category;

2. establish a new Trust Service Category;

3. define X.509 technical structures;

4. define cryptographic algorithms or parameters;

5. assign Qualified Status;

6. replace requirements established by the Main Framework, Electronic Attestation Implementation Guideline or applicable Qualified Object Profile.

Certificate scope and purpose

Article 2

1. A Certificate shall be issued only within the scope established by the applicable Certificate Profile.

2. The Certificate Profile shall identify:

1. Certificate purpose;

2. Subject category;

3. Certificate Holder;

4. applicable Validation Data;

5. applicable Assurance Conditions;

6. applicable Security Conditions;

7. applicable lifecycle conditions.

3. A Certificate shall not contain statements or bindings outside the scope established by the applicable Certificate Profile.

Certificate Issuer and responsibilities

Article 3

1. The Certificate Issuer shall be identified within each issued Certificate.

2. The Certificate Issuer information shall identify:

1. the issuing Trust Service Provider;

2. the issuing Electronic Attestation Service;

3. the applicable Service Scope;

4. the applicable Certificate Profile.

3. The Certificate Issuer shall remain responsible for:

1. Certificate issuance;

2. Certificate lifecycle management;

3. Certificate Status information;

4. Certificate issuance evidence.

4. The Certificate Issuer shall not create or alter the legal identity of the Subject through Certificate issuance.

Subject identification and binding

Article 4

1. A Certificate shall identify the Subject to which the Certificate relates.

2. The Subject identification method shall be defined by the applicable Certificate Profile.

3. The Certificate Profile shall specify:

1. Subject identification requirements;

2. identity evidence requirements;

3. Attribute verification requirements;

4. representation requirements where applicable.

4. Subject identification information shall remain separate from:

1. Certificate Identifier;

2. Serial Number;

3. Trust Service Identifier;

4. Subject Identifier.

Article 5

1. Where a Certificate binds Validation Data to a Subject, the Certificate shall identify the Validation Data.

2. The binding shall include:

1. Subject reference;

2. Validation Data reference;

3. Certificate validity period;

4. Certificate policy information;

5. applicable restrictions.

3. The binding shall remain within the purpose defined by the Certificate Profile.

Certificate content

Article 6

1. The Certificate shall contain or reference information necessary for:

1. identification;

2. Validation;

3. lifecycle management;

4. reliance within the applicable scope.

2. The Certificate content shall be defined by the applicable Technical Specification.

3. The Technical Specification shall define:

1. data structure;

2. encoding;

3. mandatory fields;

4. optional fields;

5. extensions;

6. policy identifiers;

7. validation requirements.

Article 7

1. A Certificate shall contain a Certificate Identifier or equivalent identifier mechanism.

2. A Certificate Serial Number shall:

1. uniquely identify the Certificate within the issuer scope;

2. not be reused;

3. remain associated with the issuing Actor.

3. The relationship between the Certificate Identifier and the Trust Object Identifier shall be defined by the applicable Profile.

Certificate issuance

Article 8

1. Before issuing a Certificate, the Certificate Issuer shall verify that:

1. the issuance request is authorised;

2. the Subject is identified;

3. required evidence is available;

4. required Attributes have been verified;

5. applicable conditions are satisfied.

2. The Certificate Issuer shall maintain issuance evidence.

3. Issuance evidence shall include, where applicable:

1. identity verification results;

2. Attribute verification results;

3. approval information;

4. issuance time;

5. Certificate Profile Version.

Certificate lifecycle

Article 9

1. The lifecycle of a Certificate shall include, where applicable:

1. request;

2. approval;

3. issuance;

4. activation;

5. suspension;

6. revocation;

7. expiration;

8. renewal;

9. replacement.

2. The Certificate Issuer shall maintain lifecycle information for each issued Certificate.

Article 10

1. Certificate Status information shall enable determination of whether a Certificate remains valid for its intended purpose.

2. Certificate Status information shall identify:

1. Certificate Identifier;

2. Status;

3. effective time;

4. reason for Status change where applicable;

5. responsible Actor.

3. Certificate Status information shall support historical determination where required.

Qualified Certificates

Article 11

1. A Qualified Certificate shall satisfy the requirements established by the applicable Qualified Object Profile.

2. The Qualified Object Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required Certificate Profile;

4. required Validation conditions;

5. required Security Conditions.

3. Qualified Certificate Status shall apply only within the approved Qualified Scope.

4. Qualification of the Certificate Issuer shall not automatically qualify every issued Certificate.

Certificate Validation

Article 12

1. Certificate Validation shall determine whether the Certificate satisfies the applicable Certificate Profile and Validation requirements.

2. Validation shall determine, where applicable:

1. Certificate integrity;

2. issuer identity;

3. Subject binding;

4. certificate chain validity;

5. Certificate Status;

6. policy applicability;

7. Historical State.

3. Certificate Validation shall be performed according to the applicable Validation and Verification Service requirements.

Article 13

1. A Certificate shall not by itself establish:

1. Authorisation;

2. entitlement;

3. legal capacity;

4. eligibility;

5. any fact outside the Certificate scope.

2. Reliance upon a Certificate shall consider:

1. Certificate purpose;

2. Certificate Profile;

3. Status;

4. Source Basis where applicable;

5. applicable Reliance Conditions.

Certificate replacement and cessation

Article 14

1. The Certificate Issuer shall maintain procedures for:

1. renewal;

2. replacement;

3. suspension;

4. revocation;

5. withdrawal.

2. Replacement of a Certificate shall identify:

1. predecessor Certificate;

2. replacement Certificate;

3. effective time;

4. reason for replacement.

3. Previous Certificates shall remain identifiable where required for Historical State determination.

Records and evidence

Article 15

1. The Certificate Issuer shall maintain records sufficient to reconstruct:

1. issuance;

2. identity verification;

3. Certificate creation;

4. Certificate Status changes;

5. Validation history;

6. replacement and revocation events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 16

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Certificate Category;

2. Qualified Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
RFC 5280	X.509 public key certificate structure, certificate path validation and certificate extensions
ETSI EN 319 411-1	General policy requirements for certificate-issuing Trust Service Providers
ETSI EN 319 411-2	Policy requirements for qualified certificate issuing Trust Service Providers
ETSI EN 319 412-1	Certificate profile requirements and common certificate data structures
ETSI EN 319 412-2	Certificate profiles for natural persons
ETSI EN 319 412-3	Certificate profiles for legal persons
ETSI EN 319 412-5	Qualified certificate statements
ISO/IEC 24760-1:2025	Identity concepts and identity information relationships
ISO/IEC 27001:2022	Security management controls applicable to Certificate services

IDEHA-IG-OBJ-DSG-001: Digital Signature and Creation Data Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Digital Signature Creation Data, Digital Signature Validation Data, Digital Signature Creation Mechanisms and Digital Signature Creation Devices.

2. This Guideline applies to Actors responsible for generating, protecting, operating, assessing, managing or relying upon Digital Signature creation environments.

3. This Guideline establishes requirements for:

1. generation and protection of Digital Signature Creation Data;

2. management of Digital Signature Validation Data;

3. operation of Digital Signature Creation Mechanisms;

4. operation of Digital Signature Creation Devices;

5. security boundaries protecting Digital Signature Creation Data;

6. conformity assessment and assurance evidence;

7. lifecycle management and compromise handling.

4. This Guideline applies together with:

1. IDEHA-IG-SVC-DSG-001 Digital Signing Service Implementation;

2. IDEHA-IG-SVC-SIG-001 Electronic Signature Service Implementation;

3. IDEHA-IG-SVC-SEL-001 Electronic Seal Service Implementation;

4. IDEHA-IG-SEC-CRY-001 Cryptographic Controls and Cryptographic Agility Implementation;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish requirements for:

1. Electronic Signatures;

2. Electronic Seals;

3. Advanced Electronic Signatures;

4. Advanced Electronic Seals;

5. Qualified Electronic Signatures;

6. Qualified Electronic Seals;

7. Signatory identification;

8. Seal Creator identification;

9. signing intent;

10. sealing intent;

11. signature workflows;

12. signature formats;

13. signature Validation procedures.

Digital Signature Creation Data

Article 2

1. Digital Signature Creation Data shall consist of cryptographic data uniquely associated with the creation of Digital Signatures.

2. Digital Signature Creation Data shall be generated and managed within an approved cryptographic environment.

3. The responsible Actor shall ensure that Digital Signature Creation Data:

1. is generated using approved cryptographic mechanisms;

2. remains confidential;

3. remains protected against unauthorised extraction;

4. remains protected against unauthorised duplication;

5. is used only through authorised cryptographic operations.

4. Digital Signature Creation Data shall not be used for purposes outside the approved Digital Signature creation function.

Article 3

1. Generation of Digital Signature Creation Data shall ensure:

1. practical uniqueness;

2. sufficient unpredictability;

3. appropriate cryptographic strength;

4. protection of generation processes;

5. traceability of lifecycle events.

2. The applicable Cryptographic Profile shall specify:

1. permitted algorithms;

2. cryptographic parameters;

3. key-generation requirements;

4. transition conditions.

Digital Signature Validation Data

Article 4

1. Digital Signature Validation Data shall enable verification of a Digital Signature.

2. Digital Signature Validation Data shall correspond exclusively to the associated Digital Signature Creation Data.

3. The responsible Actor shall maintain evidence establishing the association between:

1. Digital Signature Creation Data;

2. Digital Signature Validation Data;

3. Digital Signature Creation Device;

4. applicable cryptographic mechanism.

4. The technical representation of Digital Signature Validation Data shall be defined by the applicable Technical Specification.

Digital Signature Creation Mechanism

Article 5

1. A Digital Signature Creation Mechanism shall provide the cryptographic function used to generate Digital Signatures.

2. The Digital Signature Creation Mechanism shall identify:

1. cryptographic operations;

2. protected functions;

3. required inputs;

4. security assumptions;

5. external dependencies.

3. The Digital Signature Creation Mechanism shall operate within an identified security boundary.

Article 6

1. A Digital Signature Creation Mechanism shall ensure that:

1. Digital Signature Creation Data is used only by authorised functions;

2. cryptographic operations are executed according to approved requirements;

3. unauthorised modification of cryptographic functions is prevented;

4. security-relevant events are recorded where required.

Digital Signature Creation Device

Article 7

1. A Digital Signature Creation Device shall provide the protected environment in which Digital Signature Creation Data is generated, stored or used.

2. The Digital Signature Creation Device shall identify:

1. Device Identifier;

2. device category;

3. security boundary;

4. configuration Version;

5. operational Status;

6. conformity evidence where applicable.

3. The Device Identifier shall:

1. remain stable during the applicable lifecycle;

2. not disclose personal information;

3. not encode Status;

4. not encode qualification level.

Article 8

1. The Digital Signature Creation Device security boundary shall identify:

1. protected components;

2. trusted functions;

3. cryptographic functions;

4. administrative interfaces;

5. external interfaces;

6. dependencies.

2. The security boundary shall protect Digital Signature Creation Data against:

1. unauthorised disclosure;

2. unauthorised extraction;

3. unauthorised duplication;

4. unauthorised modification;

5. unauthorised use.

Device activation and controlled operation

Article 9

1. A Digital Signature Creation Device shall support controlled activation of Digital Signature creation operations.

2. Activation controls shall ensure:

1. authorised operation;

2. protection of activation information;

3. prevention of unauthorised activation;

4. detection of abnormal activity.

3. Device activation requirements shall remain separate from:

1. Authentication Service operation;

2. Electronic Signature Service operation;

3. Authorisation Service decisions.

Remote Digital Signature Creation Devices

Article 10

1. A remote Digital Signature Creation Device shall maintain a controlled security boundary between:

1. Signatory interaction;

2. activation functions;

3. cryptographic functions;

4. Digital Signature Creation Data.

2. A remote Digital Signature Creation Device shall identify:

1. Cryptographic Module;

2. Signature Activation Mechanism where applicable;

3. Signature Activation Data where applicable;

4. trusted communication channels;

5. operational responsibilities.

3. The applicable Profile shall specify requirements for remote operation and sole control conditions where applicable.

Qualified Digital Signature Creation Devices

Article 11

1. A Digital Signature Creation Device intended to obtain Qualified Status shall satisfy the applicable Qualified Object Profile.

2. The Qualified Object Profile shall specify:

1. applicable Protection Profile;

2. required assurance level;

3. required conformity evidence;

4. evaluated configuration;

5. lifecycle conditions;

6. operational limitations.

3. A cryptographic module, Hardware Security Module, secure element or other cryptographic component shall not by itself constitute a Qualified Digital Signature Creation Device.

Article 12

1. The minimum security evaluation level for a Qualified Digital Signature Creation Device shall be:

1. Common Criteria Evaluation Assurance Level 4 augmented by applicable augmentation requirements; or

2. an equivalent assurance level recognised through the applicable qualification route.

2. The security evaluation shall identify:

1. Target of Evaluation;

2. Security Target;

3. Protection Profile;

4. evaluated configuration;

5. certification scope;

6. applicable limitations.

3. A modification affecting the evaluated security boundary shall require reassessment where required by the applicable conformity route.

Cryptographic modules and composite devices

Article 13

1. Where a Digital Signature Creation Device includes a Cryptographic Module, the Cryptographic Module shall satisfy the applicable security requirements.

2. Where a Digital Signature Creation Device consists of multiple security components, the conformity evidence shall identify:

1. each evaluated component;

2. the relationship between components;

3. the combined security boundary;

4. applicable dependencies.

3. A composite Digital Signature Creation Device shall be assessed as the complete configuration intended for operation.

Lifecycle management

Article 14

1. The lifecycle of Digital Signature Creation Data and Digital Signature Creation Devices shall include, where applicable:

1. generation;

2. registration;

3. configuration;

4. evaluation;

5. activation;

6. operation;

7. maintenance;

8. suspension;

9. replacement;

10. retirement;

11. destruction.

2. Lifecycle events affecting security assurance shall be recorded.

Article 15

1. Changes affecting the security properties of a Digital Signature Creation Device shall be assessed before implementation.

2. The assessment shall consider:

1. hardware changes;

2. firmware changes;

3. software changes;

4. cryptographic changes;

5. configuration changes;

6. certification impact.

Compromise management

Article 16

1. Where Digital Signature Creation Data or a Digital Signature Creation Device is compromised or suspected to be compromised, the responsible Actor shall implement protective measures.

2. Protective measures shall include, where applicable:

1. restriction of operation;

2. preservation of evidence;

3. investigation;

4. replacement;

5. reassessment.

3. The effect of compromise on previously created Digital Signatures shall be determined through the applicable Validation process.

Records and evidence

Article 17

1. The responsible Actor shall maintain records sufficient to reconstruct:

1. Digital Signature Creation Data lifecycle;

2. Digital Signature Creation Device identity;

3. device configuration;

4. security evaluation;

5. cryptographic operations;

6. compromise events.

2. Records shall identify the relationship between:

1. Digital Signature Creation Data;

2. Digital Signature Validation Data;

3. Digital Signature Creation Mechanism;

4. Digital Signature Creation Device.

Applicable standards

Article 18

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Signature Status;

2. Qualified Electronic Signature Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
EN 419 211 series	Protection Profiles for secure signature creation devices
EN 419 241-1	General security requirements for trustworthy systems supporting server signing
EN 419 241-2	Protection Profile for QSCD for server signing
EN 419 221-5	Protection Profile for cryptographic modules used in Trust Services
ISO/IEC 15408 series	Common Criteria security evaluation framework
ISO/IEC 18045	Common Criteria evaluation methodology
ISO/IEC 19790	Security requirements for cryptographic modules
ISO/IEC 24759	Cryptographic module testing requirements
ISO/IEC 11770 series	Key management requirements
ETSI TS 119 312	Cryptographic suites and mechanisms

IDEHA-IG-OBJ-SIG-001: Electronic Signature Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Signatures within the Trust Framework.

2. This Guideline applies to Actors creating, managing, validating or relying upon Electronic Signatures within the scope established by the applicable Framework Instruments.

3. This Guideline establishes requirements for:

1. Electronic Signature creation context;

2. Signatory attribution;

3. signing act implementation;

4. signing intent evidence;

5. association between the Electronic Signature and signed data;

6. Electronic Signature lifecycle management;

7. Signature Evidence management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

2. IDEHA-IG-SVC-DSG-001 Digital Signing Service Implementation;

3. IDEHA-IG-SVC-SIG-001 Electronic Signature Service Implementation;

4. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Digital Signature Creation Data requirements;

2. Digital Signature Creation Device requirements;

3. cryptographic algorithms;

4. cryptographic parameters;

5. signature format structures;

6. Certificate issuance requirements;

7. Certificate Service requirements.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Signature scope

Article 2

1. An Electronic Signature shall be associated with identified electronic data and an identified signing context.

2. The Electronic Signature implementation shall identify:

1. the signed data;

2. the Signatory;

3. the signing event;

4. the Digital Signature where applicable;

5. the applicable Electronic Signature Profile.

3. The Electronic Signature shall remain associated with the signed data throughout its lifecycle.

Article 3

1. The applicable Electronic Signature Profile shall define:

1. the purpose of the Electronic Signature;

2. the applicable Signatory requirements;

3. the required evidence;

4. the applicable Assurance Conditions;

5. the applicable Security Conditions;

6. the applicable Validation requirements.

2. An Electronic Signature Profile shall not modify the Electronic Signature Categories or Controlled Effects established by the Main Framework.

Signatory identification and attribution

Article 4

1. The Electronic Signature implementation shall establish the relationship between the Electronic Signature and the Signatory.

2. The applicable Electronic Signature Profile shall specify:

1. Signatory identification requirements;

2. required Authentication conditions;

3. required evidence;

4. applicable identity binding requirements.

3. The Signatory reference shall remain separate from:

1. Digital Signature Identifier;

2. Trust Object Identifier;

3. Certificate Identifier;

4. Signature Value.

Article 5

1. The Electronic Signature shall provide evidence sufficient to determine the Signatory associated with the signing event.

2. Signatory attribution evidence shall identify, where applicable:

1. Signatory reference;

2. Authentication Event;

3. signing service interaction;

4. applicable Signature Profile;

5. signing time;

6. relevant limitations.

Signing act and intent

Article 6

1. The Electronic Signature implementation shall establish evidence of the signing act.

2. The signing act evidence shall identify, where applicable:

1. the Signatory action;

2. the signed data presented for signing;

3. the signing event;

4. the creation request;

5. the resulting Electronic Signature.

3. The applicable Profile shall define the required level of evidence.

Article 7

1. Where signing intent is required, the Electronic Signature implementation shall record evidence demonstrating that the Signatory intended to apply the Electronic Signature to the identified data.

2. Signing intent evidence may include:

1. explicit confirmation;

2. user interaction evidence;

3. transaction confirmation;

4. another approved indication.

3. Signing intent shall remain separate from:

1. Authentication;

2. Authorisation;

3. Digital Signature creation;

4. Certificate issuance.

Signed data association

Article 8

1. An Electronic Signature shall remain bound to the electronic data to which it relates.

2. The binding shall enable determination of:

1. the signed data;

2. the Electronic Signature;

3. the applicable Signature Profile;

4. the relevant creation context.

3. Any subsequent alteration of the signed data shall be detectable according to the applicable Validation requirements.

Article 9

1. The applicable Technical Specification shall define:

1. signed-data representation;

2. signature container format;

3. signature attributes;

4. encoding;

5. interoperability requirements.

2. This Guideline shall not define technical signature formats.

Advanced Electronic Signature implementation

Article 10

1. An Advanced Electronic Signature shall satisfy the conditions established by the Main Framework.

2. The applicable Electronic Signature Profile shall specify implementation requirements for:

1. unique association with the Signatory;

2. identification of the Signatory;

3. Signatory control over the signature creation process;

4. detection of subsequent alteration of signed data.

3. The implementation evidence shall support Validation of the applicable Advanced Electronic Signature conditions.

Qualified Electronic Signature implementation

Article 11

1. A Qualified Electronic Signature shall satisfy the conditions established by the Main Framework and the applicable Qualified Object Profile.

2. The applicable Qualified Object Profile shall identify:

1. required Advanced Electronic Signature conditions;

2. required Qualified Certificate;

3. required Qualified Digital Signature Creation Device;

4. required Validation conditions;

5. required preservation conditions where applicable.

3. The presence of:

1. a Qualified Certificate;

2. a Qualified Digital Signature Creation Device;

3. a Qualified Trust Service Provider;

shall not individually establish a Qualified Electronic Signature.

4. Qualified Status shall apply only where all applicable qualified conditions are satisfied.

Signature evidence

Article 12

1. The Electronic Signature implementation shall maintain evidence sufficient to support Validation.

2. Signature Evidence shall identify, where applicable:

1. signed data;

2. Signatory;

3. Digital Signature;

4. Certificate dependency;

5. creation time;

6. signing event;

7. applicable Profile;

8. Validation dependencies.

3. Signature Evidence shall be protected against unauthorised alteration.

Article 13

1. Where long-term reliance is required, the Electronic Signature shall support preservation of evidence required for Historical Validation.

2. Preservation evidence may include:

1. timestamps;

2. Certificate information;

3. Status information;

4. Validation results;

5. cryptographic transition information.

3. Preservation requirements shall be defined by the applicable Profile.

Electronic Signature lifecycle

Article 14

1. The lifecycle of an Electronic Signature shall include, where applicable:

1. creation;

2. delivery;

3. Validation;

4. preservation;

5. historical evaluation.

2. Lifecycle events affecting reliance shall be recorded.

Article 15

1. Changes affecting Electronic Signature dependencies shall be assessed where they may affect:

1. attribution;

2. Validation;

3. Historical State;

4. Controlled Reliance.

2. The assessment shall identify:

1. affected Electronic Signatures;

2. affected Certificates;

3. affected Digital Signature Creation Devices;

4. applicable transition measures.

Accessibility and safeguards

Article 16

1. Electronic Signature implementations shall provide Accessible Alternatives where required by the applicable Safeguard Conditions.

2. The applicable Profile shall define:

1. alternative signing methods;

2. assisted signing arrangements;

3. accessibility requirements;

4. human support conditions.

3. Accessibility measures shall preserve the applicable Assurance Conditions.

Records and evidence

Article 17

1. The responsible Actor shall maintain records sufficient to reconstruct:

1. signing request;

2. Signatory identification;

3. signing event;

4. Digital Signature creation reference;

5. Signature Evidence;

6. lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 18

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Signature Category;

2. Qualified Electronic Signature Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 102-1	Validation process requirements for electronic signatures
ETSI EN 319 122-1	CAdES signature representation requirements
ETSI EN 319 132-1	XAdES signature representation requirements
ETSI EN 319 142-1	PAdES signature representation requirements
ETSI TS 119 182-1	JAdES signature representation requirements
ETSI EN 319 312	Cryptographic suites where applicable
ETSI EN 319 411-2	Qualified certificate service requirements where qualified certificates are used
ISO/IEC 29115	Authentication assurance considerations for Signatory identification
ISO/IEC 24760 series	Identity information and identity binding considerations

IDEHA-IG-OBJ-SEL-001: Electronic Seal Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Seals within the Trust Framework.

2. This Guideline applies to Actors creating, managing, validating or relying upon Electronic Seals within the scope established by the applicable Framework Instruments.

3. This Guideline establishes requirements for:

1. Electronic Seal creation context;

2. Seal Creator attribution;

3. organisational authority and control;

4. sealing act implementation;

5. association between the Electronic Seal and sealed data;

6. Electronic Seal lifecycle management;

7. Seal Evidence management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

2. IDEHA-IG-SVC-DSG-001 Digital Signing Service Implementation;

3. IDEHA-IG-SVC-SEL-001 Electronic Seal Service Implementation;

4. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Digital Signature Creation Data requirements;

2. Digital Signature Creation Device requirements;

3. cryptographic algorithms;

4. cryptographic parameters;

5. certificate issuance requirements;

6. Certificate Service requirements;

7. seal format structures;

8. Seal Validation procedures.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Seal scope

Article 2

1. An Electronic Seal shall be associated with identified electronic data and an identified Seal Creator.

2. The Electronic Seal implementation shall identify:

1. the sealed data;

2. the Seal Creator;

3. the sealing event;

4. the Digital Signature where applicable;

5. the applicable Electronic Seal Profile.

3. The Electronic Seal shall remain associated with the sealed data throughout its lifecycle.

Article 3

1. The applicable Electronic Seal Profile shall define:

1. the purpose of the Electronic Seal;

2. the Seal Creator requirements;

3. the required evidence;

4. the applicable Assurance Conditions;

5. the applicable Security Conditions;

6. the applicable Validation requirements.

2. An Electronic Seal Profile shall not modify the Electronic Seal Categories or Controlled Effects established by the Main Framework.

Seal Creator identification and attribution

Article 4

1. The Electronic Seal implementation shall establish the relationship between the Electronic Seal and the Seal Creator.

2. The applicable Electronic Seal Profile shall specify:

1. Seal Creator identification requirements;

2. organisational identification requirements;

3. authority verification requirements;

4. required evidence.

3. The Seal Creator reference shall remain separate from:

1. Digital Signature Identifier;

2. Trust Object Identifier;

3. Certificate Identifier;

4. Signature Value.

Article 5

1. The Electronic Seal shall provide evidence sufficient to determine the organisational Actor associated with the sealing event.

2. Seal Creator attribution evidence shall identify, where applicable:

1. Seal Creator reference;

2. initiating Actor;

3. sealing authority;

4. sealing event;

5. applicable Electronic Seal Profile;

6. sealing time;

7. relevant limitations.

Organisational authority and control

Article 6

1. An Electronic Seal shall be created only where the Seal Creator has authority to apply the seal within the applicable scope.

2. The responsible Actor shall maintain evidence demonstrating:

1. identity of the Seal Creator;

2. authority to apply the Electronic Seal;

3. scope of authority;

4. validity period;

5. applicable limitations.

3. Authority to apply an Electronic Seal shall remain separate from:

1. Digital Signature creation;

2. Authentication;

3. Authorisation;

4. legal effect of the sealed data.

Article 7

1. Where sealing is performed automatically, the responsible Actor shall maintain evidence demonstrating:

1. the initiating system or process;

2. the applicable policy;

3. the authority permitting automated sealing;

4. the sealed-data determination;

5. the sealing event.

2. Automated sealing shall not remove the requirement to establish the Seal Creator.

Sealing act and evidence

Article 8

1. The Electronic Seal implementation shall establish evidence of the sealing act.

2. Sealing act evidence shall identify, where applicable:

1. the sealed data;

2. the Seal Creator;

3. the sealing request;

4. the sealing event;

5. the resulting Electronic Seal.

3. The applicable Profile shall define the required evidence level.

Article 9

1. The Electronic Seal shall remain bound to the electronic data to which it relates.

2. The binding shall enable determination of:

1. the sealed data;

2. the Electronic Seal;

3. the applicable Electronic Seal Profile;

4. the relevant creation context.

3. Any subsequent alteration of the sealed data shall be detectable according to the applicable Validation requirements.

Article 10

1. The applicable Technical Specification shall define:

1. sealed-data representation;

2. seal container format;

3. seal attributes;

4. encoding;

5. interoperability requirements.

2. This Guideline shall not define technical seal formats.

Advanced Electronic Seal implementation

Article 11

1. An Advanced Electronic Seal shall satisfy the conditions established by the Main Framework.

2. The applicable Electronic Seal Profile shall specify implementation requirements for:

1. unique association with the Seal Creator;

2. identification of the Seal Creator;

3. Seal Creator control over the seal creation process;

4. detection of subsequent alteration of sealed data.

3. The implementation evidence shall support Validation of the applicable Advanced Electronic Seal conditions.

Qualified Electronic Seal implementation

Article 12

1. A Qualified Electronic Seal shall satisfy the conditions established by the Main Framework and the applicable Qualified Object Profile.

2. The applicable Qualified Object Profile shall identify:

1. required Advanced Electronic Seal conditions;

2. required Qualified Certificate;

3. required Qualified Digital Signature Creation Device;

4. required Validation conditions;

5. preservation requirements where applicable.

3. The presence of:

1. a Qualified Certificate;

2. a Qualified Digital Signature Creation Device;

3. a Qualified Trust Service Provider;

shall not individually establish a Qualified Electronic Seal.

4. Qualified Status shall apply only where all applicable qualified conditions are satisfied.

Seal Evidence

Article 13

1. The Electronic Seal implementation shall maintain evidence sufficient to support Validation.

2. Seal Evidence shall identify, where applicable:

1. sealed data;

2. Seal Creator;

3. Digital Signature;

4. Certificate dependency;

5. sealing time;

6. sealing event;

7. applicable Profile;

8. Validation dependencies.

3. Seal Evidence shall be protected against unauthorised alteration.

Article 14

1. Where long-term reliance is required, the Electronic Seal shall support preservation of evidence required for Historical Validation.

2. Preservation evidence may include:

1. timestamps;

2. Certificate information;

3. Status information;

4. Validation results;

5. cryptographic transition information.

3. Preservation requirements shall be defined by the applicable Profile.

Electronic Seal lifecycle

Article 15

1. The lifecycle of an Electronic Seal shall include, where applicable:

1. creation;

2. delivery;

3. Validation;

4. preservation;

5. historical evaluation.

2. Lifecycle events affecting reliance shall be recorded.

Article 16

1. Changes affecting Electronic Seal dependencies shall be assessed where they may affect:

1. attribution;

2. Validation;

3. Historical State;

4. Controlled Reliance.

2. The assessment shall identify:

1. affected Electronic Seals;

2. affected Certificates;

3. affected Digital Signature Creation Devices;

4. applicable transition measures.

Accessibility and safeguards

Article 17

1. Electronic Seal implementations used for organisational processes shall maintain accessibility and safeguard requirements where natural persons interact with the sealing process.

2. The applicable Profile shall define:

1. human interaction requirements;

2. approval conditions;

3. accessibility requirements;

4. assisted operation conditions.

3. Accessibility measures shall preserve applicable Assurance Conditions.

Records and evidence

Article 18

1. The responsible Actor shall maintain records sufficient to reconstruct:

1. sealing request;

2. Seal Creator identification;

3. sealing authority;

4. sealing event;

5. Digital Signature creation reference;

6. Seal Evidence;

7. lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 19

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Seal Category;

2. Qualified Electronic Seal Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 102-1	Validation process requirements for electronic signatures and seals
ETSI EN 319 122-1	CAdES seal representation requirements
ETSI EN 319 132-1	XAdES seal representation requirements
ETSI EN 319 142-1	PAdES seal representation requirements
ETSI TS 119 182-1	JAdES seal representation requirements
ETSI EN 319 411-1	General policy requirements for certificate-issuing Trust Service Providers where certificates are used
ETSI EN 319 411-2	Qualified certificate issuing requirements where qualified seals are used
RFC 5280	Certificate validation and public-key certificate processing
ISO/IEC 24760 series	Identity information and organisational identity relationship considerations
ISO/IEC 27001:2022	Security management controls applicable to seal creation processes

IG14: Electronic Signature Service Implementation

IDEHA-IG-SVC-SIG-001 Version: 0.1

IDEHA-IG-OBJ-TST-001 Electronic Timestamp Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Timestamps and Qualified Electronic Timestamps within the Trust Framework.

2. This Guideline applies to Actors creating, managing, validating or relying upon Electronic Timestamps within the scope established by the applicable Framework Instruments.

3. This Guideline establishes requirements for:

1. Electronic Timestamp object identification;

2. binding of electronic data to an identified time;

3. timestamp evidence;

4. timestamp object lifecycle management;

5. dependencies required for Validation;

6. Qualified Electronic Timestamp object conditions.

4. This Guideline applies together with:

1. IDEHA-IG-SVC-TST-001 Electronic Timestamp Service Implementation;

2. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

3. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

4. IDEHA-IG-SEC-CRY-001 Cryptographic Controls and Cryptographic Agility Implementation;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Electronic Timestamp Service operation;

2. Trust Service Provider requirements;

3. time-source operation procedures;

4. clock synchronisation architecture;

5. cryptographic algorithm selection;

6. timestamp transport protocols;

7. signature format timestamp integration.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Timestamp scope

Article 2

1. An Electronic Timestamp shall establish a binding between identified electronic data and an identified time.

2. The Electronic Timestamp shall identify:

1. the referenced electronic data or data representation;

2. the generated time value;

3. the Timestamp Issuer;

4. the applicable Timestamp Profile;

5. the protection mechanism.

3. The Electronic Timestamp shall remain associated with the referenced electronic data throughout its lifecycle.

Article 3

1. The applicable Timestamp Profile shall define:

1. the purpose of the Electronic Timestamp;

2. the data reference method;

3. the required time accuracy;

4. the required evidence;

5. the applicable Validation conditions;

6. the applicable Security Conditions.

2. A Timestamp Profile shall not modify the Electronic Timestamp Category or Controlled Effects established by the Main Framework.

Timestamp data binding

Article 4

1. An Electronic Timestamp shall identify the electronic data to which the time value applies.

2. The data binding shall enable determination of:

1. the referenced electronic data;

2. the applied data representation;

3. the time value;

4. the Timestamp Issuer;

5. the applicable Profile.

3. The Electronic Timestamp shall not require disclosure of the original electronic data where a protected data reference is used.

Article 5

1. Where a digest or equivalent data reference is used, the applicable Technical Specification shall define:

1. the data-reference representation;

2. the permitted cryptographic mechanisms;

3. the encoding;

4. interoperability requirements.

2. A digest or data reference shall not by itself establish the legal meaning, ownership or validity of the referenced data.

Time information

Article 6

1. An Electronic Timestamp shall contain or reference an identified time value.

2. The time information shall identify, where applicable:

1. generation time;

2. time precision;

3. time accuracy;

4. applicable time reference;

5. uncertainty information.

3. The interpretation of time information shall be defined by the applicable Timestamp Profile.

Article 7

1. The Electronic Timestamp shall provide evidence sufficient to determine the relationship between:

1. the referenced electronic data;

2. the identified time;

3. the Timestamp Issuer;

4. the applicable Timestamp Profile.

2. Timestamp evidence shall remain available for Validation according to the applicable lifecycle requirements.

Timestamp protection

Article 8

1. An Electronic Timestamp shall be protected against unauthorised alteration.

2. Protection mechanisms shall ensure:

1. integrity of the timestamp information;

2. authenticity of the Timestamp Issuer;

3. detection of modification.

3. The protection mechanism shall remain separate from the Timestamp Category.

Article 9

1. Where an Electronic Timestamp depends on another Trust Object, the dependency shall be identified.

2. Dependencies may include:

1. Certificate;

2. Electronic Signature;

3. Electronic Seal;

4. Trust List information;

5. other Validation evidence.

3. A dependency shall not transfer its Status, Qualified Status or Controlled Effects to the Electronic Timestamp.

Qualified Electronic Timestamp

Article 10

1. A Qualified Electronic Timestamp shall satisfy the requirements established by the Main Framework and the applicable Qualified Object Profile.

2. The Qualified Object Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required time conditions;

4. required protection conditions;

5. required Validation conditions;

6. required evidence.

3. Qualification of the Electronic Timestamp Service shall not automatically qualify every Electronic Timestamp issued by that service.

4. Qualified Status shall apply only where all applicable qualified conditions are satisfied.

Validation support

Article 11

1. An Electronic Timestamp shall support Validation according to the applicable Validation requirements.

2. Validation support shall enable determination of:

1. timestamp integrity;

2. Timestamp Issuer identity;

3. referenced data binding;

4. time information;

5. protection validity;

6. Status information;

7. Historical State.

3. Validation requirements shall be implemented through the Validation and Verification Service Implementation.

Article 12

1. An Electronic Timestamp shall not by itself establish:

1. ownership of the referenced data;

2. legal validity of the referenced data;

3. Authorisation;

4. approval;

5. consent;

6. any fact expressed by the referenced data.

2. Reliance upon an Electronic Timestamp shall consider:

1. purpose;

2. Profile;

3. Status;

4. Validation Result;

5. applicable Reliance Conditions.

Timestamp lifecycle

Article 13

1. The lifecycle of an Electronic Timestamp shall include, where applicable:

1. creation;

2. issuance;

3. Validation;

4. preservation;

5. historical evaluation.

2. Lifecycle information affecting reliance shall be recorded.

Article 14

1. Changes affecting Electronic Timestamp dependencies shall be assessed where they may affect:

1. integrity;

2. Validation;

3. Historical State;

4. Controlled Reliance.

2. The assessment shall identify:

1. affected Electronic Timestamps;

2. affected Certificates;

3. affected cryptographic dependencies;

4. applicable transition measures.

Preservation and long-term reliance

Article 15

1. Where long-term reliance is required, the Electronic Timestamp shall support preservation of evidence necessary for Historical Validation.

2. Preservation evidence may include:

1. timestamp evidence;

2. Certificate information;

3. Status information;

4. Validation evidence;

5. cryptographic transition information.

3. Long-term preservation requirements shall be defined by the applicable Profile.

Records and evidence

Article 16

1. The responsible Actor shall maintain records sufficient to reconstruct:

1. timestamp creation;

2. referenced data binding;

3. Timestamp Issuer;

4. timestamp dependencies;

5. lifecycle events;

6. Validation history.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 17

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Timestamp Category;

2. Qualified Electronic Timestamp Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 422	Timestamp token and protocol profile requirements
RFC 3161	Time-Stamp Protocol
RFC 5816	ESSCertIDv2 update for timestamp token certificate identification
RFC 5280	Certificate validation where timestamp certificates are used
ETSI EN 319 102-1	Validation process requirements applicable to timestamps
ISO/IEC 18014-4	Traceability of time sources where applicable
ISO 8601-1:2019	Date and time representation

IDEHA-IG-SVC-TSP-001: Trust Service Provider and Trust Service Common Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements applicable to Trust Service Providers and Trust Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers responsible for providing one or more Trust Services within the scope established by the applicable Framework Instruments.

3. This Guideline establishes common implementation requirements for:

1. Trust Service Provider governance;

2. Trust Service inventory and separation;

3. Trust Service operational management;

4. service documentation and evidence;

5. service lifecycle management;

6. common security and continuity arrangements;

7. dependencies between Trust Services.

4. This Guideline applies together with the applicable Trust Service-specific Implementation Guideline.

5. This Guideline does not establish:

1. Trust Service Categories;

2. Trust Service Provider Status;

3. Qualified Trust Service Provider Status;

4. Qualified Trust Service Status;

5. Service Permission;

6. Qualification decisions;

7. Humanitarian Trust List governance;

8. service-specific technical requirements.

Those matters shall be implemented through the applicable Framework Instruments.

Trust Service Provider operational identity

Article 2

1. A Trust Service Provider shall maintain operational information identifying its Trust Service Provider functions.

2. The operational information shall identify:

1. Trust Service Provider Identifier;

2. organisational information;

3. applicable Provider Scope;

4. responsible governance functions;

5. provided Trust Services;

6. applicable Service Permissions;

7. lifecycle information.

3. The Trust Service Provider Identifier shall remain separate from:

1. Trust Service Identifier;

2. Certificate Identifier;

3. Service Digital Identity;

4. Trust Object Identifier.

Trust Service inventory and separation

Article 3

1. A Trust Service Provider shall maintain an inventory of Trust Services provided under the Trust Framework.

2. The Trust Service inventory shall identify:

1. Trust Service Identifier;

2. Trust Service Category;

3. Service Scope;

4. applicable Profiles;

5. applicable Technical Specifications;

6. applicable Standards;

7. operational Status.

3. Each Trust Service shall remain separately identifiable.

4. A Trust Service Provider shall not:

1. merge separate Trust Services into one service identity;

2. use one Service Identifier for different Trust Services;

3. assume that qualification of one Trust Service applies to another Trust Service.

Article 4

1. A Trust Service Provider providing multiple Trust Services shall maintain separation between:

1. service governance;

2. service operation;

3. service evidence;

4. service dependencies;

5. service lifecycle.

2. The separation shall be sufficient to determine the scope of each Trust Service independently.

Trust Service documentation

Article 5

1. A Trust Service Provider shall maintain documentation necessary for operation and reliance upon each Trust Service.

2. The documentation shall identify, where applicable:

1. Trust Service description;

2. Service Scope;

3. applicable Profiles;

4. applicable Technical Specifications;

5. applicable Standards;

6. operational limitations;

7. security conditions;

8. evidence requirements.

3. Service documentation shall remain consistent with the applicable Framework Instruments.

Article 6

1. A Trust Service Provider shall maintain service practice information sufficient to demonstrate how each Trust Service is operated.

2. The practice information shall include, where applicable:

1. responsibilities;

2. operational procedures;

3. security controls;

4. incident handling arrangements;

5. continuity arrangements;

6. evidence retention requirements.

3. Service practice information shall not modify requirements established by the Main Framework or applicable Profiles.

Trust Service operation

Article 7

1. A Trust Service Provider shall operate each Trust Service within its assigned Service Scope.

2. The Trust Service Provider shall ensure that each Trust Service:

1. performs only permitted functions;

2. applies applicable Profiles;

3. applies applicable Technical Specifications;

4. maintains required evidence;

5. supports applicable Validation requirements.

3. A Trust Service Provider shall not perform functions outside the approved scope of a Trust Service.

Article 8

1. A Trust Service Provider shall maintain records of Trust Service operations.

2. Operational records shall identify, where applicable:

1. service requests;

2. service outputs;

3. processing events;

4. Status changes;

5. security events;

6. lifecycle events.

3. Operational records shall enable reconstruction of relevant service activities.

Dependencies and supporting functions

Article 9

1. A Trust Service Provider shall identify dependencies required for operation of each Trust Service.

2. Dependencies may include:

1. Sources;

2. Trust Objects;

3. Certificates;

4. Validation Services;

5. Electronic Timestamp Services;

6. Cryptographic mechanisms;

7. supporting Actors.

3. Dependency information shall identify:

1. dependency purpose;

2. applicable scope;

3. required Status;

4. applicable Validation conditions.

4. A dependency shall not transfer its Status or Qualified Status to the Trust Service.

Security and confidentiality

Article 10

1. A Trust Service Provider shall implement security measures appropriate to the Trust Services provided.

2. Security measures shall address, where applicable:

1. confidentiality;

2. integrity;

3. availability;

4. authenticity;

5. accountability;

6. access control;

7. monitoring.

3. Security requirements specific to a Trust Service shall be established by the applicable Trust Service-specific Implementation Guideline.

Personnel and supporting Actors

Article 11

1. A Trust Service Provider shall define responsibilities for persons and supporting Actors involved in Trust Service operation.

2. Responsibilities shall identify:

1. assigned functions;

2. access permissions;

3. competence requirements;

4. segregation requirements;

5. accountability arrangements.

3. Supporting Actors shall operate only within the scope assigned by the Trust Service Provider.

Incident response and continuity

Article 12

1. A Trust Service Provider shall maintain arrangements for:

1. incident detection;

2. incident response;

3. service continuity;

4. Recovery;

5. evidence preservation.

2. Incident and continuity arrangements shall identify:

1. responsible functions;

2. notification conditions;

3. affected Trust Services;

4. Recovery conditions.

3. Service-specific incident requirements shall be established by the applicable Implementation Guideline.

Trust Service lifecycle management

Article 13

1. A Trust Service Provider shall manage the lifecycle of each Trust Service.

2. The lifecycle shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. withdrawal;

8. cessation.

3. Lifecycle changes shall be recorded.

Article 14

1. Before implementing a material change affecting a Trust Service, the Trust Service Provider shall assess:

1. affected Service Scope;

2. affected Profiles;

3. affected Technical Specifications;

4. affected Standards;

5. affected dependencies;

6. impact on reliance.

2. Material changes shall be managed according to the applicable Change Control requirements.

Qualification support

Article 15

1. Where a Trust Service Provider seeks Qualified Status for a Trust Service, it shall prepare evidence according to the applicable Qualified Profile.

2. Evidence shall identify:

1. Trust Service scope;

2. applicable requirements;

3. conformity evidence;

4. assessment results;

5. limitations.

3. Preparation of qualification evidence shall not create Qualified Status.

4. Qualified Status shall arise only through the applicable Framework decision route.

Records and evidence

Article 16

1. A Trust Service Provider shall maintain records sufficient to reconstruct:

1. Trust Service establishment;

2. service operation;

3. service dependencies;

4. service changes;

5. security events;

6. qualification evidence where applicable.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 17

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Trust Service Category;

2. Trust Service Status;

3. Qualified Trust Service Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 401	General policy requirements for Trust Service Providers
ISO/IEC 27001:2022	Information security management controls applicable to Trust Service operation
ISO/IEC 27002:2022	Security control implementation guidance
ISO/IEC 27701:2025	Privacy information management where personal data processing is performed
ISO 22301:2019	Business continuity management where continuity requirements apply
ISO/IEC 20000-1:2018	Service management controls where service-management processes are applied

IDEHA-IG-SVC-IDN-001: Identification Service Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Identification Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Identification Services and Actors performing Identification Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Identity Proofing;

2. Identity Registration;

3. maintenance of Identity Registration Records;

4. Identifier allocation and management;

5. Identity Resolution;

6. identity lifecycle management;

7. Identification Results.

4. This Guideline applies together with:

1. IDEHA-IG-SRC-ASO-001 Source and Authoritative Source Implementation;

2. IDEHA-IG-DAT-SEM-001 Controlled Data Elements, Semantics and Data Quality Implementation;

3. IDEHA-IG-BIO-GEN-001 Biometric Implementation Controls;

4. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

5. IDEHA-IG-SVC-EAS-001 Electronic Attestation Service Implementation;

6. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. civil registration authority;

2. legal identity creation;

3. Source authority;

4. Electronic Attestation issuance;

5. Authentication Service operation;

6. Authorisation decisions;

7. biometric technical formats;

8. technical data exchange protocols.

Those matters shall be implemented through the applicable Framework Instruments.

Identification Service scope

Article 2

1. An Identification Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. Subject categories;

2. permitted Identification Service Functions;

3. applicable Sources;

4. applicable Profiles;

5. applicable Assurance Conditions;

6. applicable Security Conditions;

7. applicable jurisdictions or operational domains.

3. An Identification Service shall not perform functions outside its approved Service Scope.

Article 3

1. The Identification Service shall distinguish between:

1. identity evidence;

2. identity information;

3. Identity Registration Records;

4. Identification Results;

5. Identity Resolution Results.

2. The Identification Service shall maintain separation between:

1. the registered identity representation;

2. the evidence used to establish that representation;

3. the Source providing the evidence;

4. outputs produced by the Identification Service.

Identity Proofing

Article 4

1. Identity Proofing shall establish confidence that identity information relates to the identified Subject.

2. Identity Proofing shall evaluate:

1. identity evidence;

2. Source information;

3. biographic information;

4. biometric information where applicable;

5. demographic information where applicable;

6. other permitted evidence.

3. The applicable Profile shall define:

1. accepted evidence types;

2. evidence quality requirements;

3. verification methods;

4. assurance conditions;

5. failure and exception handling.

Article 5

1. The Identification Service shall record evidence supporting an Identity Proofing result.

2. The evidence record shall identify, where applicable:

1. evidence type;

2. evidence Source;

3. collection method;

4. verification method;

5. processing time;

6. responsible Actor;

7. outcome.

3. Evidence used for Identity Proofing shall remain attributable to its Source and shall not become a new Source solely through use by the Identification Service.

Identity Registration

Article 6

1. Identity Registration shall establish and maintain an Identity Registration Record for a registered Subject.

2. An Identity Registration Record shall contain or reference, where applicable:

1. biographic data;

2. biometric data;

3. demographic data;

4. allocated Identification Number;

5. family relationship information;

6. contact details;

7. identification document details;

8. registration evidence;

9. lifecycle information.

3. The applicable Profile shall define the permitted data elements, retention conditions and reuse conditions.

Article 7

1. The Identification Service shall ensure that Identity Registration Records maintain:

1. provenance;

2. Data Quality information;

3. Source references;

4. correction history;

5. lifecycle information.

2. Information contained in an Identity Registration Record shall remain distinguishable according to its origin and purpose.

3. Derived information shall identify:

1. source information;

2. derivation method;

3. responsible processing function;

4. applicable Version.

Identification Number

Article 8

1. An Identification Service assigning an Identification Number shall maintain an Identifier namespace.

2. An Identification Number shall:

1. uniquely identify the Subject within the applicable namespace;

2. remain stable during the applicable lifecycle;

3. remain separate from identity Attributes;

4. remain separate from Trust Object Identifiers.

3. An Identification Number shall not:

1. disclose identity type;

2. disclose demographic information;

3. disclose jurisdictional meaning unless required by the identifier scheme;

4. encode Status or qualification information.

4. The applicable Profile shall define:

1. generation method;

2. uniqueness scope;

3. non-reuse conditions;

4. lifecycle treatment.

Identity Resolution

Article 9

1. Identity Resolution shall determine whether identity information refers to:

1. an existing Identity Registration Record;

2. a different Identity Registration Record;

3. an unresolved identity state.

2. Identity Resolution shall consider:

1. available identity information;

2. applicable matching rules;

3. permitted biometric comparison where applicable;

4. confidence thresholds;

5. human review requirements.

3. Identity Resolution shall not create a legal identity or alter Source records.

Article 10

1. Where automated matching is used, the Identification Service shall maintain evidence of:

1. matching method;

2. algorithm Version;

3. thresholds;

4. input data;

5. result;

6. limitations.

2. The applicable Profile shall define requirements for:

1. false match risk;

2. false non-match risk;

3. demographic performance;

4. human review.

Biographic, biometric and demographic data

Article 11

1. The Identification Service shall process biographic, biometric and demographic data according to the applicable Profile.

2. The applicable Profile shall identify:

1. permitted data elements;

2. collection conditions;

3. Source requirements;

4. quality requirements;

5. retention conditions;

6. reuse conditions.

3. Biometric data shall be processed according to the applicable Biometric Implementation requirements.

4. Demographic data shall remain separate from:

1. Identification Number;

2. Subject Identifier;

3. Trust Object Identifier.

Identity Registration Record lifecycle

Article 12

1. The Identification Service shall manage the lifecycle of Identity Registration Records.

2. Lifecycle management shall include, where applicable:

1. creation;

2. update;

3. correction;

4. suspension;

5. recovery;

6. closure;

7. historical preservation.

3. Lifecycle events shall identify:

1. responsible Actor;

2. effective time;

3. reason;

4. supporting evidence.

Article 13

1. Corrections to Identity Registration Records shall preserve sufficient evidence to reconstruct:

1. previous information;

2. correction basis;

3. responsible Actor;

4. effective time.

2. A correction shall not remove historical information required for accountability or Historical State determination.

Identification Results

Article 14

1. An Identification Service shall produce an Identification Result where an Identification Service Function produces an outcome intended for use by another Actor.

2. An Identification Result shall identify, where applicable:

1. Subject reference;

2. Identification Service;

3. evaluated evidence basis;

4. Assurance Conditions;

5. evaluation time;

6. limitations.

3. An Identification Result shall not:

1. create legal identity;

2. create Source authority;

3. create Authorisation;

4. create entitlement.

Article 15

1. An Identity Resolution Result shall identify, where applicable:

1. evaluated records;

2. resolution method;

3. confidence information;

4. limitations;

5. evaluation time.

2. An Identity Resolution Result shall remain separate from an Identification Result.

Reuse and disclosure

Article 16

1. Identity Registration Record information shall be reused only within the conditions established by the applicable Profile.

2. Reuse conditions shall consider:

1. purpose;

2. Service Scope;

3. Source Basis;

4. Freshness Condition;

5. Assurance Conditions;

6. disclosure restrictions.

3. The Identification Service shall not disclose Identity Registration Record information beyond the authorised scope.

Security and safeguards

Article 17

1. The Identification Service shall protect Identity Registration Records and related evidence against:

1. unauthorised access;

2. unauthorised modification;

3. unauthorised disclosure;

4. loss of integrity.

2. Access shall be controlled through:

1. Authentication;

2. Authorisation;

3. purpose restrictions;

4. audit requirements.

3. Protected-Person Safeguards and Accessible Alternatives shall apply where required.

Records and evidence

Article 18

1. The Identification Service shall maintain records sufficient to reconstruct:

1. Identity Proofing;

2. Identity Registration;

3. Identity Resolution;

4. Identifier allocation;

5. corrections;

6. lifecycle changes;

7. Identification Results.

2. Records shall identify:

1. responsible Actor;

2. Source Basis;

3. processing method;

4. applicable Profile Version.

Applicable standards

Article 19

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. identity;

2. Source authority;

3. Identification Service Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ISO/IEC 24760-1:2025	Identity concepts, identity information and Identifier principles
ISO/IEC 24760-2:2025	Identity-management architecture considerations
ISO/IEC 24760-3:2025	Identity-management operational processes
ETSI TS 119 461 V2.1.1	Identity proofing requirements where used for trust-service-related identity verification
ISO/IEC TS 29003:2018	Identity-proofing guidance
NIST SP 800-63A-4	Identity proofing and enrolment controls
ISO/IEC 11179-31:2023	Data-element concepts and semantic descriptions
ISO/IEC 25012:2008	Data quality model
ISO/IEC 25024:2015	Data quality measurement
ISO 15489-1:2016	Records management principles
ISO 23081-1:2017	Records metadata principles
ISO/IEC 24745:2022	Biometric information protection where biometric data is processed

IDEHA-IG-SVC-AUT-001: Authentication Service Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Authentication Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Authentication Services and Actors performing Authentication functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Subject Authentication;

2. System Authentication;

3. Authentication Mechanisms;

4. Authenticators;

5. Authentication Events;

6. Authentication Outcomes;

7. session and reauthentication management.

4. This Guideline applies together with:

1. IDEHA-IG-SVC-IDN-001 Identification Service Implementation;

2. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

3. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation where cryptographic Authenticators are used;

4. IDEHA-IG-SEC-CRY-001 Cryptographic Controls and Cryptographic Agility Implementation;

5. IDEHA-IG-BIO-GEN-001 Biometric Implementation Controls where biometric Authenticators are used;

6. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. identity;

2. Identity Proofing;

3. Identity Registration;

4. Authorisation;

5. Electronic Signature;

6. Electronic Seal;

7. Trust Object issuance;

8. access policy decisions;

9. cryptographic algorithm selection.

Those matters shall be implemented through the applicable Framework Instruments.

Authentication Service scope

Article 2

1. An Authentication Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. authenticated Subject or entity categories;

2. permitted Authentication Mechanisms;

3. supported Authenticators;

4. applicable Assurance Conditions;

5. applicable Security Conditions;

6. applicable Profiles;

7. applicable Technical Specifications.

3. An Authentication Service shall not perform functions outside its approved Service Scope.

Article 3

1. An Authentication Service shall distinguish between:

1. Authentication;

2. Authentication Mechanism;

3. Authenticator;

4. Authentication Event;

5. Authentication Outcome.

2. The Authentication Service shall maintain separation between:

1. identity information used for Authentication;

2. Authentication evidence;

3. Authentication decision;

4. Authorisation decision.

3. A successful Authentication Event shall not by itself create Authorisation.

Authentication Mechanisms

Article 4

1. An Authentication Service shall use Authentication Mechanisms appropriate to the applicable Assurance Conditions.

2. An Authentication Mechanism shall define:

1. authenticated entity;

2. authentication method;

3. required inputs;

4. required evidence;

5. security conditions;

6. failure conditions.

3. The applicable Authentication Profile shall specify:

1. permitted mechanisms;

2. assurance level;

3. factor requirements;

4. replay resistance requirements;

5. phishing resistance requirements where applicable.

Article 5

1. Authentication Mechanisms may include:

1. knowledge factors;

2. possession factors;

3. inherence factors;

4. cryptographic Authenticators;

5. device-based Authenticators;

6. service or system authentication mechanisms.

2. The applicable Profile shall determine the permitted combination of factors.

3. A biometric characteristic shall not by itself constitute an Authenticator unless explicitly permitted by the applicable Profile.

Authenticators

Article 6

1. An Authenticator shall be uniquely associated with the authenticated Subject or entity within the applicable scope.

2. Authenticator information shall identify:

1. Authenticator Identifier;

2. associated Subject or entity reference;

3. Authenticator type;

4. activation conditions;

5. lifecycle Status;

6. effective period.

3. An Authenticator Identifier shall:

1. remain opaque;

2. not disclose identity type;

3. not disclose personal information;

4. remain separate from Subject Identifier and Trust Object Identifier.

Article 7

1. The Authentication Service shall manage the Authenticator lifecycle.

2. Lifecycle management shall include:

1. issuance;

2. binding;

3. activation;

4. use;

5. suspension;

6. replacement;

7. revocation;

8. recovery;

9. termination.

3. Lifecycle events affecting Authentication assurance shall be recorded.

Subject Authentication

Article 8

1. Subject Authentication shall determine whether the identified Subject successfully demonstrates control of an approved Authenticator.

2. Subject Authentication shall evaluate:

1. Authentication request;

2. Authenticator status;

3. Authentication mechanism;

4. required factors;

5. security conditions.

3. Subject Authentication shall not establish:

1. identity;

2. legal capacity;

3. entitlement;

4. Authorisation.

Article 9

1. Where Subject Authentication uses a cryptographic Authenticator, the Authentication Service shall verify:

1. possession or control of the cryptographic material;

2. integrity of the Authentication response;

3. freshness of the Authentication Event;

4. applicable certificate or key status where relevant.

2. Cryptographic key lifecycle requirements shall be established through the applicable Cryptographic Controls requirements.

System Authentication

Article 10

1. System Authentication shall determine whether a system, service, device or Endpoint is authenticated within the applicable scope.

2. System Authentication may apply to:

1. information systems;

2. services;

3. applications;

4. devices;

5. workloads;

6. gateways;

7. Endpoints.

3. System Authentication shall identify:

1. authenticated system or entity;

2. authentication mechanism;

3. credential or certificate reference;

4. Authentication Event;

5. applicable Security Conditions.

Article 11

1. A system Authentication Credential shall remain separate from:

1. Subject Authentication credentials;

2. Authorisation credentials;

3. Trust Service Identifier;

4. Trust Object Identifier.

2. A system successfully authenticated shall not automatically receive permission to access a resource.

3. Authorisation shall be determined through the applicable Authorisation Service.

Biometric Authentication

Article 12

1. Where biometric information contributes to Authentication, the Authentication Service shall apply the applicable Biometric Implementation requirements.

2. Biometric Authentication shall consider:

1. biometric sample quality;

2. biometric reference protection;

3. presentation attack detection;

4. applicable performance requirements;

5. accessibility conditions.

3. A biometric comparison result shall not independently establish identity or Authorisation.

Authentication Events

Article 13

1. Each Authentication Event shall be uniquely identifiable within the applicable scope.

2. An Authentication Event record shall identify:

1. Authentication Event Identifier;

2. authenticated Subject or entity;

3. Authentication Mechanism;

4. Authenticator used;

5. Authentication time;

6. result;

7. Assurance Conditions achieved;

8. limitations.

3. Authentication Event information shall be protected according to applicable Security Conditions.

Article 14

1. An Authentication Event shall remain associated with the conditions under which it occurred.

2. The Authentication Service shall record:

1. successful Authentication;

2. failed Authentication;

3. rejected Authentication;

4. restricted Authentication;

5. step-up Authentication where applicable.

3. Authentication evidence shall be retained according to the applicable Profile.

Authentication Outcomes

Article 15

1. An Authentication Service shall produce an Authentication Outcome following an Authentication Event.

2. An Authentication Outcome shall identify:

1. authenticated Subject or entity;

2. Authentication Service;

3. Authentication Mechanism;

4. achieved Assurance Conditions;

5. Authentication time;

6. validity period;

7. limitations.

3. An Authentication Outcome shall remain separate from:

1. Authorisation Outcome;

2. Electronic Attestation;

3. Electronic Signature.

Article 16

1. An Authentication Outcome shall support Verification and Validation.

2. Validation shall determine, where applicable:

1. Authentication Service Status;

2. Authenticator Status;

3. Authentication Mechanism;

4. Assurance Conditions;

5. validity period;

6. Historical State.

3. An Authentication Outcome shall not establish Authorisation.

Session and reauthentication management

Article 17

1. Where an Authentication Service establishes a session, the session shall be associated with the applicable Authentication Outcome.

2. Session management shall define:

1. session identifier;

2. session validity period;

3. inactivity conditions;

4. reauthentication conditions;

5. termination conditions.

3. A session shall not provide a higher assurance level than the Authentication Event that established it.

Article 18

1. Reauthentication shall be required where:

1. the applicable Profile requires it;

2. the session exceeds its permitted period;

3. risk conditions change;

4. the requested operation requires additional assurance.

2. Step-up Authentication shall establish a new Authentication Outcome or update the existing outcome according to the applicable Profile.

Failure, recovery and replacement

Article 19

1. The Authentication Service shall maintain procedures for:

1. failed Authentication;

2. Authenticator recovery;

3. Authenticator replacement;

4. compromised Authenticator handling.

2. Recovery and replacement processes shall provide assurance equivalent to the intended Authentication use unless the applicable Profile establishes another condition.

Security and safeguards

Article 20

1. The Authentication Service shall protect Authentication information against:

1. unauthorised access;

2. credential compromise;

3. replay;

4. impersonation;

5. unauthorised disclosure.

2. Security controls shall include, where applicable:

1. monitoring;

2. anomaly detection;

3. rate limitation;

4. audit records;

5. incident response.

Records and evidence

Article 21

1. The Authentication Service shall maintain records sufficient to reconstruct:

1. Authentication Events;

2. Authentication Outcomes;

3. Authenticator lifecycle;

4. failed Authentication attempts;

5. recovery actions;

6. security events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 22

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. identity;

2. Authorisation;

3. Trust Object Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
NIST SP 800-63B-4	Authentication and Authenticator management requirements
ISO/IEC 29115:2013	Entity Authentication Assurance framework
ISO/IEC 9798-1:2010	Entity Authentication framework
ISO/IEC 9798-2:2019	Symmetric cryptographic Authentication mechanisms
ISO/IEC 9798-3:2019	Public-key cryptographic Authentication mechanisms
RFC 5280	Certificate validation where certificate-based Authentication is used
RFC 9525	Service identity verification in TLS
RFC 8446	TLS 1.3 protected communication
ISO/IEC 24745:2022	Biometric information protection
ISO/IEC 30107-1:2023	Presentation attack detection framework
ISO/IEC 30107-3:2023	Presentation attack detection testing
ISO/IEC 19795-1:2021	Biometric performance testing

IDEHA-IG-SVC-AUZ-001: Authorisation Service Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Authorisation Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Authorisation Services and Actors performing Authorisation functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Authorisation Policy management;

2. Authorisation request processing;

3. policy evaluation;

4. Authorisation decision generation;

5. Authorisation Outcome management;

6. enforcement coordination;

7. lifecycle management of Authorisation decisions.

4. This Guideline applies together with:

1. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

2. IDEHA-IG-ACT-PAR-001 Participation, Roles, Mandates and Representation Implementation;

3. IDEHA-IG-SRC-ASO-001 Source and Authoritative Source Implementation;

4. IDEHA-IG-SVC-FDX-001 Federated Data Exchange Service Implementation where Authorisation applies to data exchange;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. identity;

2. Authentication;

3. Identity Proofing;

4. Identity Registration;

5. Source authority;

6. legal rights or entitlements;

7. data-sharing agreements;

8. cryptographic mechanisms;

9. access-token formats;

10. protocol bindings.

Those matters shall be implemented through the applicable Framework Instruments.

Authorisation Service scope

Article 2

1. An Authorisation Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted Authorisation functions;

2. Actor categories;

3. Controlled Matters subject to evaluation;

4. applicable Policies;

5. applicable Profiles;

6. applicable Assurance Conditions;

7. applicable Security Conditions.

3. An Authorisation Service shall not perform functions outside its approved Service Scope.

Article 3

1. An Authorisation Service shall distinguish between:

1. Authentication Outcome;

2. Authorisation Request;

3. Authorisation Policy;

4. Authorisation Decision;

5. Authorisation Outcome;

6. Policy Enforcement.

2. A successful Authentication Event shall not by itself establish Authorisation.

3. An Authorisation Outcome shall not establish identity, Source authority, legal capacity or entitlement unless such matters are determined by another applicable Framework Instrument.

Authorisation architecture

Article 4

1. An Authorisation Service shall maintain functions necessary for policy-based evaluation.

2. The functions may include:

1. Policy Administration Function;

2. Policy Decision Function;

3. Policy Information Function;

4. Policy Enforcement Function.

3. The applicable Profile shall define the functions required for each implementation context.

Article 5

1. The Policy Administration Function shall manage Authorisation Policies.

2. Policy administration shall include:

1. creation;

2. approval;

3. publication;

4. modification;

5. suspension;

6. withdrawal;

7. version management.

3. Policy administration shall remain separate from Policy evaluation.

Authorisation Policies

Article 6

1. An Authorisation Policy shall define conditions under which an Action may be permitted, denied or restricted.

2. An Authorisation Policy shall identify, where applicable:

1. Policy Identifier;

2. Policy Version;

3. Policy Owner;

4. applicable Actors;

5. Controlled Matters;

6. permitted Actions;

7. purposes;

8. required Attributes;

9. obligations;

10. restrictions;

11. validity period.

3. An Authorisation Policy shall operate only within the scope assigned by the responsible Actor.

Article 7

1. An Authorisation Policy shall not:

1. create a Subject identity;

2. create a Role;

3. create a Mandate;

4. create a Source authority;

5. create a legal entitlement.

2. Where a Policy requires Roles, Mandates, Attributes or Source information, those inputs shall be obtained from applicable authoritative functions.

Authorisation Request

Article 8

1. An Authorisation Request shall identify the requested Action and the Controlled Matter to which the Action applies.

2. An Authorisation Request shall contain, where applicable:

1. requesting Actor;

2. represented Subject where applicable;

3. recipient;

4. Controlled Matter;

5. requested Action;

6. Purpose;

7. Authentication Outcome reference;

8. Role or Mandate reference;

9. applicable consent reference where applicable;

10. contextual information.

3. The applicable Technical Specification shall define the technical representation of Authorisation Requests.

Article 9

1. Before evaluation, the Authorisation Service shall verify that the Authorisation Request is complete and within the Service Scope.

2. The verification shall determine:

1. presence of required information;

2. validity of references;

3. applicability of the requested Action;

4. applicability of the requested Controlled Matter.

Policy evaluation

Article 10

1. The Policy Decision Function shall evaluate the Authorisation Request against the applicable Authorisation Policy.

2. The evaluation shall consider, where applicable:

1. Actor Attributes;

2. Subject Attributes;

3. Role information;

4. Mandate information;

5. Source information;

6. Authentication Assurance;

7. Purpose;

8. environmental conditions;

9. security conditions.

3. The evaluation result shall be recorded as an Authorisation Decision.

Article 11

1. Where required information is unavailable, invalid or insufficient, the Authorisation Decision shall not result in an unauthorised Permit.

2. The Authorisation Service shall identify, where applicable:

1. missing information;

2. unavailable Sources;

3. expired conditions;

4. unresolved conflicts;

5. policy limitations.

3. An inability to determine Authorisation shall remain distinguishable from a Deny decision.

Roles, Mandates and delegated authority

Article 12

1. An Authorisation Service may evaluate Roles, Mandates and representation information as decision inputs.

2. The evaluation shall determine:

1. existence of the Role or Mandate;

2. applicable scope;

3. validity period;

4. restrictions;

5. relationship to the requested Action.

3. A Role or Mandate used in an Authorisation decision shall not be expanded beyond its assigned scope.

Article 13

1. A delegated authority shall be evaluated against:

1. delegating Actor;

2. delegated Actor;

3. delegated scope;

4. permitted Actions;

5. validity period;

6. revocation conditions.

2. Delegation shall not permit an Actor to grant authority exceeding the authority available to that Actor.

Consent and purpose conditions

Article 14

1. Where consent is applicable, the Authorisation Service may evaluate consent information as an Authorisation input.

2. Consent information shall identify, where applicable:

1. consenting Subject;

2. receiving Actor;

3. permitted data or Controlled Matter;

4. purpose;

5. validity period;

6. withdrawal status;

7. limitations.

3. Consent shall remain separate from:

1. Authentication;

2. Authorisation Policy;

3. Authorisation Outcome.

4. The existence of consent shall not replace other required Authorisation conditions.

Authorisation Outcome

Article 15

1. An Authorisation Service shall produce an Authorisation Outcome following evaluation.

2. An Authorisation Outcome shall identify:

1. Authorisation Outcome Identifier;

2. requesting Actor;

3. represented Subject where applicable;

4. Controlled Matter;

5. Action;

6. Purpose;

7. decision;

8. Policy Identifier and Version;

9. evaluation time;

10. validity period;

11. obligations;

12. restrictions;

13. limitations.

3. An Authorisation Outcome shall remain separate from:

1. Authentication Outcome;

2. Electronic Attestation;

3. Electronic Signature;

4. Authorisation Policy.

Article 16

1. An Authorisation Outcome may contain obligations requiring enforcement by another Actor or function.

2. Obligations may include:

1. restricted disclosure;

2. additional verification;

3. logging;

4. human approval;

5. purpose limitation;

6. retention restrictions.

3. The Policy Enforcement Function shall verify that mandatory obligations can be satisfied before permitting the requested Action.

Policy Enforcement

Article 17

1. Policy Enforcement shall apply the Authorisation Outcome to the requested operation.

2. The Policy Enforcement Function shall verify:

1. Outcome integrity;

2. Outcome validity;

3. applicable scope;

4. obligations;

5. restrictions.

3. Policy Enforcement shall not modify the substantive Authorisation decision.

Continuous authorisation and re-evaluation

Article 18

1. An Authorisation Outcome shall remain valid only for the conditions and period established by the applicable Policy.

2. Re-evaluation shall occur where:

1. the validity period expires;

2. the Authentication Outcome changes;

3. Role or Mandate information changes;

4. Source Status changes;

5. requested Action changes;

6. Purpose changes;

7. risk conditions materially change.

3. A cached Authorisation Outcome shall not be used beyond its permitted scope.

Lifecycle management

Article 19

1. The lifecycle of an Authorisation Outcome shall include, where applicable:

1. creation;

2. activation;

3. use;

4. expiry;

5. revocation;

6. replacement;

7. historical retention.

2. Lifecycle events shall identify:

1. responsible Actor;

2. effective time;

3. reason;

4. supporting evidence.

Security and records

Article 20

1. The Authorisation Service shall protect:

1. Authorisation Policies;

2. Authorisation Requests;

3. Authorisation Decisions;

4. Authorisation Outcomes;

5. evaluation evidence.

2. Protection shall include:

1. confidentiality;

2. integrity;

3. access control;

4. accountability;

5. auditability.

Article 21

1. The Authorisation Service shall maintain records sufficient to reconstruct:

1. evaluated Request;

2. applicable Policy;

3. decision inputs;

4. Authorisation Decision;

5. Authorisation Outcome;

6. enforcement result.

2. Records shall enable historical determination of the Authorisation conditions applicable at the relevant time.

Applicable standards

Article 22

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. identity;

2. Authentication;

3. Authorisation;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ISO/IEC 29146:2024	Access-management architecture and distributed authorisation functions
ISO/IEC 10181-3:1996	Access-control framework concepts
NIST SP 800-162	Attribute Based Access Control implementation guidance
OASIS XACML 3.0	Policy language and decision model
XACML JSON Profile 1.1	JSON representation of policy requests and responses
XACML REST Profile 1.1	REST-based policy decision interface
XACML RBAC Profile 1.0	Role-based policy evaluation where applicable
XACML Administration and Delegation Profile 1.0	Policy administration and delegation where applicable
ISO/IEC TS 27560:2023	Consent records where consent is used as an Authorisation input
ISO/IEC 27701:2025	Privacy management controls where personal data access decisions are performed
ISO/IEC 27001:2022	Security management controls applicable to Authorisation Services

IDEHA-IG-SVC-DSG-001: Digital Signing Service Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Digital Signing Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Digital Signing Services and Actors operating Digital Signing Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Digital Signing Service operation;

2. signing request processing;

3. Digital Signature creation orchestration;

4. interaction with Digital Signature Creation Mechanisms and Devices;

5. signing evidence management;

6. service lifecycle management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

2. IDEHA-IG-OBJ-SIG-001 Electronic Signature Implementation;

3. IDEHA-IG-OBJ-SEL-001 Electronic Seal Implementation where applicable;

4. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

5. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

6. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

7. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Digital Signature Creation Data requirements;

2. Digital Signature Creation Device requirements;

3. Qualified Digital Signature Creation Device requirements;

4. Electronic Signature requirements;

5. Electronic Seal requirements;

6. Signatory identification requirements;

7. signing intent requirements;

8. signature format requirements;

9. cryptographic algorithm selection.

Those matters shall be implemented through the applicable Framework Instruments.

Digital Signing Service scope

Article 2

1. A Digital Signing Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted signing functions;

2. supported Digital Signature Creation Mechanisms;

3. supported Digital Signature Creation Devices;

4. supported Signature Profiles;

5. applicable Assurance Conditions;

6. applicable Security Conditions;

7. applicable Technical Specifications.

3. A Digital Signing Service shall not perform signing operations outside its approved Service Scope.

Article 3

1. A Digital Signing Service shall maintain separation between:

1. signing request processing;

2. Digital Signature creation;

3. Electronic Signature creation;

4. Electronic Seal creation;

5. Validation activities.

2. A Digital Signing Service shall create Digital Signatures only.

3. The resulting Digital Signature shall become part of an Electronic Signature or Electronic Seal only through the applicable Framework Instrument.

Signing request processing

Article 4

1. A Digital Signing Service shall process signing requests according to the applicable Signing Profile.

2. A signing request shall identify, where applicable:

1. requesting Actor;

2. requested signing operation;

3. data to be signed;

4. Digital Signature Creation Mechanism;

5. Digital Signature Creation Device;

6. applicable Profile;

7. required evidence.

3. The Digital Signing Service shall verify that the requested operation is within its Service Scope.

Article 5

1. Before creating a Digital Signature, the Digital Signing Service shall determine that:

1. the request is valid;

2. the required Digital Signature Creation Device is available;

3. the Digital Signature Creation Data may be used;

4. applicable Authentication conditions are satisfied;

5. applicable Authorisation conditions are satisfied.

2. The Digital Signing Service shall not determine:

1. legal effect of the signed data;

2. existence of signing intent;

3. validity of the resulting Electronic Signature.

Those matters belong to the applicable Electronic Signature Profile.

Interaction with Digital Signature Creation Devices

Article 6

1. A Digital Signing Service shall use Digital Signature Creation Mechanisms and Digital Signature Creation Devices according to the applicable Profile.

2. The Digital Signing Service shall maintain evidence of:

1. selected Digital Signature Creation Device;

2. selected Digital Signature Creation Mechanism;

3. signing operation;

4. creation result;

5. applicable configuration.

3. The Digital Signing Service shall not alter the security boundary or evaluated configuration of a Digital Signature Creation Device.

Article 7

1. Where a Digital Signing Service operates with a remote Digital Signature Creation Device, it shall ensure that:

1. the correct signing operation is selected;

2. the intended data representation is provided;

3. communication with the device is protected;

4. creation evidence is generated.

2. Remote operation shall comply with the applicable remote signing Profile.

3. The Digital Signing Service shall not replace the requirements applicable to the Digital Signature Creation Device.

Authentication and Authorisation dependencies

Article 8

1. Where required by the applicable Profile, a Digital Signing Service shall require an Authentication Outcome before initiating a signing operation.

2. The Authentication Outcome shall identify, where applicable:

1. authenticated Subject;

2. Authentication Service;

3. Authentication Assurance;

4. validity period;

5. limitations.

3. Authentication shall remain separate from the Digital Signature creation process.

Article 9

1. Where required by the applicable Profile, a Digital Signing Service shall require an Authorisation Outcome before initiating a signing operation.

2. The Authorisation Outcome shall identify, where applicable:

1. permitted signing operation;

2. Actor;

3. Subject;

4. scope;

5. validity period;

6. restrictions.

3. Authorisation shall remain separate from Digital Signature creation.

Digital Signature creation operation

Article 10

1. A Digital Signing Service shall create a Digital Signature using the approved Digital Signature Creation Mechanism.

2. The creation operation shall identify:

1. data representation provided for signing;

2. Digital Signature Creation Data reference;

3. Digital Signature Creation Device reference;

4. creation time;

5. resulting Digital Signature.

3. The Digital Signing Service shall preserve the relationship between the signing request and the resulting Digital Signature.

Article 11

1. A Digital Signing Service shall produce creation evidence sufficient to reconstruct the Digital Signature creation operation.

2. Creation evidence shall include, where applicable:

1. signing request identifier;

2. Digital Signature identifier;

3. Digital Signature Creation Device reference;

4. Digital Signature Creation Mechanism reference;

5. creation time;

6. service Version;

7. applicable Profile.

3. Creation evidence shall not expose Digital Signature Creation Data.

Service evidence

Article 12

1. The Digital Signing Service shall maintain evidence sufficient to demonstrate operation of the service.

2. Service evidence shall identify:

1. received request;

2. evaluation performed;

3. dependencies used;

4. creation operation;

5. resulting Digital Signature;

6. service outcome.

3. Evidence shall be protected against unauthorised alteration.

Qualified Digital Signing Service

Article 13

1. A Digital Signing Service intended to operate as a Qualified Trust Service shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall identify:

1. required Trust Service Provider Status;

2. required Trust Service Status;

3. applicable Digital Signature Creation Device requirements;

4. applicable service assurance conditions;

5. required evidence.

3. Qualified Status of the Digital Signing Service shall not establish:

1. Qualified Electronic Signature Status;

2. Qualified Electronic Seal Status;

3. Qualified Digital Signature Creation Device Status.

4. Each qualified condition shall be evaluated separately.

Service lifecycle management

Article 14

1. The lifecycle of a Digital Signing Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting signing operations shall be recorded.

Article 15

1. Changes affecting the Digital Signing Service shall be assessed before implementation.

2. The assessment shall consider:

1. Digital Signature Creation Devices;

2. Digital Signature Creation Mechanisms;

3. supported Profiles;

4. Authentication dependencies;

5. Authorisation dependencies;

6. Technical Specifications.

3. Material changes shall be managed according to applicable Change Control requirements.

Incident management

Article 16

1. A Digital Signing Service shall maintain procedures for:

1. signing service interruption;

2. Digital Signature Creation Device compromise;

3. Digital Signature Creation Data compromise;

4. failed signing operations;

5. recovery.

2. Incident records shall identify affected signing operations where applicable.

3. The effect on created Digital Signatures shall be determined through applicable Validation processes.

Records and evidence

Article 17

1. The Digital Signing Service shall maintain records sufficient to reconstruct:

1. signing requests;

2. authentication and authorisation dependencies;

3. Digital Signature creation operations;

4. service decisions;

5. incidents;

6. lifecycle changes.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 18

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Signature Status;

2. Qualified Electronic Signature Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 419 241-1	General security requirements for trustworthy systems supporting server signing
ETSI EN 419 241-2	Protection Profile for QSCD used for server signing
ETSI TS 119 431-1	Policy and security requirements for remote signature creation services
ETSI TS 119 432	Protocols and interfaces for remote signature creation
ETSI EN 319 102-1	Signature validation process where service evidence includes validation dependencies
ETSI EN 319 312	Cryptographic suites where applicable
ISO/IEC 27001:2022	Information security management controls applicable to Digital Signing Services
ISO/IEC 27701:2025	Privacy management controls where personal data is processed
ISO 22301:2019	Business continuity management where continuity requirements apply

IDEHA-IG-SVC-SIG-001: Electronic Signature Service Implementation

Version: 0.1

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Signature Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Electronic Signature Services and Actors operating Electronic Signature Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Electronic Signature request processing;

2. Signatory interaction;

3. signing workflow management;

4. signing intent evidence;

5. presentation and confirmation of data before signing;

6. delivery of Electronic Signatures;

7. Electronic Signature service evidence.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-SIG-001 Electronic Signature Implementation;

2. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

3. IDEHA-IG-SVC-DSG-001 Digital Signing Service Implementation;

4. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

5. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

6. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

7. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Digital Signature Creation Data requirements;

2. Digital Signature Creation Device requirements;

3. cryptographic algorithms;

4. cryptographic parameters;

5. Certificate issuance requirements;

6. Digital Signature formats;

7. Validation procedures.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Signature Service scope

Article 2

1. An Electronic Signature Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted Electronic Signature functions;

2. supported Electronic Signature Profiles;

3. supported signing workflows;

4. applicable Authentication dependencies;

5. applicable Authorisation dependencies;

6. applicable Assurance Conditions;

7. applicable Security Conditions.

3. An Electronic Signature Service shall not perform functions outside its approved Service Scope.

Article 3

1. An Electronic Signature Service shall maintain separation between:

1. Electronic Signature workflow;

2. Digital Signature creation;

3. Authentication;

4. Authorisation;

5. Validation.

2. An Electronic Signature Service shall not create legal effects beyond those established by the applicable Framework Instruments.

Electronic Signature request processing

Article 4

1. An Electronic Signature Service shall process Electronic Signature requests according to the applicable Electronic Signature Profile.

2. An Electronic Signature request shall identify, where applicable:

1. requesting Actor;

2. Signatory;

3. data to be signed;

4. intended purpose;

5. applicable Signature Profile;

6. required evidence.

3. The Electronic Signature Service shall verify that the requested signing operation is within its Service Scope.

Article 5

1. Before initiating a signing operation, the Electronic Signature Service shall determine that:

1. the Signatory is identified according to the applicable Profile;

2. required Authentication conditions are satisfied;

3. required Authorisation conditions are satisfied;

4. the data to be signed is identified;

5. the signing workflow is applicable.

2. The Electronic Signature Service shall not replace the Identification Service or Authentication Service.

Signatory interaction

Article 6

1. The Electronic Signature Service shall provide mechanisms enabling the Signatory to participate in the signing process.

2. The signing interaction shall ensure, where applicable:

1. identification of the data to be signed;

2. presentation of relevant signing information;

3. confirmation of the signing operation;

4. recording of the signing action.

3. The applicable Profile shall define the required level of interaction.

Article 7

1. The Electronic Signature Service shall ensure that the Signatory is able to understand the signing operation to the extent required by the applicable Profile.

2. The signing interface shall identify, where applicable:

1. signed data;

2. relevant transaction information;

3. signing context;

4. applicable limitations.

3. Presentation requirements shall remain separate from Digital Signature creation requirements.

Signing intent

Article 8

1. Where signing intent is required by the applicable Profile, the Electronic Signature Service shall capture evidence demonstrating that the Signatory intended to apply the Electronic Signature to the identified data.

2. Signing intent evidence may include:

1. explicit confirmation;

2. user interaction;

3. transaction confirmation;

4. another approved interaction mechanism.

3. Signing intent shall remain separate from:

1. Authentication;

2. Authorisation;

3. Digital Signature creation.

Article 9

1. The Electronic Signature Service shall record signing intent evidence where required.

2. The evidence shall identify:

1. Signatory;

2. signed data reference;

3. signing event;

4. time of confirmation;

5. applicable workflow.

3. Signing intent evidence shall be protected against unauthorised alteration.

Authentication and Authorisation dependencies

Article 10

1. Where required by the applicable Profile, the Electronic Signature Service shall obtain an Authentication Outcome before completing a signing operation.

2. The Authentication Outcome shall identify, where applicable:

1. authenticated Subject;

2. Authentication Service;

3. Authentication Assurance;

4. validity period;

5. limitations.

3. Authentication shall remain separate from the Electronic Signature.

Article 11

1. Where required by the applicable Profile, the Electronic Signature Service shall obtain an Authorisation Outcome before completing a signing operation.

2. The Authorisation Outcome shall identify, where applicable:

1. permitted signing operation;

2. Actor;

3. represented Subject;

4. scope;

5. validity period;

6. restrictions.

3. Authorisation shall remain separate from the Electronic Signature.

Digital Signature service dependency

Article 12

1. An Electronic Signature Service shall use a Digital Signing Service or equivalent Digital Signature creation function where a Digital Signature is required.

2. The Electronic Signature Service shall maintain evidence of:

1. Digital Signing Service used;

2. Digital Signature creation operation;

3. resulting Digital Signature;

4. applicable Signature Profile.

3. The Electronic Signature Service shall not modify the Digital Signature creation environment.

Article 13

1. The Electronic Signature Service shall maintain the relationship between:

1. Signatory;

2. signing workflow;

3. signed data;

4. Digital Signature;

5. resulting Electronic Signature.

2. The relationship shall support Validation according to the applicable Profile.

Electronic Signature delivery

Article 14

1. The Electronic Signature Service shall deliver the resulting Electronic Signature according to the applicable Profile.

2. Delivery information shall identify, where applicable:

1. Electronic Signature Identifier;

2. recipient;

3. delivery time;

4. applied Profile;

5. associated evidence.

3. The delivered Electronic Signature shall remain protected against unauthorised alteration.

Qualified Electronic Signature Service

Article 15

1. An Electronic Signature Service intended to provide Qualified Electronic Signatures shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required Digital Signing Service conditions;

4. required Qualified Digital Signature Creation Device dependency;

5. required Qualified Certificate dependency;

6. required evidence.

3. Qualification of the Electronic Signature Service shall not by itself establish Qualified Electronic Signature Status for every signature created through the service.

4. Qualified Electronic Signature Status shall be determined according to the applicable Qualified Object Profile.

Service evidence

Article 16

1. The Electronic Signature Service shall maintain evidence sufficient to reconstruct:

1. signing request;

2. Signatory interaction;

3. Authentication and Authorisation dependencies;

4. signing intent where applicable;

5. Digital Signature creation reference;

6. resulting Electronic Signature.

2. Evidence shall be protected according to applicable Security Conditions.

Lifecycle management

Article 17

1. The lifecycle of an Electronic Signature Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting signing operations shall be recorded.

Article 18

1. Changes affecting an Electronic Signature Service shall be assessed before implementation.

2. The assessment shall consider:

1. applicable Electronic Signature Profiles;

2. Digital Signing Service dependencies;

3. Authentication dependencies;

4. Authorisation dependencies;

5. Technical Specifications;

6. Security Conditions.

3. Material changes shall be managed according to applicable Change Control requirements.

Accessibility and safeguards

Article 19

1. An Electronic Signature Service shall provide Accessible Alternatives where required by the applicable Safeguard Conditions.

2. Accessible Alternatives shall preserve the applicable Assurance Conditions.

3. The applicable Profile shall define:

1. assisted signing arrangements;

2. alternative interaction methods;

3. human support conditions;

4. accessibility requirements.

Records and evidence

Article 20

1. The Electronic Signature Service shall maintain records sufficient to reconstruct:

1. signing requests;

2. Signatory interaction;

3. signing intent evidence;

4. Authentication dependencies;

5. Authorisation dependencies;

6. Digital Signature creation references;

7. service lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 21

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Signature Status;

2. Qualified Electronic Signature Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 401	General policy requirements for Trust Service Providers
ETSI EN 319 411-2	Qualified certificate issuing requirements where qualified signatures are supported
ETSI EN 319 102-1	Signature validation process requirements
ETSI EN 319 122-1	CAdES representation requirements
ETSI EN 319 132-1	XAdES representation requirements
ETSI EN 319 142-1	PAdES representation requirements
ETSI TS 119 182-1	JAdES representation requirements
ETSI TS 119 431-1	Remote signing service requirements where applicable
ISO/IEC 29115	Authentication assurance considerations
ISO/IEC 24760 series	Identity information and identity binding considerations
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy management controls where personal data is processed

IDEHA-IG-SVC-SEL-001: Electronic Seal Service Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Seal Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Electronic Seal Services and Actors operating Electronic Seal Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Electronic Seal request processing;

2. Seal Creator interaction and authority handling;

3. sealing workflow management;

4. automated and scheduled sealing operations;

5. interaction with Digital Signing Services;

6. Seal Evidence management;

7. Electronic Seal Service lifecycle management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-SEL-001 Electronic Seal Implementation;

2. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

3. IDEHA-IG-SVC-DSG-001 Digital Signing Service Implementation;

4. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

5. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

6. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

7. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Digital Signature Creation Data requirements;

2. Digital Signature Creation Device requirements;

3. cryptographic algorithms;

4. cryptographic parameters;

5. Electronic Seal object requirements;

6. Advanced Electronic Seal requirements;

7. Qualified Electronic Seal requirements;

8. Seal Validation procedures.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Seal Service scope

Article 2

1. An Electronic Seal Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted sealing functions;

2. supported Electronic Seal Profiles;

3. supported sealing workflows;

4. supported Digital Signing Services;

5. applicable Authentication dependencies;

6. applicable Authorisation dependencies;

7. applicable Assurance Conditions;

8. applicable Security Conditions.

3. An Electronic Seal Service shall not perform sealing operations outside its approved Service Scope.

Article 3

1. An Electronic Seal Service shall maintain separation between:

1. sealing workflow;

2. Digital Signature creation;

3. organisational authority evaluation;

4. Authentication;

5. Authorisation;

6. Validation.

2. An Electronic Seal Service shall not determine legal effect of sealed data.

3. The resulting Electronic Seal shall acquire its applicable legal or evidential effect only according to the Main Framework and applicable Profile.

Seal request processing

Article 4

1. An Electronic Seal Service shall process sealing requests according to the applicable Electronic Seal Profile.

2. A sealing request shall identify, where applicable:

1. requesting Actor;

2. Seal Creator;

3. data to be sealed;

4. intended purpose;

5. applicable Seal Profile;

6. required evidence.

3. The Electronic Seal Service shall verify that the requested sealing operation is within its Service Scope.

Article 5

1. Before initiating a sealing operation, the Electronic Seal Service shall determine that:

1. the requesting Actor is identified;

2. the Seal Creator is identified;

3. required authority conditions are satisfied;

4. the data to be sealed is identified;

5. applicable workflow requirements are fulfilled.

2. The Electronic Seal Service shall not replace:

1. Identification Service;

2. Authentication Service;

3. Authorisation Service.

Seal Creator and authority handling

Article 6

1. An Electronic Seal Service shall maintain evidence identifying the Seal Creator associated with the sealing operation.

2. Seal Creator information shall identify, where applicable:

1. Seal Creator reference;

2. organisational Actor;

3. authority basis;

4. effective period;

5. limitations.

3. Seal Creator information shall remain separate from:

1. Digital Signature Creation Data;

2. Certificate Identifier;

3. Electronic Seal Identifier;

4. Trust Object Identifier.

Article 7

1. Where sealing requires organisational approval, the Electronic Seal Service shall verify the applicable approval or authority condition before initiating sealing.

2. Approval evidence may identify:

1. approving Actor;

2. approval event;

3. approved data;

4. applicable policy;

5. approval time.

3. Approval evidence shall remain separate from the resulting Electronic Seal.

Automated and scheduled sealing

Article 8

1. An Electronic Seal Service may support automated sealing where permitted by the applicable Profile.

2. Automated sealing shall identify:

1. initiating system or process;

2. sealing policy;

3. authority permitting automated sealing;

4. data selection rules;

5. sealing event.

3. Automated sealing shall not remove the requirement to identify the Seal Creator.

Article 9

1. Scheduled sealing operations shall operate according to predefined conditions.

2. The Electronic Seal Service shall maintain evidence of:

1. schedule definition;

2. execution event;

3. data selection;

4. sealing operation;

5. resulting Electronic Seal.

3. Changes to scheduled sealing conditions shall be managed through applicable Change Control requirements.

Authentication and Authorisation dependencies

Article 10

1. Where required by the applicable Profile, the Electronic Seal Service shall obtain an Authentication Outcome before completing a sealing operation.

2. The Authentication Outcome shall identify, where applicable:

1. authenticated Actor;

2. Authentication Service;

3. Authentication Assurance;

4. validity period;

5. limitations.

3. Authentication shall remain separate from Electronic Seal creation.

Article 11

1. Where required by the applicable Profile, the Electronic Seal Service shall obtain an Authorisation Outcome before completing a sealing operation.

2. The Authorisation Outcome shall identify, where applicable:

1. permitted sealing operation;

2. Actor;

3. scope;

4. validity period;

5. restrictions.

3. Authorisation shall remain separate from the Electronic Seal.

Digital Signature creation dependency

Article 12

1. An Electronic Seal Service shall use a Digital Signing Service or equivalent Digital Signature creation function where a Digital Signature is required for sealing.

2. The Electronic Seal Service shall maintain evidence of:

1. Digital Signing Service used;

2. Digital Signature creation operation;

3. resulting Digital Signature;

4. applicable Seal Profile.

3. The Electronic Seal Service shall not modify the Digital Signature Creation Device or Digital Signature Creation Data environment.

Article 13

1. The Electronic Seal Service shall maintain the relationship between:

1. Seal Creator;

2. sealing workflow;

3. sealed data;

4. Digital Signature;

5. resulting Electronic Seal.

2. The relationship shall support Validation according to the applicable Profile.

Seal delivery and evidence

Article 14

1. The Electronic Seal Service shall deliver the resulting Electronic Seal according to the applicable Profile.

2. Delivery information shall identify, where applicable:

1. Electronic Seal Identifier;

2. recipient;

3. delivery time;

4. applied Profile;

5. associated evidence.

3. The delivered Electronic Seal shall remain protected against unauthorised alteration.

Article 15

1. The Electronic Seal Service shall maintain Seal Evidence sufficient to reconstruct:

1. sealing request;

2. Seal Creator;

3. authority evaluation;

4. Authentication and Authorisation dependencies;

5. Digital Signature creation reference;

6. resulting Electronic Seal.

2. Seal Evidence shall be protected according to applicable Security Conditions.

Qualified Electronic Seal Service

Article 16

1. An Electronic Seal Service intended to provide Qualified Electronic Seals shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required Digital Signing Service conditions;

4. required Qualified Digital Signature Creation Device dependency;

5. required Qualified Certificate dependency;

6. required evidence.

3. Qualification of the Electronic Seal Service shall not by itself establish Qualified Electronic Seal Status for every seal created through the service.

4. Qualified Electronic Seal Status shall be determined according to the applicable Qualified Object Profile.

Service lifecycle management

Article 17

1. The lifecycle of an Electronic Seal Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting sealing operations shall be recorded.

Article 18

1. Changes affecting an Electronic Seal Service shall be assessed before implementation.

2. The assessment shall consider:

1. Electronic Seal Profiles;

2. Digital Signing Service dependencies;

3. Authentication dependencies;

4. Authorisation dependencies;

5. Technical Specifications;

6. Security Conditions.

3. Material changes shall be managed according to applicable Change Control requirements.

Incident management

Article 19

1. An Electronic Seal Service shall maintain procedures for:

1. sealing service interruption;

2. Digital Signature Creation Device compromise;

3. Digital Signature Creation Data compromise;

4. failed sealing operations;

5. recovery.

2. Incident records shall identify affected sealing operations where applicable.

3. The effect on created Electronic Seals shall be determined through applicable Validation processes.

Records and evidence

Article 20

1. The Electronic Seal Service shall maintain records sufficient to reconstruct:

1. sealing requests;

2. Seal Creator identification;

3. authority verification;

4. Authentication and Authorisation dependencies;

5. Digital Signature creation references;

6. resulting Electronic Seals;

7. service lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 21

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Seal Status;

2. Qualified Electronic Seal Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 401	General policy requirements for Trust Service Providers
ETSI EN 319 411-2	Qualified certificate issuing requirements where qualified seals are supported
ETSI EN 319 102-1	Signature and seal validation process requirements
ETSI EN 319 122-1	CAdES seal representation requirements
ETSI EN 319 132-1	XAdES seal representation requirements
ETSI EN 319 142-1	PAdES seal representation requirements
ETSI TS 119 182-1	JAdES seal representation requirements
ETSI TS 119 431-1	Remote signing service requirements where applicable
ISO/IEC 24760 series	Identity and organisational identity relationship considerations
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy management controls where personal data is processed
ISO 22301:2019	Business continuity management where continuity requirements apply

IDEHA-IG-SVC-TST-001: Electronic Timestamp Service Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Timestamp Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Electronic Timestamp Services and Actors operating Electronic Timestamp Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Electronic Timestamp Service operation;

2. timestamp request processing;

3. Time-Stamping Unit operation;

4. trusted time source management;

5. timestamp issuance;

6. timestamp service evidence;

7. service lifecycle management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-TST-001 Electronic Timestamp Implementation;

2. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

3. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

4. IDEHA-IG-SEC-CRY-001 Cryptographic Controls and Cryptographic Agility Implementation;

5. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Electronic Timestamp object categories;

2. Qualified Electronic Timestamp object conditions;

3. timestamp token formats;

4. signature timestamp integration;

5. signature or seal validation procedures;

6. cryptographic algorithm selection.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Timestamp Service scope

Article 2

1. An Electronic Timestamp Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted timestamp functions;

2. supported Timestamp Profiles;

3. supported Time-Stamping Units;

4. applicable time sources;

5. applicable Assurance Conditions;

6. applicable Security Conditions;

7. applicable Technical Specifications.

3. An Electronic Timestamp Service shall not issue Electronic Timestamps outside its approved Service Scope.

Timestamp service architecture

Article 3

1. An Electronic Timestamp Service shall maintain operational separation between:

1. time source management;

2. Time-Stamping Unit operation;

3. timestamp request processing;

4. timestamp creation;

5. timestamp evidence management.

2. The Electronic Timestamp Service shall identify the components involved in timestamp creation.

3. Component relationships shall be maintained as operational evidence.

Article 4

1. An Electronic Timestamp Service shall operate Time-Stamping Units within a controlled security environment.

2. The Time-Stamping Unit shall:

1. receive authorised timestamp requests;

2. obtain trusted time information;

3. create Electronic Timestamps;

4. protect timestamp creation functions;

5. maintain required evidence.

3. The Time-Stamping Unit shall operate according to the applicable Timestamp Profile.

Timestamp request processing

Article 5

1. An Electronic Timestamp Service shall process timestamp requests according to the applicable Timestamp Profile.

2. A timestamp request shall identify, where applicable:

1. requesting Actor;

2. data reference;

3. requested timestamp function;

4. applicable Timestamp Profile;

5. required evidence.

3. The Electronic Timestamp Service shall verify that the requested operation is within its Service Scope.

Article 6

1. An Electronic Timestamp Service shall ensure that the timestamp request is processed without unauthorised modification.

2. Request processing shall maintain evidence of:

1. request receipt;

2. request evaluation;

3. request acceptance or rejection;

4. timestamp creation result.

3. The Electronic Timestamp Service shall not require disclosure of the original electronic data where a protected data reference is used.

Trusted time source management

Article 7

1. An Electronic Timestamp Service shall use trusted time sources appropriate to the applicable Timestamp Profile.

2. The trusted time source arrangement shall establish:

1. traceability to the applicable time reference;

2. synchronisation conditions;

3. monitoring conditions;

4. accuracy conditions;

5. failure handling conditions.

3. The Electronic Timestamp Service shall monitor the accuracy and availability of trusted time sources.

Article 8

1. The Electronic Timestamp Service shall establish procedures for loss of acceptable time synchronisation.

2. Where trusted time conditions are no longer satisfied, the Electronic Timestamp Service shall:

1. prevent issuance where required;

2. record the event;

3. assess affected timestamps;

4. initiate corrective measures.

3. The applicable Timestamp Profile shall define the conditions for service restoration.

Time-Stamping Unit operation

Article 9

1. A Time-Stamping Unit shall operate within an identified security boundary.

2. The security boundary shall identify:

1. protected components;

2. timestamp creation functions;

3. cryptographic functions;

4. administrative functions;

5. external dependencies.

3. The Time-Stamping Unit shall protect timestamp creation material against:

1. unauthorised disclosure;

2. unauthorised use;

3. unauthorised modification;

4. unauthorised replacement.

Article 10

1. The Electronic Timestamp Service shall maintain evidence relating to each Time-Stamping Unit.

2. Evidence shall identify, where applicable:

1. Time-Stamping Unit Identifier;

2. configuration Version;

3. cryptographic dependencies;

4. operational Status;

5. lifecycle events.

Electronic Timestamp issuance

Article 11

1. An Electronic Timestamp Service shall create Electronic Timestamps according to the applicable Timestamp Profile.

2. The issuance process shall establish:

1. data-reference binding;

2. trusted time application;

3. timestamp protection;

4. issuance evidence.

3. The Electronic Timestamp Service shall maintain the relationship between:

1. timestamp request;

2. Time-Stamping Unit;

3. trusted time source;

4. resulting Electronic Timestamp.

Article 12

1. The Electronic Timestamp Service shall maintain issuance records sufficient to reconstruct timestamp creation.

2. Issuance records shall identify:

1. request identifier;

2. timestamp identifier;

3. Time-Stamping Unit;

4. creation time;

5. applicable Timestamp Profile;

6. service Version.

Qualified Electronic Timestamp Service

Article 13

1. An Electronic Timestamp Service intended to provide Qualified Electronic Timestamps shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required time-source conditions;

4. required security conditions;

5. required evidence;

6. required conformity assessment.

3. Qualification of the Electronic Timestamp Service shall not automatically establish Qualified Status for every Electronic Timestamp issued.

4. Qualified Electronic Timestamp Status shall be determined according to the applicable Qualified Object Profile.

Timestamp service evidence

Article 14

1. The Electronic Timestamp Service shall maintain evidence sufficient to demonstrate:

1. request processing;

2. trusted time conditions;

3. Time-Stamping Unit operation;

4. timestamp issuance;

5. security events;

6. lifecycle changes.

2. Evidence shall be protected against unauthorised alteration.

Service lifecycle management

Article 15

1. The lifecycle of an Electronic Timestamp Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting timestamp reliability shall be recorded.

Article 16

1. Changes affecting an Electronic Timestamp Service shall be assessed before implementation.

2. The assessment shall consider:

1. Time-Stamping Units;

2. trusted time sources;

3. cryptographic dependencies;

4. Timestamp Profiles;

5. Technical Specifications;

6. Security Conditions.

3. Material changes shall be managed according to applicable Change Control requirements.

Incident management and continuity

Article 17

1. An Electronic Timestamp Service shall maintain procedures for:

1. time-source failure;

2. Time-Stamping Unit compromise;

3. cryptographic compromise;

4. service interruption;

5. recovery.

2. Incident records shall identify affected Electronic Timestamps where applicable.

3. The effect on issued Electronic Timestamps shall be determined through the applicable Validation process.

Records and evidence

Article 18

1. The Electronic Timestamp Service shall maintain records sufficient to reconstruct:

1. timestamp requests;

2. trusted time conditions;

3. Time-Stamping Unit operation;

4. timestamp issuance;

5. lifecycle events;

6. incident events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 19

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Timestamp Category;

2. Qualified Electronic Timestamp Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 421	Policy and security requirements for Electronic Timestamp Services
ETSI EN 319 422	Timestamp protocol and token profile requirements
RFC 3161	Time-Stamp Protocol
RFC 5816	ESSCertIDv2 update for timestamp token certificate identification
ETSI EN 319 102-1	Validation process requirements applicable to timestamps
ISO/IEC 18014-4	Time source traceability and assurance considerations
ISO 8601-1:2019	Date and time representation
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy management controls where personal data is processed
ISO 22301:2019	Business continuity management where continuity requirements apply

IDEHA-IG-SVC-EAS-001: Electronic Attestation Service Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Electronic Attestation Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Electronic Attestation Services and Actors operating Electronic Attestation Service functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Electronic Attestation Service operation;

2. attestation request processing;

3. Attestation Issuer responsibilities;

4. evidence evaluation before issuance;

5. Source Basis handling;

6. Electronic Attestation issuance;

7. Electronic Attestation lifecycle management;

8. issuance evidence management.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-EAA-001 Electronic Attestation Implementation;

2. IDEHA-IG-SRC-ASO-001 Source and Authoritative Source Implementation;

3. IDEHA-IG-SVC-IDN-001 Identification Service Implementation where identity information is used;

4. IDEHA-IG-DAT-SEM-001 Controlled Data Elements, Semantics and Data Quality Implementation;

5. IDEHA-IG-SVC-VVS-001 Validation and Verification Service Implementation;

6. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. Electronic Attestation Categories;

2. Attribute semantic definitions;

3. Source authority;

4. Identification Service operation;

5. Authentication Service operation;

6. Authorisation decisions;

7. attestation data formats;

8. technical schemas;

9. cryptographic algorithms.

Those matters shall be implemented through the applicable Framework Instruments.

Electronic Attestation Service scope

Article 2

1. An Electronic Attestation Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted attestation functions;

2. supported Attestation Profiles;

3. supported Attestation Schemes;

4. permitted Source Basis;

5. applicable Assurance Conditions;

6. applicable Security Conditions;

7. applicable Technical Specifications.

3. An Electronic Attestation Service shall not issue Electronic Attestations outside its approved Service Scope.

Article 3

1. An Electronic Attestation Service shall maintain separation between:

1. evidence collection;

2. evidence evaluation;

3. attestation creation;

4. attestation issuance;

5. attestation Status management.

2. An Electronic Attestation Service shall not:

1. create Source authority;

2. modify Attribute meaning;

3. create underlying legal facts;

4. replace the Source maintaining the attested information.

3. The Electronic Attestation Service shall remain responsible for the issuance process within its assigned Service Scope.

Attestation request processing

Article 4

1. An Electronic Attestation Service shall process attestation requests according to the applicable Attestation Profile.

2. An attestation request shall identify, where applicable:

1. requesting Actor;

2. intended Subject;

3. requested Attestation Profile;

4. requested Attributes or statements;

5. intended purpose;

6. required evidence.

3. The Electronic Attestation Service shall verify that the requested attestation operation is within its Service Scope.

Article 5

1. Before issuing an Electronic Attestation, the Electronic Attestation Service shall determine that:

1. the request is valid;

2. the Subject or matter is identified;

3. the required Source Basis is available;

4. the requested Attributes are within scope;

5. applicable issuance conditions are satisfied.

2. The Electronic Attestation Service shall maintain evidence of the evaluation performed before issuance.

Attestation Issuer responsibilities

Article 6

1. An Electronic Attestation Service shall identify the Attestation Issuer responsible for issuing an Electronic Attestation.

2. The Attestation Issuer information shall identify:

1. issuing Trust Service Provider or Actor;

2. Electronic Attestation Service;

3. applicable Service Scope;

4. applicable Attestation Profile.

3. The Attestation Issuer shall remain responsible for:

1. issuance decision;

2. attestation creation process;

3. issuance evidence;

4. lifecycle management.

4. The Attestation Issuer shall not assume responsibility for a Source beyond the evaluation performed according to the applicable Profile.

Source Basis and evidence evaluation

Article 7

1. Where an Electronic Attestation relies on information from a Source, the Electronic Attestation Service shall identify the Source Basis.

2. The Source Basis shall identify, where applicable:

1. Source Identifier;

2. Source Scope;

3. Source Holder;

4. Source Steward;

5. relevant evidence;

6. Provenance information.

3. The Electronic Attestation Service shall use Source information only within the Source Scope applicable to the attestation.

Article 8

1. Before issuance, the Electronic Attestation Service shall evaluate the information used to create the Electronic Attestation.

2. The evaluation shall determine, where applicable:

1. Source applicability;

2. Attribute applicability;

3. data integrity;

4. Provenance;

5. Freshness Conditions;

6. applicable Assurance Conditions.

3. Evaluation results shall be retained as issuance evidence.

Attribute handling

Article 9

1. An Electronic Attestation Service shall use Attributes according to the applicable semantic definitions.

2. The Electronic Attestation Service shall ensure that:

1. Attribute Identifier remains separate from Attribute value;

2. Attribute Version is maintained where applicable;

3. Attribute meaning remains unchanged;

4. transformations are recorded.

3. The Electronic Attestation Service shall not create new semantic meaning through issuance.

Article 10

1. Where Attributes are derived, the Electronic Attestation Service shall identify:

1. source Attributes;

2. derivation method;

3. responsible processing function;

4. derivation Version;

5. limitations.

2. Derived Attributes shall remain distinguishable from directly sourced Attributes.

Electronic Attestation issuance

Article 11

1. An Electronic Attestation Service shall create Electronic Attestations according to the applicable Attestation Profile.

2. The issuance process shall establish:

1. Subject or matter reference;

2. Attestation Statement;

3. Source Basis where applicable;

4. Attestation Issuer;

5. issuance time;

6. applicable Profile;

7. required protection.

3. The Electronic Attestation Service shall maintain the relationship between:

1. request;

2. evaluated evidence;

3. issuance decision;

4. resulting Electronic Attestation.

Article 12

1. The Electronic Attestation Service shall protect issued Electronic Attestations according to the applicable Profile.

2. Protection requirements may include:

1. Electronic Signature;

2. Electronic Seal;

3. integrity protection;

4. other approved mechanisms.

3. Technical protection formats shall be defined through the applicable Technical Specification.

Qualified Electronic Attestation Service

Article 13

1. An Electronic Attestation Service intended to provide Qualified Electronic Attestations shall satisfy the applicable Qualified Profile.

2. The Qualified Profile shall identify:

1. required Qualified Trust Service Provider Status;

2. required Qualified Trust Service Status;

3. required Source conditions where applicable;

4. required protection conditions;

5. required Assurance Conditions;

6. required evidence.

3. Qualification of the Electronic Attestation Service shall not automatically qualify every Electronic Attestation issued by the service.

4. Qualified Electronic Attestation Status shall be determined according to the applicable Qualified Object Profile.

Status and lifecycle management

Article 14

1. An Electronic Attestation Service shall maintain lifecycle information for issued Electronic Attestations.

2. Lifecycle information shall include, where applicable:

1. creation;

2. issuance;

3. activation;

4. use;

5. correction;

6. replacement;

7. Suspension;

8. Revocation;

9. expiration;

10. withdrawal.

3. Lifecycle events shall identify:

1. responsible Actor;

2. effective time;

3. reason;

4. supporting evidence.

Article 15

1. An Electronic Attestation Service shall maintain Status information necessary for Validation.

2. Status information shall identify, where applicable:

1. Electronic Attestation Identifier;

2. Status;

3. effective time;

4. reason;

5. responsible Actor.

3. Status information shall support determination of Historical State where required.

Correction and replacement

Article 16

1. The Electronic Attestation Service shall maintain procedures for:

1. correction;

2. replacement;

3. supersession;

4. withdrawal;

5. Revocation.

2. Replacement of an Electronic Attestation shall identify:

1. predecessor Electronic Attestation;

2. replacement Electronic Attestation;

3. reason;

4. effective time.

3. Previous Electronic Attestations shall remain identifiable where required for Historical State determination.

Service lifecycle management

Article 17

1. The lifecycle of an Electronic Attestation Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting attestation issuance shall be recorded.

Article 18

1. Changes affecting an Electronic Attestation Service shall be assessed before implementation.

2. The assessment shall consider:

1. Attestation Profiles;

2. Source dependencies;

3. Attribute dependencies;

4. Technical Specifications;

5. Security Conditions;

6. Assurance Conditions.

3. Material changes shall be managed according to applicable Change Control requirements.

Records and evidence

Article 19

1. The Electronic Attestation Service shall maintain records sufficient to reconstruct:

1. attestation requests;

2. evidence evaluation;

3. Source Basis;

4. issuance decisions;

5. issued Electronic Attestations;

6. lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 20

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Electronic Attestation Category;

2. Qualified Electronic Attestation Status;

3. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 401	General policy requirements for Trust Service Providers
ETSI TS 119 461	Identity and Attribute verification requirements where applicable
ISO/IEC 11179-3:2023	Metadata registration and Attribute identification
ISO/IEC 11179-31:2023	Data-element concepts and value-domain descriptions
ISO/IEC 24760-1:2025	Identity information and identity relationship concepts
ISO/IEC 25012:2008	Data quality model
ISO/IEC 25024:2015	Data quality measurement
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy management controls where personal data is processed
ISO 15489-1:2016	Records management principles

IDEHA-IG-SVC-VVS-001: Validation and Verification Service Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Validation Services and Verification Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Validation and Verification Services and Actors performing Validation or Verification functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Verification request processing;

2. Validation request processing;

3. evidence evaluation;

4. dependency resolution;

5. Status determination;

6. Historical State determination;

7. Verification Results, Validation Results and Status Responses.

4. This Guideline applies together with:

1. IDEHA-IG-OBJ-DSG-001 Digital Signature Creation Data and Device Implementation;

2. IDEHA-IG-OBJ-SIG-001 Electronic Signature Implementation;

3. IDEHA-IG-OBJ-SEL-001 Electronic Seal Implementation;

4. IDEHA-IG-OBJ-TST-001 Electronic Timestamp Implementation;

5. IDEHA-IG-OBJ-EAA-001 Electronic Attestation Implementation;

6. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

7. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

8. IDEHA-IG-PUB-HTL-001 Humanitarian Trust List, Status Publication, Registers, Catalogues and Federation Discovery Implementation.

5. This Guideline does not establish:

1. Trust Object creation;

2. Trust Service operation other than Validation and Verification functions;

3. Certificate issuance;

4. Status publication;

5. Source authority;

6. Authentication;

7. Authorisation;

8. cryptographic algorithm selection;

9. technical object formats.

Those matters shall be implemented through the applicable Framework Instruments.

Validation and Verification Service scope

Article 2

1. A Validation and Verification Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. permitted Validation functions;

2. permitted Verification functions;

3. supported Trust Object Categories;

4. supported Trust Services;

5. supported Status sources;

6. applicable Profiles;

7. applicable Assurance Conditions;

8. applicable Security Conditions.

3. A Validation and Verification Service shall not perform functions outside its approved Service Scope.

Article 3

1. A Validation and Verification Service shall distinguish between:

1. Verification;

2. Validation;

3. Verification Result;

4. Validation Result;

5. Status Response.

2. Verification shall determine whether information can be checked against available evidence.

3. Validation shall determine whether the applicable requirements for reliance are satisfied.

4. A Verification Result shall not automatically establish Validity, Status or Controlled Reliance.

Verification requests

Article 4

1. A Validation and Verification Service shall process Verification requests according to the applicable Profile.

2. A Verification request shall identify, where applicable:

1. requesting Actor;

2. matter to be verified;

3. requested Verification function;

4. applicable Profile;

5. required evidence.

3. The Validation and Verification Service shall verify that the requested function is within its Service Scope.

Article 5

1. Verification shall evaluate the available information necessary to determine the requested fact.

2. Verification may include:

1. structural checking;

2. integrity checking;

3. consistency checking;

4. presence checking;

5. comparison against available information.

3. Verification shall not determine matters requiring Status evaluation, Historical State evaluation or Controlled Reliance assessment.

Validation requests

Article 6

1. A Validation request shall identify the Trust Object, Trust Service, Source, Authentication Outcome, Authorisation Outcome or other Controlled Matter subject to evaluation.

2. A Validation request shall identify, where applicable:

1. relying Actor;

2. intended purpose;

3. evaluation time;

4. applicable Profile;

5. required Assurance Conditions.

3. The Validation and Verification Service shall determine the applicable evaluation requirements before performing Validation.

Article 7

1. Validation shall consider, where applicable:

1. Authenticity;

2. Integrity;

3. Status;

4. dependency validity;

5. applicable Assurance Conditions;

6. Historical State;

7. limitations.

2. Validation shall evaluate only matters within the applicable Service Scope.

Evidence evaluation

Article 8

1. A Validation and Verification Service shall evaluate evidence according to the applicable Validation Profile.

2. Evidence evaluation may include:

1. Trust Object evidence;

2. Certificate evidence;

3. Status evidence;

4. Source evidence;

5. Authentication evidence;

6. Authorisation evidence;

7. timestamp evidence.

3. The Validation and Verification Service shall record evidence used for the evaluation.

Article 9

1. Evidence used during Validation shall remain attributable to its originating Actor or Source.

2. The Validation and Verification Service shall not become the owner of evidence solely because it evaluates that evidence.

3. Evidence transformation or derivation performed during Validation shall be recorded.

Trust Object validation

Article 10

1. Validation of a Trust Object shall determine whether the Trust Object satisfies applicable requirements.

2. Validation shall consider, where applicable:

1. Trust Object identity;

2. issuing Actor;

3. protection mechanism;

4. dependency information;

5. Status;

6. applicable Profile;

7. Historical State.

3. Validation requirements shall be defined by the applicable Trust Object Profile.

Article 11

1. Digital Signature and Electronic Signature Validation shall determine, where applicable:

1. signed data integrity;

2. Digital Signature integrity;

3. Validation Data applicability;

4. Certificate dependencies;

5. applicable Signature Profile;

6. Historical State.

2. Electronic Seal Validation shall determine, where applicable:

1. sealed data integrity;

2. Digital Signature integrity;

3. Seal Creator dependencies;

4. Certificate dependencies;

5. applicable Seal Profile.

3. The Validation and Verification Service shall not create Electronic Signatures or Electronic Seals.

Article 12

1. Electronic Timestamp Validation shall determine, where applicable:

1. timestamp integrity;

2. Timestamp Issuer;

3. data reference binding;

4. time information;

5. Status information;

6. Historical State.

2. The Validation and Verification Service shall not create Electronic Timestamps.

Article 13

1. Electronic Attestation Validation shall determine, where applicable:

1. Attestation Issuer;

2. integrity of the Attestation Statement;

3. Source Basis;

4. Attribute applicability;

5. Status;

6. Historical State.

2. Validation shall consider the applicable Attestation Profile.

Certificate and Status validation

Article 14

1. Where Validation depends on Certificates, the Validation and Verification Service shall evaluate:

1. certificate integrity;

2. certificate chain;

3. issuer information;

4. certificate Status;

5. applicable certificate policy;

6. historical validity.

2. Certificate Validation shall be performed according to the applicable Certificate Profile.

Article 15

1. Where Validation requires Status information, the Validation and Verification Service shall determine:

1. Status source;

2. Status authenticity;

3. Status applicability;

4. effective time;

5. historical Status where required.

2. Status information shall be evaluated separately from the identity of the Status source.

Humanitarian Trust List dependency

Article 16

1. Where Validation depends on Humanitarian Trust List information, the Validation and Verification Service shall determine:

1. applicable Trust List Version;

2. authenticity of the Trust List;

3. relevant Entry;

4. published Status;

5. effective time;

6. historical information.

2. Humanitarian Trust List publication shall remain separate from Validation decisions.

3. The Validation and Verification Service shall not create Trust Service Status.

Authentication and Authorisation outcome validation

Article 17

1. Where Validation requires Authentication Outcomes, the Validation and Verification Service shall determine:

1. issuing Authentication Service;

2. Authentication Outcome integrity;

3. Authentication Assurance;

4. validity period;

5. limitations.

2. Authentication Outcome Validation shall not create a new Authentication Event.

Article 18

1. Where Validation requires Authorisation Outcomes, the Validation and Verification Service shall determine:

1. issuing Authorisation Service;

2. Outcome integrity;

3. Policy reference;

4. validity period;

5. scope;

6. limitations.

2. Authorisation Outcome Validation shall not create a new Authorisation decision.

Historical State

Article 19

1. Where reliance requires evaluation at a previous time, the Validation and Verification Service shall determine the applicable Historical State.

2. Historical State determination shall consider:

1. Trust Object Version;

2. Status at the relevant time;

3. dependency Status;

4. applicable Standards;

5. applicable Profiles.

3. Current Status shall not automatically determine Historical State.

Validation Results and Status Responses

Article 20

1. A Validation and Verification Service shall produce a result corresponding to the performed evaluation.

2. A Verification Result shall identify, where applicable:

1. evaluated matter;

2. checks performed;

3. result;

4. limitations.

3. A Validation Result shall identify, where applicable:

1. evaluated matter;

2. evidence used;

3. evaluation time;

4. Status information;

5. Historical State;

6. limitations.

Article 21

1. A Status Response shall identify:

1. Status source;

2. evaluated Status;

3. effective time;

4. applicable scope;

5. limitations.

2. A Status Response shall remain separate from a Validation Result.

Service lifecycle management

Article 22

1. The lifecycle of a Validation and Verification Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting Validation reliability shall be recorded.

Article 23

1. Changes affecting Validation and Verification Services shall be assessed before implementation.

2. The assessment shall consider:

1. supported Trust Objects;

2. supported Trust Services;

3. Status dependencies;

4. Profiles;

5. Technical Specifications;

6. Standards.

3. Material changes shall be managed according to applicable Change Control requirements.

Records and evidence

Article 24

1. The Validation and Verification Service shall maintain records sufficient to reconstruct:

1. Verification requests;

2. Validation requests;

3. evidence evaluated;

4. evaluation results;

5. Status Responses;

6. Historical State determinations;

7. lifecycle events.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 25

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Trust Object Status;

2. Trust Service Status;

3. Qualified Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
ETSI EN 319 102-1	Validation process requirements for electronic signatures and seals
ETSI TS 119 102-2	Validation report structures where applicable
ETSI TS 119 615	Trust List use and interpretation
ETSI TS 119 612	Trusted List structures where applicable
RFC 5280	Certificate path validation
RFC 6960	Online Certificate Status Protocol where applicable
RFC 3161	Timestamp validation where timestamp tokens are used
RFC 5816	Timestamp certificate identification update
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27701:2025	Privacy management controls where personal data is processed

IDEHA-IG-SVC-FDX-001: Federated Data Exchange Service Implementation

Subject matter and scope

Article 1

1. This Guideline lays down implementation requirements for Federated Data Exchange Services operating under the Trust Framework.

2. This Guideline applies to Trust Service Providers providing Federated Data Exchange Services and Actors operating exchange functions within the applicable Service Scope.

3. This Guideline establishes requirements for:

1. Federated Data Exchange Service operation;

2. Participant onboarding;

3. Controlled Gateway operation;

4. Endpoint registration and management;

5. Technical Exchange Route operation;

6. request and response exchange lifecycle;

7. Exchange Evidence management;

8. service continuity and lifecycle management.

4. This Guideline applies together with:

1. IDEHA-IG-FED-DOM-001 Federation Domain and Cross-Domain Implementation;

2. IDEHA-IG-ACT-PAR-001 Participation, Roles, Mandates and Representation Implementation;

3. IDEHA-IG-SVC-AUT-001 Authentication Service Implementation;

4. IDEHA-IG-SVC-AUZ-001 Authorisation Service Implementation;

5. IDEHA-IG-SRC-ASO-001 Source and Authoritative Source Implementation;

6. IDEHA-IG-DAT-SEM-001 Controlled Data Elements, Semantics and Data Quality Implementation;

7. IDEHA-IG-SEC-CRY-001 Cryptographic Controls and Cryptographic Agility Implementation;

8. IDEHA-IG-ASR-GEN-001 Assurance, Conformity Assessment and Qualification Implementation.

5. This Guideline does not establish:

1. data-sharing agreements between Actors;

2. Source authority;

3. substantive disclosure decisions;

4. Authorisation Policies;

5. identity information;

6. data semantics;

7. payload business meaning;

8. message schemas;

9. protocol bindings;

10. cryptographic algorithm parameters.

Those matters shall be implemented through the applicable Framework Instruments.

Federated Data Exchange Service scope

Article 2

1. A Federated Data Exchange Service shall operate within an identified Service Scope.

2. The Service Scope shall identify:

1. participating Actors;

2. Federation Domains;

3. Technical Exchange Routes;

4. Endpoints;

5. supported exchange functions;

6. applicable Security Conditions;

7. applicable Technical Specifications.

3. A Federated Data Exchange Service shall not perform exchanges outside its approved Service Scope.

Article 3

1. A Federated Data Exchange Service shall maintain separation between:

1. exchange routing;

2. system Authentication;

3. Authorisation enforcement;

4. payload handling;

5. Exchange Evidence creation.

2. A Federated Data Exchange Service shall not:

1. become the Source Holder;

2. determine the substantive right to disclose data;

3. determine the entitlement of a receiving Actor;

4. modify the meaning of exchanged data.

3. The Federated Data Exchange Service shall transport and process exchange information only within the authorised scope.

Exchange architecture

Article 4

1. A Federated Data Exchange Service shall consist of controlled exchange functions supporting communication between authorised Actors.

2. The exchange architecture shall identify, where applicable:

1. Data Exchange Provider;

2. Controlled Gateway;

3. Participant Actor;

4. Endpoint;

5. Technical Exchange Route;

6. Federation Domain dependencies.

3. The relationship between exchange components shall be maintained as operational evidence.

Article 5

1. A Controlled Gateway shall provide the controlled point through which exchange communication is performed.

2. A Controlled Gateway shall perform, where applicable:

1. system Authentication;

2. route resolution;

3. exchange policy enforcement;

4. request and response handling;

5. Exchange Evidence generation.

3. A Controlled Gateway shall not perform substantive evaluation of the data being exchanged unless separately authorised under another Framework Instrument.

Participant onboarding

Article 6

1. A Federated Data Exchange Service shall establish procedures for onboarding participating Actors.

2. Onboarding shall verify, where applicable:

1. Actor identity;

2. Participation status;

3. Federation Domain membership;

4. Endpoint information;

5. required Security Conditions;

6. required Technical Specifications.

3. Onboarding evidence shall be maintained throughout the participation lifecycle.

Article 7

1. A participating Actor shall maintain information required for exchange operation.

2. The information shall identify, where applicable:

1. Actor Identifier;

2. Participant status;

3. associated Controlled Gateways;

4. permitted Endpoints;

5. applicable exchange scope;

6. lifecycle information.

3. Participation in the Federated Data Exchange Service shall not create Authorisation to access specific data.

Endpoint management

Article 8

1. A Federated Data Exchange Service shall maintain Endpoint information necessary for exchange operation.

2. Endpoint information shall identify:

1. Endpoint Identifier;

2. responsible Actor;

3. service function;

4. Technical Exchange Route;

5. operational Status;

6. applicable Technical Specification.

3. Endpoint information shall remain separate from:

1. Subject Identifier;

2. Trust Object Identifier;

3. Source Identifier.

Article 9

1. Endpoint activation shall require verification that:

1. the Endpoint belongs to the identified Actor;

2. required Authentication mechanisms are available;

3. required Security Conditions are satisfied;

4. applicable Technical Specifications are supported.

2. Endpoint changes affecting exchange reliability shall be managed through applicable Change Control requirements.

Technical Exchange Route

Article 10

1. A Technical Exchange Route shall define the controlled path through which exchange communication occurs.

2. A Technical Exchange Route shall identify, where applicable:

1. originating Endpoint;

2. receiving Endpoint;

3. Controlled Gateways;

4. Federation Domain;

5. applicable Security Conditions;

6. applicable Technical Specifications.

3. A Technical Exchange Route shall not define the substantive purpose or legal basis of data exchange.

Exchange request processing

Article 11

1. A Federated Data Exchange Service shall process exchange requests according to the applicable Exchange Profile.

2. An exchange request shall identify, where applicable:

1. requesting Actor;

2. receiving Actor;

3. requested Endpoint;

4. Controlled Matter;

5. Authorisation Outcome reference;

6. interaction identifier;

7. applicable Technical Specification.

3. The Federated Data Exchange Service shall verify that the request is within the permitted exchange scope.

Article 12

1. Before transmitting a request, the Federated Data Exchange Service shall verify:

1. requesting Participant status;

2. Endpoint availability;

3. Technical Exchange Route availability;

4. required Authentication conditions;

5. required Authorisation conditions.

2. Verification of exchange conditions shall not replace substantive Authorisation decisions.

Response processing

Article 13

1. A Federated Data Exchange Service shall process responses according to the applicable Exchange Profile.

2. Response processing shall maintain:

1. response integrity;

2. response attribution;

3. interaction correlation;

4. delivery evidence.

3. The Federated Data Exchange Service shall not alter the substantive content of received responses.

Authentication and confidentiality

Article 14

1. A Federated Data Exchange Service shall use System Authentication mechanisms appropriate to the applicable Security Conditions.

2. System Authentication shall identify, where applicable:

1. Controlled Gateway;

2. Endpoint;

3. participating system;

4. communication peer.

3. System Authentication shall remain separate from:

1. Subject Authentication;

2. Authorisation;

3. data disclosure permission.

Article 15

1. Exchange communication shall provide protection against:

1. unauthorised disclosure;

2. unauthorised modification;

3. impersonation;

4. replay.

2. The applicable Technical Specification shall define:

1. transport protection;

2. payload protection;

3. message integrity protection;

4. cryptographic mechanisms.

3. Payload protection requirements shall apply independently from transport protection where required by the applicable Profile.

Authorisation enforcement dependency

Article 16

1. A Federated Data Exchange Service shall enforce applicable Authorisation Outcomes before permitting exchange.

2. The enforcement shall verify, where applicable:

1. Outcome integrity;

2. validity period;

3. permitted Actor;

4. permitted receiving Actor;

5. permitted Controlled Matter;

6. obligations and restrictions.

3. The Federated Data Exchange Service shall not create Authorisation Outcomes.

Exchange Evidence

Article 17

1. A Federated Data Exchange Service shall create Exchange Evidence for controlled exchanges.

2. Exchange Evidence shall identify, where applicable:

1. Exchange Evidence Identifier;

2. requesting Actor;

3. receiving Actor;

4. Controlled Gateways;

5. interaction identifier;

6. request and response references;

7. relevant timestamps;

8. Authentication evidence references;

9. Authorisation Outcome reference;

10. exchange result.

3. Exchange Evidence shall not contain exchanged payload data unless required by the applicable Profile.

Article 18

1. Exchange Evidence shall be protected against unauthorised alteration.

2. Protection may include:

1. integrity mechanisms;

2. Electronic Signature;

3. Electronic Seal;

4. Electronic Timestamp;

5. other approved mechanisms.

3. The applicable Profile shall determine required protection conditions.

Failure handling and continuity

Article 19

1. A Federated Data Exchange Service shall maintain procedures for:

1. failed exchanges;

2. unavailable Endpoints;

3. communication failures;

4. Authentication failures;

5. Authorisation failures;

6. recovery.

2. Failure records shall identify:

1. affected exchange;

2. failure condition;

3. responsible component;

4. recovery action.

Article 20

1. A Federated Data Exchange Service shall maintain continuity arrangements.

2. Continuity arrangements shall address:

1. Controlled Gateway availability;

2. configuration recovery;

3. Endpoint recovery;

4. exchange evidence preservation;

5. restoration procedures.

Service lifecycle management

Article 21

1. The lifecycle of a Federated Data Exchange Service shall include, where applicable:

1. preparation;

2. activation;

3. operation;

4. modification;

5. restriction;

6. Suspension;

7. cessation.

2. Lifecycle events affecting exchange reliability shall be recorded.

Article 22

1. Changes affecting a Federated Data Exchange Service shall be assessed before implementation.

2. The assessment shall consider:

1. Federation Domains;

2. Controlled Gateways;

3. Endpoints;

4. Technical Exchange Routes;

5. Security Conditions;

6. Technical Specifications.

3. Material changes shall be managed according to applicable Change Control requirements.

Records and evidence

Article 23

1. The Federated Data Exchange Service shall maintain records sufficient to reconstruct:

1. participant onboarding;

2. Endpoint lifecycle;

3. exchange requests;

4. exchange responses;

5. Authentication dependencies;

6. Authorisation dependencies;

7. Exchange Evidence;

8. incidents.

2. Records shall be protected according to applicable Security Conditions.

Applicable standards

Article 24

1. The standards applicable to this Guideline are set out in Annex I.

2. A standard referenced in Annex I shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Authorisation;

2. Source authority;

3. Trust Service Status;

4. Controlled Effects.

Annex I

Applicable standards

Reference	Application
RFC 8446	TLS 1.3 protected communication
RFC 5280	Certificate validation where certificate-based system authentication is used
RFC 9525	Service identity verification in TLS
RFC 9110	HTTP semantics where HTTP exchange is used
RFC 9113	HTTP/2 where HTTP/2 exchange is used
RFC 9530	HTTP message digest integrity
RFC 9421	HTTP message signatures where message-level integrity is required
OpenAPI Specification 3.2.0	Service interface description where applicable
ISO/IEC 27001:2022	Information security management controls
ISO/IEC 27002:2022	Security control implementation guidance
ISO/IEC 27701:2025	Privacy management controls where personal data is processed
ISO 22301:2019	Business continuity management where continuity requirements apply
ETSI TS 119 612	Trusted List structures where Trust List dependencies apply
ETSI TS 119 615	Trusted List interpretation where Trust List dependencies apply

IDEHA-IG-SVC-FDX-001: Federated Data Exchange Service Implementation

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline establishes implementation requirements for a Federated Data Exchange Service recognised under the Framework.

1.2. This Guideline shall apply to each Trust Service Provider, requesting Actor, responding Actor, Source Holder, Source Steward, Relying Actor, Technical Exchange Route Operator, Intermediary, Endpoint operator and supporting Actor implementing, operating, assessing, supervising or using a Federated Data Exchange Service.

1.3. This Guideline shall govern, where assigned within the Service Scope:

1. Federated Data Exchange Service implementation and operational activation;

2. Provider, participating-Actor, Endpoint, Technical Exchange Route Operator, Intermediary and supporting-Actor responsibilities;

3. federation-policy and configuration distribution;

4. Humanitarian Trust List based discovery and address resolution;

5. exchange-request intake and admissibility;

6. Endpoint Authentication, route resolution and destination resolution;

7. Authorisation and Policy Enforcement;

8. request, response, Trust Object and Trust Service Output exchange;

9. payload signing or sealing before encryption;

10. Transport Confidentiality and Payload Confidentiality;

11. Integrity, Authenticity, correlation, replay, duplication, Status and error controls;

12. Exchange Evidence and Controlled Exchange Results;

13. dependencies, incidents, Continuity, Recovery, qualification and service lifecycle.

1.4. This Guideline shall not:

1. redefine the Federated Data Exchange Service, Exchange Evidence or Controlled Exchange Results;

2. create a separate gateway, messaging, routing, directory, delivery or policy-distribution Trust Service Category;

3. assign access, disclosure permission, acceptance of content, a substantive decision, Source Status, Trust Service Status or Controlled Reliance;

4. transfer governance, Decision Competence or Status Publication responsibility for the Humanitarian Trust List to the Trust Service Provider or a technical operator;

5. require a Source or responding system to store its substantive records within a gateway, route component or shared federation platform;

6. convert a request, response, payload, message, log or transport record into an Electronic Attestation or another Trust Object by implication;

7. prescribe payload semantics, business-data models, exact schemas, encodings, algorithms, parameter values, interfaces, product configurations or test vectors.

1.5. Compliance with this Guideline shall not, by itself, establish Trust Service Status, Service Permission, Technical Exchange Permission, Qualified Status, Source Status, Authorisation, access, disclosure, acceptance, External Legal Status, External Legal Effect or Controlled Reliance.

Article 2: Allocation between Scheme, Profile and Technical Specification

2.1. The applicable Scheme shall identify:

1. the governed purpose and operational context;

2. the participating Actor categories and Federation Domains;

3. the permitted request, response, Trust Object and Trust Service Output categories;

4. the permitted Source and responding-system categories;

5. the applicable purpose, access, disclosure and Reliance Conditions;

6. the applicable safeguards, Review Routes and Remedy Routes.

2.2. The applicable Federated Data Exchange Service Profile shall identify:

1. the Trust Service Provider and Service Scope;

2. the participating Actor, Endpoint, Technical Exchange Route and Federation Domain categories;

3. the permitted exchange patterns and interaction classes;

4. the supported request, response, payload and evidence categories;

5. the Endpoint Authentication and Authorisation requirements;

6. the route-resolution and destination-resolution conditions;

7. the Humanitarian Trust List and Discovery Metadata dependencies;

8. the federation-policy and configuration-package requirements;

9. the payload signing or sealing requirements;

10. the Transport Confidentiality and Payload Confidentiality requirements;

11. the correlation, replay, duplication, sequencing, Status and error controls;

12. the Exchange Evidence and Controlled Exchange Result requirements;

13. the delivery-state, failure-state, timeout and retry conditions;

14. the availability, Continuity and Recovery conditions;

15. the security, monitoring, incident, Retention and historical-reconstruction conditions;

16. the conformity and qualified conditions, where applicable.

2.3. The applicable exchange Profile shall define each permitted interaction pattern, request purpose, requesting and responding Role, payload class, response class, exchange state, time condition, restriction and caveat.

2.4. The applicable Endpoint Profile shall define the Endpoint identity, responsible Actor, permitted service functions, Authentication conditions, Authorisation conditions, Technical Exchange Route bindings, certificate or key dependencies, Status conditions and lifecycle controls.

2.5. The applicable Technical Specification shall define:

1. request and response schemas;

2. exchange envelopes;

3. payload-package structures;

4. Endpoint and Technical Exchange Route identifiers;

5. correlation values;

6. Status codes and error structures;

7. signature, seal and encryption containers;

8. transport and protocol bindings;

9. interface behaviour;

10. cryptographic parameter selections;

11. conformance tests.

Article 3: Implementation Plan

3.1. Before operational activation, the Trust Service Provider shall maintain an approved Implementation Plan for the Federated Data Exchange Service.

3.2. The Implementation Plan shall identify:

1. the Service Scope and Service Permission;

2. the participating Actors and Federation Domains;

3. the gateway, Endpoint and Technical Exchange Route arrangements;

4. the federation-policy and configuration-distribution arrangements;

5. the Humanitarian Trust List and Discovery Metadata dependencies;

6. the Endpoint Authentication arrangements;

7. the Authorisation and Policy Enforcement arrangements;

8. the payload signing or sealing arrangements;

9. the payload-encryption arrangements;

10. the Transport Confidentiality arrangements;

11. the Exchange Evidence and trusted-time arrangements;

12. the dependency, incident, Continuity, Recovery and cessation arrangements;

13. the applicable Scheme, Profile and Technical Specification Versions;

14. the applicable conformity and qualified conditions.

3.3. The Implementation Plan shall identify each Actor having access to plaintext payload information and the authorised purpose, scope and conditions of that access.

3.4. The Implementation Plan shall identify each technical component that processes routing Metadata, Discovery Metadata, certificates, policy packages, configuration packages, payload packages, Exchange Evidence or operational logs.

3.5. The Implementation Plan shall remain consistent with the approved Service Scope and shall be updated following each material change.

3.6. The Implementation Plan shall not create Service Permission, Technical Exchange Permission, access, disclosure, Qualified Status or another Controlled Effect.

Section 2: Service identity, responsibility and federation coordination

Article 4: Service identity and Service Scope

4.1. Each Federated Data Exchange Service shall have an independently identifiable service record.

4.2. The service record shall identify:

1. the Trust Service Provider;

2. the Trust Service Identifier and Version;

3. the Service Scope;

4. the applicable Scheme and Profile Versions;

5. the supported Federation Domains;

6. the supported participating-Actor and Endpoint categories;

7. the supported interaction, request, response and payload classes;

8. the recognised Technical Exchange Routes and route dependencies;

9. the Exchange Evidence and Controlled Exchange Result classes;

10. the Service Status, Service Permission and Qualified Scope, where applicable;

11. the security, Continuity, lifecycle and cessation conditions.

4.3. A shared platform, gateway, network, Endpoint, Technical Exchange Route, product name, operational team or infrastructure component shall not merge the Federated Data Exchange Service with another Trust Service.

4.4. Each materially distinct Service Scope shall remain separately identifiable where differences affect purpose, Federation Domain, Actor category, Endpoint class, exchange pattern, protection, output, Assurance, qualified condition or responsibility.

4.5. Technical availability, discovery, registration, onboarding or testing shall not create Service Permission or Technical Exchange Permission.

Article 5: Responsibilities and separation of functions

5.1. The Trust Service Provider shall remain responsible for the Federated Data Exchange Service within the recognised Service Scope.

5.2. The Trust Service Provider shall identify the Actor responsible for:

1. service governance and Service Permission compliance;

2. federation-policy and configuration-package distribution;

3. Endpoint registration and lifecycle administration;

4. Technical Exchange Route registration and operational control;

5. Humanitarian Trust List discovery and destination resolution;

6. security monitoring and incident handling;

7. exchange-state and error management;

8. Exchange Evidence and Controlled Exchange Result production;

9. Continuity, Recovery and cessation;

10. records, Review and Remedy support.

5.3. A Technical Exchange Route Operator, Intermediary, gateway operator, relay operator or supporting Actor shall perform only the functions expressly assigned by the applicable Profile and Authorisation Outcome.

5.4. Operation of an Endpoint, gateway, directory, route, queue, broker, relay, policy-distribution or monitoring component shall not assign the Role, Mandate, Status or Decision Competence of the requesting Actor, responding Actor, Source Holder, Source Steward, Framework Body or Relying Actor.

5.5. A responding Actor shall retain responsibility for Source access, response generation, disclosure conditions and substantive content.

5.6. The Trust Service Provider shall not become the Source Holder, Source Steward, Attestation Issuer, policy owner or substantive decision-maker merely because the service routes, correlates, logs, protects or evidences an interaction.

5.7. Outsourcing or shared operation shall preserve the responsibility, evidence, security and lifecycle requirements assigned to each Actor and Service Scope.

Article 6: Service Permission and operational activation

6.1. A Federated Data Exchange Service shall enter operational use only where the applicable Service Permission and each required Technical Exchange Permission are effective for the intended scope.

6.2. Before activation, the Trust Service Provider shall verify:

1. service recognition and Service Scope;

2. participating-Actor and Endpoint eligibility;

3. Technical Exchange Route registration and Status;

4. applicable Scheme, Profile and Technical Specification Versions;

5. Endpoint Authentication controls;

6. Authorisation and Policy Enforcement controls;

7. federation-policy and configuration-package controls;

8. Humanitarian Trust List discovery controls;

9. payload signing or sealing controls;

10. Payload Confidentiality controls;

11. Transport Confidentiality controls;

12. Exchange Evidence and trusted-time controls;

13. incident, Continuity and Recovery arrangements;

14. required conformity and qualified conditions.

6.3. Operational activation shall be recorded before the first controlled exchange within the activated scope.

6.4. A component shall not be treated as operationally activated solely because it is reachable, configured, tested or published through Discovery Metadata.

6.5. A material activation condition that cannot be established shall prevent operation within the affected scope.

Article 7: Federation policy and configuration distribution

7.1. The Federated Data Exchange Service shall maintain or use a central policy component for controlled distribution of federation-policy and configuration packages.

7.2. The central policy component shall distribute only packages authorised by the responsible Framework Body or Actor within its assigned competence.

7.3. A federation-policy or configuration package shall identify:

1. the issuing Actor;

2. the package identifier and Version;

3. the applicable Federation Domain and scope;

4. the applicable Actors, Endpoints or Technical Exchange Routes;

5. the applicable policy, Profile and Technical Specification references;

6. the Effective Date and expiry or review time;

7. the predecessor package, where applicable;

8. the applicable restrictions and transition conditions.

7.4. Each federation-policy and configuration package shall be protected by an Electronic Seal attributable to the issuing Actor before distribution.

7.5. Where approval by an identified natural person is required, the package shall contain or reference the applicable Electronic Signature evidence.

7.6. Where proof of existence at an identified time is required, the protected package shall receive an Electronic Timestamp.

7.7. Before use, the Trust Service Provider shall verify and validate:

1. the package identifier and Version;

2. the issuing Actor;

3. the Electronic Seal or Electronic Signature;

4. the applicable Certificate and Status information;

5. the Effective Date and scope;

6. the applicable predecessor and transition relationship.

7.8. A central policy component shall not:

1. create an Authorisation Outcome;

2. define a Source Scope;

3. assign Status;

4. create Technical Exchange Permission;

5. replace a responding Actor’s disclosure decision.

7.9. A locally cached policy or configuration package shall remain derivative, freshness-controlled and traceable to the authoritative package.

Article 8: Humanitarian Trust List discovery and address resolution

8.1. The Federated Data Exchange Service shall use the Humanitarian Trust List and authorised Discovery Metadata as the trusted source for federation discovery and address resolution.

8.2. The Humanitarian Trust List shall contain or reference, where authorised:

1. Actor identifiers;

2. Trust Service Provider identifiers;

3. Trust Service identifiers;

4. service certificates or other digital identity information;

5. Endpoint references;

6. Federation Domain relationships;

7. supported Profiles and Technical Specifications;

8. current and historical Status information;

9. applicable restrictions and Validity Periods.

8.3. Before using Humanitarian Trust List information, the Federated Data Exchange Service shall verify and validate:

1. the authenticity and Integrity of the publication;

2. the Scheme Operator Certificate or other authorised publication identity;

3. the publication Version and sequence information;

4. the applicable Entry;

5. the Entry Status and Effective Date;

6. the Discovery Metadata scope;

7. the applicable Endpoint reference;

8. the applicable Federation Domain;

9. the applicable Freshness Condition.

8.4. A cached or locally replicated Humanitarian Trust List record shall remain derivative, freshness-controlled and traceable to the authoritative publication.

8.5. Inclusion of an Actor, Trust Service, Endpoint or Technical Exchange Route reference in the Humanitarian Trust List shall not create:

1. Authorisation;

2. access;

3. disclosure permission;

4. Technical Exchange Permission;

5. Controlled Reliance.

8.6. The Trust Service Provider shall not operate, control, assign or alter Status through the Humanitarian Trust List.

8.7. A technical operator shall not acquire Decision Competence by hosting, caching, distributing or processing Humanitarian Trust List information.

Section 3: Controlled exchange operation and payload protection

Article 9: Exchange-request intake and admissibility

9.1. Each exchange request shall be independently identifiable and attributable to the requesting Actor and originating Endpoint.

9.2. The request shall contain or reference:

1. the requesting Actor and originating Endpoint;

2. the intended responding Actor or receiving Endpoint;

3. the recognised purpose;

4. the requested action;

5. the requested Controlled Matter or payload class;

6. the applicable Scheme, Profile and Technical Specification Versions;

7. the Controlled Interaction identifier;

8. the Authorisation Outcome reference, where required;

9. the applicable policy and configuration-package references;

10. the applicable restrictions, caveats and correlation information.

9.3. Before admitting the request, the Federated Data Exchange Service shall verify:

1. the identity and current Status of the requesting Actor and originating Endpoint;

2. the applicable Service Permission and Technical Exchange Permission;

3. the current Technical Exchange Route and destination;

4. the applicable Authorisation Outcome;

5. the applicable policy and configuration package;

6. the required payload-protection conditions;

7. the applicable time and Freshness Conditions.

9.4. Request admission shall not create a right to receive a response or require disclosure by the responding Actor.

9.5. The service shall reject, restrict or hold a request where an applicable identity, Status, permission, Technical Exchange Route, security, freshness or policy condition cannot be established.

9.6. A held or rejected request shall receive the Status or error treatment assigned by the applicable Profile without unnecessary disclosure of Protection-Sensitive Information or Security-Sensitive Information.

Article 10: Endpoint Authentication and route resolution

10.1. Each participating Endpoint shall be uniquely identifiable within the applicable Federation Domain and Service Scope.

10.2. The Federated Data Exchange Service shall authenticate each participating Endpoint at the level and frequency assigned by the applicable Profile.

10.3. Endpoint Authentication shall establish the Endpoint identity and current Authentication Outcome but shall not, by itself, establish Authorisation, disclosure permission, Source Status or Controlled Reliance.

10.4. Certificate-based Endpoint Authentication shall use the certificate and validation arrangements assigned by the applicable Endpoint Profile and Technical Specification.

10.5. Route and destination resolution shall use authenticated Humanitarian Trust List information, authorised Discovery Metadata and current federation-policy and configuration packages.

10.6. The service shall detect and prevent:

1. unauthorised route substitution;

2. destination substitution;

3. certificate substitution;

4. Endpoint redirection;

5. downgrade to an unauthorised protocol or protection arrangement.

10.7. A route-resolution result shall not create Technical Exchange Permission or require the responding Actor to disclose information.

10.8. Where an authorised current destination cannot be established, the service shall terminate or hold the interaction according to the applicable Profile.

Article 11: Authorisation, disclosure and Policy Enforcement

11.1. An Authorisation Service or local Policy Enforcement Function shall determine and enforce the applicable exchange permission where required by the Scheme or Profile.

11.2. An Authorisation decision shall remain separate from:

1. Endpoint Authentication;

2. Humanitarian Trust List discovery;

3. route and destination resolution;

4. technical availability;

5. Source access;

6. response generation;

7. payload protection;

8. content acceptance;

9. Controlled Reliance.

11.3. The requesting Actor shall provide or reference the purpose, requested action, target, scope and context required for Authorisation evaluation.

11.4. The responding Actor shall enforce its own access and Disclosure Conditions before releasing a response or payload.

11.5. The Federated Data Exchange Service shall enforce the applicable Authorisation Outcome only within the identified interaction, purpose, Actor, Endpoint, payload class, Technical Exchange Route and Validity Period.

11.6. A previous Authorisation Outcome shall not be reused where the interaction, purpose, Actor, Endpoint, recipient, payload class, Technical Exchange Route, Status or time condition has materially changed.

11.7. The service shall not invent, extend or reinterpret an Authorisation Policy or Authorisation Outcome.

11.8. A successful exchange shall not establish that the exchange was lawful, necessary, accurate or acceptable beyond the conditions evidenced for that interaction.

Article 12: Request, response and Source separation

12.1. A responding Actor shall generate a response only after applying the applicable Source access, purpose, disclosure, data-minimisation, Freshness and Authorisation conditions.

12.2. A Source shall remain under the control of its Source Holder and Source Steward and shall not be required to reside within the Federated Data Exchange Service, gateway or Technical Exchange Route.

12.3. The service shall transport or mediate only the request, response, Trust Object, Trust Service Output or evidence assigned by the applicable exchange Profile.

12.4. A request shall not become an Electronic Attestation merely because it contains statements, identifiers, Attributes or supporting information.

12.5. A response shall not become an Electronic Attestation merely because it contains a statement or originates from a recognised Actor.

12.6. Where a response constitutes or contains an Electronic Attestation, that Electronic Attestation shall remain a separate Trust Object governed by its applicable Framework Instruments.

12.7. The service shall preserve the separation between:

1. the request and its requester;

2. the Source and responding Actor;

3. the response and its substantive Issuer or producer;

4. the exchanged payload and Exchange Evidence;

5. the exchanged payload and Controlled Exchange Result.

12.8. Transformation, aggregation or derivation performed during exchange shall be expressly authorised, attributable and governed by the applicable Profile and shall not transfer Source Status to the resulting output.

Article 13: Payload-package protection

13.1. Each payload shall be placed within a payload package before transmission through a Technical Exchange Route.

13.2. The payload package shall contain or reference:

1. the sending Actor;

2. the intended receiving Actor;

3. the originating and receiving Endpoints;

4. the Controlled Interaction identifier;

5. the recognised purpose;

6. the applicable Profile and Technical Specification Versions;

7. the payload identifier and payload digest;

8. the applicable Authorisation Outcome reference;

9. the creation time;

10. the applicable restrictions and caveats.

13.3. Before Payload Confidentiality is applied, the sending Actor shall protect the plaintext payload package:

1. by an Electronic Seal attributable to the sending Actor; or

2. by an Electronic Signature where the payload package is attributable to a Signatory under the applicable Profile.

13.4. An existing Electronic Signature, Electronic Seal, Electronic Timestamp, Certificate or other object-level protection applied to a Trust Object or Trust Service Output contained in the payload package shall remain intact.

13.5. The sending Actor shall apply Payload Confidentiality to the signed or sealed payload package before that package enters the Technical Exchange Route.

13.6. Payload Confidentiality shall ensure that plaintext access is limited to:

1. the authorised sending Actor;

2. the authorised receiving Actor;

3. each additional processing Actor expressly identified by the applicable Profile and Authorisation Outcome.

13.7. A Trust Service Provider, Technical Exchange Route Operator, Intermediary, gateway operator, relay operator, policy component or monitoring component shall not access the plaintext payload unless separately authorised as a processing Actor for the recognised purpose.

13.8. Decryption material shall not be disclosed to an unrelated Technical Exchange Route, Intermediary, support or monitoring component.

13.9. The receiving Actor shall:

1. decrypt the payload package;

2. verify and validate the Electronic Seal or Electronic Signature applied by the sending Actor;

3. verify the payload digest and package Metadata;

4. verify the applicable Certificate and Status information;

5. reject or isolate the payload where the required protection cannot be established.

13.10. An Electronic Seal, Electronic Signature or encryption mechanism shall not, by itself, authorise collection, processing, exchange, disclosure, onward transfer or Retention.

Article 14: Transport protection, correlation and error handling

14.1. Each Technical Exchange Route shall use HTTPS over TLS 1.3 in accordance with Annex I and the applicable Technical Specification.

14.2. Plain HTTP shall not be used for a Controlled Interaction.

14.3. Transport protection shall provide:

1. Transport Confidentiality;

2. transport Integrity;

3. mutual system Authentication;

4. protection against unauthorised interception and redirection.

14.4. Transport protection shall remain separate from and shall not replace:

1. the Electronic Seal or Electronic Signature applied to the payload package;

2. Payload Confidentiality;

3. object-level protection;

4. Exchange Evidence protection.

14.5. Where the applicable Technical Specification uses HTTP message protection, the exchange envelope shall contain:

1. a content digest;

2. a signature over the selected request or response components;

3. the applicable signature-creation time and validity information;

4. the applicable certificate or key reference.

14.6. Each Controlled Interaction shall have an identifier sufficient to correlate its request, response, Status, evidence, retry and error states.

14.7. The service shall implement controls against:

1. replay;

2. unintended duplicate processing;

3. incorrect sequencing;

4. correlation collision;

5. response substitution;

6. route downgrade.

14.8. A retry shall preserve the relationship with the original interaction and shall not conceal whether an earlier request was processed, refused, failed or remained unresolved.

14.9. Duplicate detection shall not, by itself, determine that a substantive request or response is fraudulent, invalid or unacceptable.

14.10. The service shall assign each interaction the processing, transmission, receipt, refusal, timeout, failure or unable-to-determine state required by the applicable Profile.

14.11. Error information shall be sufficient for authorised diagnosis and Remedy without exposing unnecessary Source content, Protection-Sensitive Information or Security-Sensitive Information.

14.12. A technical success state shall not establish substantive acceptance, delivery of a substantive benefit, completion of a business process or Controlled Reliance.

14.13. An unresolved or ambiguous interaction state shall not be represented as successful delivery or substantive completion.

Section 4: Service outputs, federation and operational resilience

Article 15: Exchange Evidence, operational logs and trusted time

15.1. The Federated Data Exchange Service shall create Exchange Evidence for each Controlled Interaction.

15.2. Exchange Evidence shall contain or reference:

1. the producing Federated Data Exchange Service;

2. the requesting and responding Actors and Endpoints;

3. the Controlled Interaction identifier;

4. the request, response and payload-package references without unnecessary disclosure of content;

5. the payload digest;

6. the sending Actor’s Electronic Seal or Electronic Signature reference;

7. the payload-encryption reference;

8. the relevant times;

9. the Technical Exchange Route and security context;

10. the applicable policy and configuration-package Versions;

11. the Authentication and Authorisation references;

12. the processing, transmission, receipt, refusal or failure state;

13. the applicable restrictions and caveats.

15.3. Exchange Evidence shall remain separate from the exchanged payload and from each Trust Object or Trust Service Output carried through the interaction.

15.4. Exchange Evidence shall be protected by:

1. an Electronic Seal attributable to the producing Federated Data Exchange Service; and

2. an Electronic Timestamp establishing the protected evidence state at an identified time.

15.5. The applicable Profile shall identify where a Qualified Electronic Seal, Qualified Electronic Timestamp or another qualified dependency is required.

15.6. Operational logs shall:

1. use trusted and synchronised time;

2. record attributable security-relevant events;

3. be protected against unauthorised alteration and deletion;

4. preserve event ordering and correlation;

5. exclude plaintext payload content unless expressly authorised.

15.7. Integrity-protected operational-log batches or evidence roots shall be periodically sealed and timestamped at the frequency assigned by the applicable Profile.

15.8. Exchange Evidence and operational-log evidence shall remain available for the Retention period assigned by the applicable Profile and shall support Historical State reconstruction.

15.9. Exchange Evidence shall not, by itself, create access, disclosure permission, acceptance of content, delivery of a substantive benefit, a local business decision or Controlled Reliance.

15.10. Delivery evidence shall remain a subordinate Exchange Evidence function and shall not constitute a separate Trust Service Category.

Article 16: Controlled Exchange Results

16.1. The Federated Data Exchange Service shall create a Controlled Exchange Result where the applicable Profile requires a separately identifiable result of the interaction.

16.2. A Controlled Exchange Result shall contain or reference:

1. the producing Federated Data Exchange Service;

2. the requesting and responding Actors or Endpoints;

3. the Controlled Interaction identifier;

4. the relevant request, response or payload-package reference;

5. the Technical Exchange Route and security context;

6. the result or delivery state;

7. the evaluation time and Validity Period;

8. the applicable restrictions and caveats.

16.3. A Controlled Exchange Result shall remain separate from Exchange Evidence, exchanged content and any local acceptance or business decision.

16.4. A Controlled Exchange Result shall not, by itself, create access, disclosure permission, acceptance of content, delivery of a substantive benefit or Controlled Reliance.

16.5. A Controlled Exchange Result shall be interpreted only against the interaction, evaluation time, Profile Version, Technical Exchange Route, evidence, restrictions and Validity Period identified for that Result.

16.6. Where a Controlled Exchange Result is issued as an Electronic Attestation, that Electronic Attestation shall remain a separate Trust Object governed by the applicable Attestation Profile.

16.7. Qualified Status shall apply to an individual Controlled Exchange Result only through the applicable object-instance qualification conditions.

Article 17: Cross-domain exchange and dependencies

17.1. Cross-domain exchange shall preserve:

1. the identity and responsibility of each participating Actor and Endpoint;

2. the Decision Competence of each Framework Body;

3. the applicable Federation Agreement and Federation Trust Relationship;

4. the Source, Trust Service, Technical Exchange Route, output and Status boundaries;

5. the applicable policy, protection, evidence, Review and Remedy conditions.

17.2. Recognition, listing or discovery in one Federation Domain shall not transfer Service Permission, Technical Exchange Permission, Source Status, Qualified Status or Controlled Reliance to another Federation Domain.

17.3. A parent Federation Domain reference to a nested-domain publication shall not make the parent publication the authoritative source of the nested-domain Status.

17.4. The Trust Service Provider shall identify each material dependency of the Federated Data Exchange Service.

17.5. Dependencies shall include, where applicable:

1. Identification and Authentication Services;

2. Authorisation Services and Policy Enforcement Functions;

3. Validation and Verification Services;

4. Humanitarian Trust List and Discovery Metadata publications;

5. central policy and configuration-distribution components;

6. Sources and responding systems;

7. Endpoints and Technical Exchange Routes;

8. certificates, keys, protection mechanisms and devices;

9. Electronic Signature, Electronic Seal and Electronic Timestamp Services;

10. time, monitoring, logging, queueing and Recovery services;

11. shared infrastructure and outsourced functions.

17.6. Each dependency record shall identify the responsible Actor, function, scope, Status, interface, failure mode, Continuity arrangement and evidence reference.

17.7. Shared infrastructure shall not merge the Federated Data Exchange Service with another Trust Service or transfer responsibility between Providers.

17.8. Failure, restriction, Suspension or Withdrawal of a dependency shall affect the service only within the identified dependent scope.

17.9. The service shall not continue an interaction where a required dependency cannot satisfy the applicable security, Status, Authorisation, protection or qualified condition.

17.10. Dependency substitution shall undergo Change Control and the assessment required by the applicable Profile before operational use.

Article 18: Security incidents, Continuity and Recovery

18.1. The Trust Service Provider shall monitor the Federated Data Exchange Service for:

1. unauthorised access or disclosure;

2. interception or alteration;

3. replay or duplication;

4. misrouting or destination substitution;

5. Endpoint or gateway compromise;

6. policy-package or configuration-package compromise;

7. Humanitarian Trust List substitution or stale-data use;

8. certificate, key or cryptographic compromise;

9. Exchange Evidence or operational-log corruption;

10. dependency failure;

11. other Security Incidents.

18.2. Incident assessment shall identify:

1. the affected Service Scope;

2. the affected Actors, Endpoints, Technical Exchange Routes, interactions, payload classes, outputs and dependencies;

3. whether plaintext or protected content was exposed;

4. whether a policy, configuration or discovery package was affected;

5. the affected Confidentiality, Integrity, Authenticity, availability, Status or qualified condition;

6. the required containment, notification, Status, Review and Remedy actions.

18.3. Incident effects shall propagate only through identified dependencies and within the evidenced affected scope.

18.4. An Endpoint, gateway, Technical Exchange Route or policy-component incident shall not automatically suspend the entire Trust Service Provider or each unrelated Trust Service.

18.5. The Trust Service Provider shall maintain a Continuity Plan covering:

1. alternative Endpoints and Technical Exchange Routes;

2. policy and configuration recovery;

3. Humanitarian Trust List and Discovery Metadata availability;

4. queueing, retry and timeout controls;

5. payload and evidence protection during interruption;

6. Degraded Operation conditions;

7. unresolved-interaction reconciliation;

8. Recovery testing and return-to-service conditions.

18.6. Degraded Operation shall not bypass:

1. Endpoint Authentication;

2. Authorisation and disclosure conditions;

3. policy and configuration validation;

4. payload signing or sealing;

5. Payload Confidentiality;

6. Transport Confidentiality;

7. Exchange Evidence and trusted-time requirements;

8. Status or qualified-dependency conditions.

18.7. The service shall not represent an interaction as completed where processing, delivery or response state remains unresolved.

18.8. Recovery of technical operation shall not automatically reinstate Service Permission, Technical Exchange Permission, dependency Status or Qualified Status.

18.9. The Trust Service Provider shall complete the required Verification, assessment and approval before returning the affected scope to normal operation.

Section 5: Assurance, lifecycle and standards

Article 19: Assurance, Conformity Assessment and qualification

19.1. The Federated Data Exchange Service shall be subject to the Assurance and Conformity Assessment requirements assigned by the applicable Framework Instruments and Profile.

19.2. The evidence package shall demonstrate, within the assessed scope:

1. service identity, Service Scope and Service Permission;

2. Provider, participating-Actor, Endpoint, Technical Exchange Route Operator and supporting-Actor responsibility;

3. federation-policy and configuration-package controls;

4. Humanitarian Trust List discovery and address-resolution controls;

5. request admissibility and interaction classification;

6. Endpoint Authentication and route-resolution controls;

7. Authorisation, disclosure and Policy Enforcement controls;

8. Source, request, response and payload separation;

9. payload signing or sealing before encryption;

10. Transport Confidentiality and Payload Confidentiality;

11. Integrity, Authenticity, correlation, replay, duplication, Status and error controls;

12. Exchange Evidence, operational-log and trusted-time controls;

13. Controlled Exchange Result production;

14. dependency, incident, Continuity and lifecycle controls.

19.3. Qualified Federated Data Exchange Service Status shall require the applicable decision-based qualification route and each required qualified dependency.

19.4. Qualified Trust Service Provider Status shall not, by itself, qualify the Federated Data Exchange Service.

19.5. Qualified Federated Data Exchange Service Status shall not transfer to:

1. Exchange Evidence;

2. a Controlled Exchange Result;

3. a requesting Actor, responding Actor, Endpoint, Technical Exchange Route Operator or Intermediary;

4. a Source, Trust Object, Trust Service Output or payload;

5. a Technical Exchange Route, Certificate, key, mechanism or device;

6. another Trust Service, output or component.

19.6. Each individual Exchange Evidence object or Controlled Exchange Result shall receive Qualified Status only through the applicable object-instance qualification conditions.

19.7. Framework qualification shall not, by itself, assign External Legal Status or External Legal Effect.

19.8. A material unresolved non-conformity shall prevent operation within the affected scope until the applicable corrective, restriction, Suspension or reassessment condition has been satisfied.

Article 20: Service lifecycle, change, transition and cessation

20.1. The Federated Data Exchange Service lifecycle shall include proposal, assessment, recognition, activation, operation, surveillance, restriction, Suspension, Correction, change, transition, Withdrawal, cessation and archival treatment.

20.2. The Trust Service Provider shall apply Change Control to each material change affecting:

1. the Service Scope or Service Permission;

2. a participating Actor, Endpoint, Technical Exchange Route, Federation Domain or interaction class;

3. a request, response, payload or output class;

4. the federation-policy or configuration-distribution model;

5. the Humanitarian Trust List discovery or address-resolution model;

6. the Authentication, Authorisation, disclosure or Policy Enforcement model;

7. the payload signing, sealing or encryption model;

8. the Transport Confidentiality model;

9. the correlation, replay, duplication, Status or error model;

10. an Exchange Evidence, operational-log or Controlled Exchange Result arrangement;

11. a Source, Trust Service, protection or infrastructure dependency;

12. the incident, Continuity or Recovery arrangement;

13. the Qualified Scope or assessed conformity basis.

20.3. A material change shall undergo the assessment, testing, approval and publication required by the applicable Framework Instrument before operational use.

20.4. A transition between service Versions shall preserve:

1. Controlled Interaction identifiers;

2. request and response state;

3. Authentication and Authorisation evidence;

4. policy and configuration-package references;

5. Humanitarian Trust List and Discovery Metadata references;

6. Technical Exchange Route and Endpoint references;

7. payload-package and protection references;

8. Exchange Evidence and Controlled Exchange Results;

9. Status and dependency references;

10. Historical State.

20.5. Restriction, Suspension, Withdrawal or cessation of the Federated Data Exchange Service shall not automatically invalidate Exchange Evidence or Controlled Exchange Results created before the Effective Date of that action.

20.6. Earlier outputs shall remain subject to their own Validation basis, Status, dependencies, lifecycle and Historical State.

20.7. Before cessation, the Trust Service Provider shall implement an approved cessation plan covering:

1. pending, queued and unresolved interactions;

2. requesting and responding Actor, Endpoint and Technical Exchange Route dependencies;

3. federation-policy and configuration-package continuity;

4. Humanitarian Trust List and discovery dependencies;

5. request, response, output and evidence delivery;

6. unresolved-state reconciliation;

7. continuing Validation and Status support;

8. record Retention, preservation and transfer;

9. dependency termination;

10. affected participating-Actor and Relying Actor notification;

11. incident, Review and Remedy continuity;

12. final Service Status and publication actions.

20.8. Cessation of technical operation shall not remove continuing security, Confidentiality, Retention, Validation, Status, Review, Remedy or historical-reconstruction obligations.

20.9. Cessation shall not transfer Source responsibility, Authorisation responsibility, Humanitarian Trust List responsibility or Controlled Reliance responsibility to the Trust Service Provider or a successor service.

Article 21: Reference standards and specifications

21.1. The reference standards and specifications applicable to the implementation of this Guideline are set out in Annex I.

21.2. A reference identified in Annex I shall apply only within the implementation function, scope and condition identified in that Annex.

21.3. Exact algorithms, parameter sets, Certificate Profiles, signature and seal formats, timestamp profiles, payload schemas, protocol bindings and test conditions shall be selected through the applicable Profile and Technical Specification.

21.4. Standards governed principally by the following Framework Instruments shall apply through those instruments and shall not be repeated in Annex I:

1. Electronic Signature and Electronic Seal standards;

2. Electronic Timestamp standards;

3. Certificate issuance and Validation standards;

4. Humanitarian Trust List publication standards;

5. cryptographic algorithm and post-quantum transition standards;

6. general Trust Service Provider, security and Continuity standards.

21.5. Conformity with a reference standard or specification shall constitute evidence only for the requirements and scope mapped to that reference.

21.6. Conformity with a reference standard or specification shall not, by itself, create Service Permission, Technical Exchange Permission, Qualified Status, Authorisation, access, disclosure, acceptance or Controlled Reliance.

Annex I: Reference standards and specifications

Reference	Implementation function	Applicability and controlled treatment
RFC 9846, The Transport Layer Security Protocol Version 1.3, 2026	Transport Confidentiality and mutually authenticated protected communication	Mandatory for Technical Exchange Routes. RFC 8446 is superseded for new implementations. The applicable Technical Specification shall define the permitted TLS configuration and shall prohibit unauthorised downgrade.
RFC 9110, HTTP Semantics, 2022	HTTP request and response semantics	Mandatory where HTTP-based exchange is selected. Only the https URI scheme shall be used for Controlled Interactions.
RFC 9525, Service Identity in TLS, 2023	Verification of system, service and Endpoint identity	Mandatory where service identity is represented through X.509 Certificates in TLS.
RFC 9530, Digest Fields, 2024	Integrity digests for HTTP content and representations	Mandatory for HTTP-based exchange envelopes carrying a payload or payload reference.
RFC 9421, HTTP Message Signatures, 2024	Protection of selected HTTP request and response components	Mandatory where the applicable Technical Specification uses HTTP-based exchange. It shall protect exchange-envelope and routing Metadata and shall not replace the Electronic Seal or Electronic Signature applied to the payload package.
RFC 7516, JSON Web Encryption, 2015	Payload Confidentiality for JSON-based payload packages	Conditionally mandatory where the applicable Technical Specification selects a JSON-based encrypted payload package.
RFC 5652, Cryptographic Message Syntax, as updated by RFC 8933 and RFC 9629	Payload Confidentiality for binary, document and format-neutral payload packages	Conditionally mandatory where the applicable Technical Specification selects CMS EnvelopedData. Cryptographic mechanisms and migration conditions shall be selected through the Cryptographic Controls and Cryptographic Agility instruments.
RFC 9052, CBOR Object Signing and Encryption: Structures and Process, 2022	Payload protection for CBOR-based payload packages	Conditionally mandatory where the applicable Technical Specification selects a CBOR-based payload package.
RFC 9053, CBOR Object Signing and Encryption: Initial Algorithms, 2022	Algorithm identifiers used with COSE	Applicable only together with the cryptographic mechanisms selected through the Cryptographic Controls and Cryptographic Agility instruments.
RFC 9457, Problem Details for HTTP APIs, 2023	Common technical error representation	Mandatory for HTTP-based error responses unless the applicable Technical Specification establishes a stricter compatible profile. Error responses shall not disclose unnecessary Protection-Sensitive Information or Security-Sensitive Information.
RFC 9562, Universally Unique IDentifiers, 2024	Controlled Interaction, request, response and evidence identifiers	Mandatory where UUIDs are selected by the applicable Technical Specification. An interaction identifier shall not serve as a Subject Identifier, Identification Number, Trust Service Identifier or access credential.

IDEHA-IG-ASR-QLF-001: Assurance and Qualification Implementation

Version: 0.1

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for Assurance evaluation, Conformity Assessment and the preparation, maintenance and lifecycle support of qualification under the Framework.

1.2. This Guideline shall apply to each Framework Body, Conformity Assessment Body, Responsible Actor, applicant for qualification, Trust Service Provider, Source Holder, Source Steward, Issuer and supporting Actor involved in an Assurance evaluation, Conformity Assessment or qualification process.

1.3. This Guideline shall govern, where applicable:

1. implementation planning;

2. requirement and evidence mapping;

3. Assurance evaluation;

4. Conformity Assessment preparation and conduct;

5. competence, independence and conflict controls;

6. findings, non-conformities and corrective action;

7. Conformity Assessment Results;

8. qualification evidence packages;

9. Object-Instance Qualification implementation;

10. qualified dependencies and composite arrangements;

11. Status Publication handoff;

12. surveillance, reassessment and material-change treatment;

13. lifecycle-action and reinstatement evidence;

14. Historical State reconstruction.

1.4. This Guideline shall not:

1. establish an Assurance Domain or Assurance Level;

2. establish an eligible qualified category;

3. establish or modify a qualification route;

4. assign Decision Competence;

5. assign recognition, Service Permission, Technical Exchange Permission or Qualified Status;

6. create a Trust Service Category, Trust Object Category, Source category or Controlled Effect;

7. treat an Assurance outcome or Conformity Assessment Result as a qualification decision;

8. prescribe technical thresholds, scoring formulae, algorithms, parameter values, test vectors, schemas, interfaces or product configurations assigned to a Profile or Technical Specification;

9. extend Qualified Status from one Status-Bearing Matter, Qualified Scope, Version, configuration, dependency or period to another.

1.5. Compliance with this Guideline shall not, by itself, establish an Assurance Level, positive Conformity Assessment Result, qualification decision, Qualified Status, recognition, operational activation, External Legal Status, External Legal Effect or permission for Controlled Reliance.

Article 2: Implementation Plan and responsibilities

2.1. Before an Assurance evaluation or Conformity Assessment begins, the Responsible Actor shall maintain an approved Implementation Plan.

2.2. Before an application for Decision-Based Qualification is submitted, the applicant shall ensure that the Implementation Plan covers the qualification process and the intended Qualified Scope.

2.3. The Implementation Plan shall identify:

1. the Assurance Object or assessment subject;

2. the intended assessment or qualification purpose;

3. the applicable Profile and Version;

4. the proposed scope;

5. the applicable Framework requirements;

6. the applicable Recognised Standards and Technical Specifications;

7. the Responsible Actors;

8. the Conformity Assessment Body, where applicable;

9. the required evidence;

10. the evaluation and assessment methods;

11. the material dependencies;

12. the expected schedule and decision gates;

13. the surveillance and reassessment arrangements;

14. the change, lifecycle and historical-evidence arrangements.

2.4. Where several Controlled Matters are evaluated together, the Implementation Plan shall identify each Controlled Matter and its scope separately.

2.5. A shared Provider, system, location, component, assessment activity or evidence source shall not merge the identity, scope, outcome or Qualified Status of separate Controlled Matters.

2.6. The Responsible Actor shall update the Implementation Plan where a material change affects the planned scope, requirements, evidence, methods, dependencies, schedule or intended qualification outcome.

2.7. An Implementation Plan shall not create an Assurance outcome, Conformity Assessment Result or Qualified Status.

Article 3: Requirement and evidence mapping

3.1. The Responsible Actor shall maintain a requirement and evidence map for each Assurance evaluation, Conformity Assessment and application for qualification.

3.2. The requirement and evidence map shall identify:

1. each applicable requirement;

2. the Framework Instrument and Version establishing the requirement;

3. the Controlled Matter and scope to which the requirement applies;

4. the evidence required to evaluate the requirement;

5. the Actor responsible for producing or maintaining that evidence;

6. the evidence source and Version;

7. the applicable Freshness Condition;

8. the evaluation or assessment method;

9. the resulting finding or conclusion;

10. each limitation, caveat or unresolved matter.

3.3. A reference to a Recognised Standard shall identify the exact edition, selected provisions, applicable scope and each approved adaptation or exclusion.

3.4. Evidence supporting one requirement or Controlled Matter shall not be treated as evidence of another requirement or Controlled Matter unless the requirement and evidence map expressly establishes that relationship.

3.5. Evidence derived from another record, assessment or result shall identify:

1. the originating evidence;

2. the derivation method;

3. the responsible Actor;

4. the derivation time;

5. the applicable Version;

6. each limitation introduced by the derivation.

3.6. A missing, stale, conflicting, inaccessible or unreliable item of evidence shall be recorded and reflected in the applicable evaluation, finding, conclusion or decision package.

3.7. An unresolved evidence gap shall not be represented as a satisfied requirement.

Section 2: Assurance implementation

Article 4: Assurance evaluation planning

4.1. Before an Assurance evaluation begins, the Responsible Actor shall prepare an evaluation plan.

4.2. The evaluation plan shall identify:

1. the Assurance Object;

2. each applicable Assurance Domain;

3. the applicable Assurance Conditions;

4. the Assurance Level or outcome class selected by the applicable Profile;

5. the evidence requirements;

6. the evaluation methods;

7. the material dependencies;

8. the evaluation time and Validity Period;

9. the competence and independence requirements applicable to the evaluator;

10. the treatment of uncertainty, conflicting evidence and unavailable dependencies;

11. the human-review conditions, where applicable.

4.3. Assurance evaluation shall be performed separately for each applicable Assurance Domain.

4.4. Assignment of the same Assurance Level in different Assurance Domains shall not establish equivalence between those Domains.

4.5. A composite Assurance evaluation shall apply only the combination method established by the applicable Profile.

4.6. A qualified dependency shall be evaluated as a condition and shall not transfer Qualified Status or an Assurance Level to the Assurance Object.

4.7. The evaluation plan shall identify each condition requiring re-evaluation following a material change.

Article 5: Assurance evidence and evaluation conduct

5.1. Assurance evidence shall be attributable, relevant, sufficiently current, protected and traceable to the Assurance Object and Assurance Condition for which it is used.

5.2. The evaluator shall verify, where applicable:

1. the evidence identity and source;

2. the Actor responsible for the evidence;

3. the evidence Version;

4. the evidence creation and evaluation times;

5. the evidence Integrity and Authenticity;

6. the applicable Freshness Condition;

7. the relationship between the evidence and the Assurance Object;

8. each restriction or limitation.

5.3. Evaluation methods shall be appropriate to the Assurance Domain, Assurance Condition, evidence type and potential consequence of an incorrect outcome.

5.4. Evaluation methods shall include, where applicable:

1. document and record review;

2. observation;

3. interview;

4. testing;

5. inspection;

6. sampling;

7. independent confirmation;

8. technical Verification or Validation;

9. historical-evidence reconstruction.

5.5. Sampling shall identify the population, sampling basis, sample size, selection method, period and limitation of the conclusion supported by the sample.

5.6. Technical testing alone shall not establish an Assurance outcome where organisational, governance, personnel, Source, lifecycle, security, safeguard or dependency conditions also apply.

5.7. An evaluator shall not issue a positive Assurance outcome where the evidence is insufficient to establish the required Assurance Conditions.

5.8. An unable-to-determine outcome shall remain distinguishable from a negative outcome.

Article 6: Assurance evaluation record

6.1. Each completed Assurance evaluation shall produce an evaluation record.

6.2. The evaluation record shall identify:

1. the Assurance Object;

2. the applicable Assurance Domains;

3. the applicable Profile and Version;

4. the Assurance Conditions evaluated;

5. the evidence considered;

6. the evaluation methods;

7. the findings;

8. the resulting Assurance Level or outcome class;

9. each dependency;

10. each limitation, caveat and unresolved matter;

11. the evaluation time;

12. the Validity Period;

13. the evaluator and responsible Actor;

14. the conditions requiring re-evaluation.

6.3. The evaluation record shall distinguish:

1. evidence;

2. evaluator findings;

3. the Assurance outcome;

4. recommendations;

5. unresolved matters.

6.4. An Assurance evaluation record shall remain separate from a Conformity Assessment Result and qualification decision.

6.5. A change affecting the Assurance Object, applicable Profile, evidence basis, dependency, configuration or Assurance Condition shall trigger re-evaluation where required by the applicable Profile.

6.6. A superseded or corrected Assurance evaluation record shall remain identifiable for Historical State, Review and Remedy purposes.

Section 3: Conformity Assessment implementation

Article 7: Assessment request and scope confirmation

7.1. A request for Conformity Assessment shall identify:

1. the assessment subject;

2. the requesting Actor;

3. the purpose of the assessment;

4. the proposed assessment scope;

5. the applicable requirements and Versions;

6. the applicable Profile and Technical Specifications;

7. the operational locations and Controlled Environments;

8. the systems, components, mechanisms and devices included in the scope;

9. the material third-party and outsourced dependencies;

10. the intended period of applicability;

11. the intended use of the Conformity Assessment Result.

7.2. Before accepting the request, the Conformity Assessment Body shall confirm:

1. that the assessment subject and scope are sufficiently identified;

2. that the applicable requirements are available and capable of assessment;

3. that the Conformity Assessment Body has the required recognised scope, competence and resources;

4. that independence and conflict requirements are satisfied;

5. that the proposed assessment period is sufficient;

6. that any required accreditation or equivalent competence evidence is current and applicable.

7.3. The confirmed assessment scope shall identify each assessed Controlled Matter separately.

7.4. Assessment of a Trust Service Provider shall remain separate from assessment of each Trust Service provided by that Trust Service Provider.

7.5. Assessment of a Trust Service shall remain separate from assessment of its outputs, Trust Objects, Sources, mechanisms, devices and dependencies.

7.6. An assessment covering several Controlled Matters shall produce separately identifiable findings and conclusions for each assessment subject and scope.

7.7. A change to the confirmed scope shall be recorded and accepted by the relevant Actors before the affected assessment activity proceeds.

7.8. A Conformity Assessment Body shall not issue a conclusion outside its recognised or accredited scope.

Article 8: Competence, independence and subcontracting

8.1. A Conformity Assessment Body shall assign personnel having the competence required for the assessment subject, assessment methods, Framework requirements, applicable standards and technical environment.

8.2. The Conformity Assessment Body shall maintain a competence record identifying:

1. the required competence areas;

2. the assigned personnel;

3. relevant qualifications and experience;

4. competence evaluation;

5. continuing competence activities;

6. each limitation on assigned functions.

8.3. The Conformity Assessment Body shall identify and manage actual, potential and perceived conflicts of interest before and during the assessment.

8.4. A person or organisational function shall not:

1. assess its own operational performance where independent assessment is required;

2. make a certification conclusion concerning a matter for which it has incompatible operational responsibility;

3. assess a matter where prior consultancy or implementation activity impairs independence;

4. participate in both the assessment and independent review where those functions are required to remain separate.

8.5. Where a conflict cannot be controlled, the affected person, function or Conformity Assessment Body shall not perform the assessment activity.

8.6. Subcontracting shall identify:

1. the subcontracted activity;

2. the subcontractor;

3. the competence and independence requirements;

4. the applicable standard;

5. the evidence and reporting requirements;

6. the access and confidentiality conditions.

8.7. The recognised Conformity Assessment Body shall retain responsibility for each subcontracted assessment activity and for the resulting Conformity Assessment Result.

8.8. A subcontractor shall not acquire Conformity Assessment Body recognition or Decision Competence by reason only of performing a subcontracted activity.

8.9. A certification conclusion made by a Conformity Assessment Body shall remain separate from the qualification decision made by the competent Framework Body.

Article 9: Assessment plan and conduct

9.1. The Conformity Assessment Body shall prepare an assessment plan before substantive assessment activity begins.

9.2. The assessment plan shall identify:

1. the assessment subject and scope;

2. the applicable requirements and Versions;

3. the assessment team and assigned functions;

4. the assessment methods;

5. the operational locations and Controlled Environments;

6. the systems, components, mechanisms, devices and dependencies to be examined;

7. the allocated assessment time and resources;

8. the sampling method, where applicable;

9. the testing and inspection activities;

10. the assessment schedule;

11. the reporting and review arrangements;

12. the treatment of confidential, personal, Protection-Sensitive and Security-Sensitive Information.

9.3. The allocated assessment time and resources shall be proportionate to the scope, complexity, risk, number of locations, number of Trust Services, dependency structure and intended Qualified Scope.

9.4. The assessment shall be conducted against the requirements and Versions applicable to the confirmed assessment scope.

9.5. The Conformity Assessment Body shall obtain sufficient evidence through examination, testing, inspection, observation, interview, sampling and record review to support each material finding.

9.6. Remote assessment methods shall be used only where they provide evidence sufficient for the requirement being assessed.

9.7. The Conformity Assessment Body shall verify the identity, source, Integrity, relevance and period of applicability of material evidence.

9.8. The assessed Actor shall provide authorised access to the personnel, records, systems, locations and evidence required for the assessment.

9.9. A limitation preventing complete assessment of a requirement shall be recorded and reflected in the relevant finding and conclusion.

9.10. The Conformity Assessment Body shall not infer conformity from the absence of detected evidence of non-conformity.

Article 10: Findings, non-conformities and corrective action

10.1. Each assessment finding shall identify:

1. the assessment subject and affected scope;

2. the applicable requirement and Version;

3. the evidence examined;

4. the assessment method;

5. the finding;

6. the actual or potential effect;

7. the responsible assessor;

8. the assessment time.

10.2. A non-conformity shall identify:

1. the failed requirement;

2. the affected Controlled Matter and scope;

3. the evidence basis;

4. the effect on Assurance, security, lifecycle, qualification or Controlled Reliance;

5. the required corrective action;

6. the completion period;

7. the Verification and closure conditions.

10.3. A material non-conformity shall prevent a positive assessment conclusion for the affected scope.

10.4. Where the assessment supports Qualified Trust Service Provider Status or Qualified Trust Service Status, each non-conformity against a mandatory qualified requirement shall be closed before a positive certification conclusion is issued.

10.5. Corrective-action evidence shall identify:

1. the correction performed;

2. the root cause where required;

3. the affected systems, records, processes or dependencies;

4. the completion time;

5. the responsible Actor;

6. the Verification performed;

7. the closure conclusion.

10.6. Closure of a non-conformity shall be verified by the Conformity Assessment Body or another Actor expressly authorised by the applicable assessment arrangement.

10.7. An observation or opportunity for improvement shall remain distinguishable from a non-conformity.

10.8. An observation or opportunity for improvement shall not be used to conceal or downgrade a failure to satisfy a mandatory requirement.

10.9. A finding or non-conformity shall not, by itself, restrict, suspend, withdraw or revoke Status.

Article 11: Conformity Assessment Result

11.1. A completed Conformity Assessment shall produce a Conformity Assessment Result.

11.2. The Conformity Assessment Result shall identify:

1. the assessment subject;

2. the assessed scope;

3. the applicable requirements and Versions;

4. the applicable Profile and Technical Specifications;

5. the Conformity Assessment Body;

6. the assessment team;

7. the assessment period;

8. the assessment methods;

9. the evidence basis;

10. each finding and non-conformity;

11. each limitation and caveat;

12. the corrective-action and closure status;

13. the assessment conclusion;

14. the issue date;

15. the period of applicability;

16. the conditions requiring surveillance or reassessment.

11.3. Where a certification arrangement is used, the Conformity Assessment Result shall contain or reference:

1. the certification conclusion;

2. any certificate issued by the Conformity Assessment Body;

3. the certification scope;

4. the issue and expiry dates;

5. the applicable surveillance conditions.

11.4. A Conformity Assessment Result covering several Controlled Matters shall state a separate conclusion for each assessed matter and scope.

11.5. A positive Conformity Assessment Result shall not, by itself, assign recognition, Service Permission, Technical Exchange Permission, operational activation or Qualified Status.

11.6. The Conformity Assessment Body shall protect the Conformity Assessment Result against unauthorised alteration, deletion and disclosure.

11.7. The assessed Actor shall receive the complete Conformity Assessment Result and the evidence references necessary for submission to the competent Framework Body.

11.8. A corrected or superseded Conformity Assessment Result shall remain identifiable and linked to its predecessor.

Section 4: Qualification implementation

Article 12: Decision-Based Qualification evidence package

12.1. An applicant for Decision-Based Qualification shall prepare a qualification evidence package for submission to the competent Framework Body.

12.2. The qualification evidence package shall identify:

1. the eligible Status-Bearing Matter;

2. its stable identifier, category and Version;

3. the applicant and Responsible Actor;

4. the applicable Qualified Profile and Version;

5. the proposed Qualified Scope;

6. the applicable Conformity Assessment Result;

7. each non-conformity and its closure status;

8. the material qualified dependencies;

9. the evidence supporting each qualified condition;

10. the applicable security, Continuity and lifecycle conditions;

11. the proposed Effective Date and review date;

12. the proposed surveillance and reassessment arrangements;

13. the proposed restrictions and caveats;

14. the publication information required following a qualification decision;

15. the applicable Review Route.

12.3. A separate qualification evidence package shall be maintained for each:

1. Trust Service Provider;

2. Trust Service;

3. Authoritative Source;

4. creation mechanism or device;

5. other matter subject to Decision-Based Qualification under the Framework.

12.4. A package covering several related matters shall preserve the separate identity, scope, evidence and requested outcome of each matter.

12.5. The proposed Qualified Scope shall not exceed the assessed scope.

12.6. The applicant shall identify each material limitation, uncertainty, dependency and unresolved matter in the qualification evidence package.

12.7. The competent Framework Body shall receive the complete evidence package before the qualification decision is prepared.

12.8. Submission, acceptance or technical completeness of the qualification evidence package shall not create Qualified Status.

Article 13: Object-Instance Qualification implementation

13.1. A Responsible Actor implementing Object-Instance Qualification shall maintain a controlled process for evaluating each eligible Trust Object or Trust Service Output against the applicable Qualified Object Profile.

13.2. The process shall verify, where applicable:

1. the identity and category of the object or output;

2. the applicable Qualified Object Profile and Version;

3. the required issuing or producing Trust Service Status;

4. the required qualified dependencies;

5. the creation or issuance evidence;

6. the required content and Metadata;

7. the required protection mechanism;

8. the applicable lifecycle and Status information;

9. the applicable Validation requirements.

13.3. The process shall produce or reference a Validation Result confirming whether the applicable qualified conditions were satisfied.

13.4. The object-instance qualification record shall identify:

1. the Trust Object or Trust Service Output;

2. the Qualified Object Profile and Version;

3. the issuing or producing Trust Service;

4. each qualified dependency and its relevant Status;

5. the evaluation time;

6. the creation or issuance time;

7. the evidence considered;

8. the Validation Result;

9. each limitation and caveat.

13.5. Object-Instance Qualification shall not require an individual Framework Decision unless the Framework expressly assigns such a decision.

13.6. Failure of an individual object or output to satisfy a qualified condition shall prevent Qualified Trust Object Status for that object or output and shall not, by itself, alter the Status of its Issuer, Trust Service Provider, Trust Service, Source, mechanism, device or dependency.

13.7. An object-instance qualification record shall remain available for Historical Validation during the applicable Retention period.

Article 14: Qualified dependencies and composite arrangements

14.1. Each qualified dependency shall be recorded and evaluated within the scope and time for which it is required.

14.2. The qualified-dependency record shall identify:

1. the dependent Controlled Matter;

2. the supporting Controlled Matter;

3. the dependency type;

4. the required Status and Qualified Scope;

5. the applicable Version or configuration;

6. the relevant time condition;

7. the evidence and Status source;

8. the effect of restriction, Suspension, Withdrawal, Revocation, expiry or unavailability.

14.3. Qualified Status assigned to a dependency shall not transfer to the dependent Controlled Matter.

14.4. A composite arrangement shall preserve separate identification of:

1. each assessment subject;

2. each Assurance Object;

3. each qualified dependency;

4. each applicable requirement;

5. each finding;

6. each assessment or qualification outcome.

14.5. The applicable Profile shall establish the rule for combining Assurance outcomes, assessment findings or dependency conditions.

14.6. A composite arrangement shall not derive an overall positive conclusion solely from the highest Assurance Level, strongest dependency or most favourable constituent result.

14.7. Failure or unavailability of a required qualified dependency shall prevent a positive qualified outcome within the affected dependent scope.

14.8. Substitution of a qualified dependency shall undergo the assessment and Change Control required by the applicable Profile before operational use.

14.9. Historical evaluation shall use the dependency Status, Version, configuration and scope applicable at the relevant past time.

Article 15: Decision and Status Publication handoff

15.1. Following a Framework Decision assigning, restricting, suspending, withdrawing, revoking or reinstating Qualified Status, the Responsible Actor shall prepare the authorised Status Publication information.

15.2. The Status Publication information shall identify:

1. the qualified Status-Bearing Matter;

2. its stable identifier and category;

3. the Qualified Scope;

4. the applicable Qualified Profile and Version;

5. the Effective Date;

6. the Validity Period or review date;

7. each restriction and caveat;

8. the Framework Decision reference;

9. the responsible Framework Body;

10. the applicable discovery or service identity information;

11. the predecessor Status entry, where applicable.

15.3. The Responsible Actor shall transmit the authorised information to the function responsible for Status Publication.

15.4. Before publication, the publication function shall verify consistency between:

1. the Framework Decision;

2. the Status-Bearing Matter identifier;

3. the Qualified Scope;

4. the Qualified Profile and Version;

5. the Effective Date;

6. the published restrictions and caveats.

15.5. A technical operator shall not alter the qualified decision, Qualified Scope, Effective Date, restriction or lifecycle state contained in the authorised publication information.

15.6. Individual high-volume Trust Objects and Trust Service Outputs shall not receive Humanitarian Trust List Entries unless the Framework expressly requires individual publication.

15.7. Qualified Trust Object Status shall ordinarily be evidenced through the object or output, applicable Qualified Object Profile, issuing-service Status, dependency Status, Validation Result and authorised Status information.

15.8. A publication error shall be corrected through the applicable publication and Correction processes without altering the underlying Framework Decision.

Section 5: Surveillance and qualification lifecycle

Article 16: Surveillance, reassessment and material change

16.1. Each matter subject to continuing Assurance, Conformity Assessment or Decision-Based Qualification shall have a surveillance and reassessment plan.

16.2. The plan shall identify:

1. the subject and scope;

2. the applicable requirements and Versions;

3. the surveillance frequency;

4. the surveillance methods;

5. the evidence to be reviewed;

6. the material-change triggers;

7. the responsible Actors;

8. the reporting and escalation arrangements;

9. the conditions requiring full reassessment.

16.3. A Qualified Trust Service Provider and each Qualified Trust Service shall undergo at least one surveillance Conformity Assessment within each twelve-month period.

16.4. A shorter surveillance interval shall apply where required by the applicable Qualified Profile, Framework Decision, risk assessment, incident, dependency condition or previous finding.

16.5. Surveillance of several Trust Services during one assessment activity shall preserve separate evidence, findings and conclusions for each Trust Service and Qualified Scope.

16.6. Reassessment shall occur where a material change affects:

1. the assessed or qualified scope;

2. the applicable Profile, requirement or Recognised Standard;

3. governance or organisational arrangements;

4. operational locations or Controlled Environments;

5. systems, components, mechanisms or devices;

6. material third parties or outsourced functions;

7. security, Continuity or safeguard conditions;

8. Sources or other material dependencies;

9. evidence, testing or monitoring arrangements;

10. a Qualified Scope or qualified dependency.

16.7. The Responsible Actor shall notify the competent Framework Body and Conformity Assessment Body of a material change within the period assigned by the applicable Profile or Framework Decision.

16.8. Where prior assessment is required, the changed matter shall not operate under the earlier assessed or Qualified Scope until that assessment and the required decision are complete.

16.9. A surveillance finding shall be recorded and communicated to the competent Framework Body where lifecycle action or another Framework Decision is required.

16.10. A surveillance finding shall not, by itself, alter Qualified Status.

Article 17: Lifecycle action and reinstatement support

17.1. Where evidence indicates that a qualified condition is no longer satisfied or is materially at risk, the Responsible Actor shall prepare a lifecycle-action evidence package for the competent Framework Body.

17.2. The evidence package shall identify:

1. the affected Status-Bearing Matter and Qualified Scope;

2. the failed or threatened condition;

3. the evidence basis;

4. the relevant finding, non-conformity, incident or change;

5. the affected dependencies;

6. the affected outputs or Trust Objects;

7. the immediate protective and corrective actions;

8. the proposed restriction, Suspension, Withdrawal, Revocation or other treatment;

9. the proposed Effective Date;

10. the Status Publication and notification requirements;

11. the treatment of Historical State;

12. the applicable Review Route.

17.3. A lifecycle-action evidence package shall distinguish between:

1. the Trust Service Provider;

2. each Trust Service;

3. each Source;

4. each mechanism or device;

5. each individual Trust Object or Trust Service Output.

17.4. A proposed lifecycle action shall remain limited to the affected matter and scope supported by the evidence.

17.5. Treatment of outputs created before the Effective Date of a lifecycle action shall be determined under the applicable Framework requirements and Historical State evidence.

17.6. An application for reinstatement shall include:

1. the corrected condition;

2. the corrective-action evidence;

3. independent Verification where required;

4. the reassessment result;

5. the restored dependency conditions;

6. the proposed reinstated scope;

7. the proposed Effective Date;

8. the required publication information.

17.7. Reinstatement of Qualified Trust Service Provider Status shall not, by itself, reinstate Qualified Trust Service Status.

17.8. Reinstatement of a Qualified Trust Service shall not, by itself, reinstate the Qualified Status of another Trust Service, Source, mechanism, device, Trust Object or Trust Service Output.

17.9. Corrective action, reassessment or submission of a reinstatement application shall not create reinstated Qualified Status before the applicable Framework Decision.

Article 18: Records and Historical State

18.1. Each Responsible Actor shall maintain the records required to reconstruct Assurance evaluation, Conformity Assessment and qualification within the applicable scope.

18.2. The records shall include, where applicable:

1. Implementation Plans;

2. requirement and evidence maps;

3. Assurance evaluation plans and records;

4. assessment requests and confirmed scopes;

5. competence and independence records;

6. assessment plans;

7. evidence and sampling records;

8. findings and non-conformities;

9. corrective-action and closure records;

10. Conformity Assessment Results;

11. qualification evidence packages;

12. Framework Decision references;

13. object-instance qualification records;

14. qualified-dependency records;

15. Status Publication handoff records;

16. surveillance and reassessment records;

17. material-change records;

18. lifecycle-action and reinstatement records;

19. Review and Remedy records.

18.3. Records shall preserve the identity, Version, time, scope, evidence source, responsible Actor, dependency and applicable Framework Instrument for each material action and conclusion.

18.4. Records shall be protected against unauthorised access, alteration, deletion and disclosure.

18.5. Access to records shall be limited according to assigned Decision Competence, assessment responsibility, Review Route, Remedy Route and applicable Confidentiality conditions.

18.6. Historical State shall remain reconstructable for the period required for Validation, supervision, Review, Remedy, Controlled Reliance and External Legal Effect where applicable.

18.7. Correction of a record shall preserve the earlier record, the correction basis, the responsible Actor and the Effective Date of the correction.

18.8. A later evaluation, assessment, decision or publication shall not erase or silently replace earlier evidence or Historical State.

18.9. A corrected or superseded record shall remain linked to its predecessor and successor.

Article 19: Reference standards and specifications

19.1. The reference standards applicable to the implementation of this Guideline are set out in Annex I.

19.2. A reference identified in Annex I shall apply only within the implementation function, subject and scope identified in that Annex.

19.3. Service-specific, object-specific, Source-specific, device-specific and technical-testing standards shall be identified through the applicable subject-specific Implementation Guideline, Profile and Technical Specification.

19.4. A later edition, amendment or replacement of a standard identified in Annex I shall not apply automatically.

19.5. A later edition, amendment or replacement shall undergo standards evaluation and Change Control before it is assigned Framework effect.

19.6. Conformity with a standard identified in Annex I shall constitute evidence only for the requirements and scope mapped to that standard.

19.7. Conformity with a standard shall not, by itself, create an Assurance outcome, positive Conformity Assessment Result, qualification decision, Qualified Status, recognition, Service Permission, Technical Exchange Permission or Controlled Reliance.

Annex I: Reference standards

Reference	Implementation function	Applicability and controlled treatment
ISO/IEC 17000:2020, Conformity assessment — Vocabulary and general principles	Common conformity-assessment concepts and functional relationships	Applicable as supporting terminology and principles where consistent with the Controlled Terms established by the Framework. Part II terminology shall prevail where the meanings differ.
ISO/IEC 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and services	Competence, impartiality, operation, review and certification requirements for Conformity Assessment Bodies	Mandatory where a Conformity Assessment Body makes a certification conclusion concerning a product, process or service.
ETSI EN 319 403-1 V2.3.1, 2020-06, Trust Service Provider Conformity Assessment — Part 1: Requirements for conformity assessment bodies assessing Trust Service Providers	Additional requirements for assessment and certification of Trust Service Providers and Trust Services	Mandatory for a Conformity Assessment Body assessing a Trust Service Provider or Trust Service for Decision-Based Qualification, together with ISO/IEC 17065:2012.
ISO/IEC 17067:2013, Conformity assessment — Fundamentals of product certification and guidelines for product certification schemes	Design and maintenance of continuing-certification arrangements	Mandatory where a conformity-assessment arrangement supporting continuing Decision-Based Qualification uses product, process or service certification. Scheme type 6 shall apply to Qualified Trust Service Provider and Qualified Trust Service assessment unless the applicable Qualified Profile establishes a stricter arrangement.
ISO/IEC 17011:2017, Conformity assessment — Requirements for accreditation bodies accrediting conformity assessment bodies	Accreditation-body competence, impartiality and consistent operation	Applicable where accreditation is used as evidence supporting recognition or continuing competence of a Conformity Assessment Body.
ISO/IEC 17025:2017, General requirements for the competence of testing and calibration laboratories	Testing, sampling and calibration performed by a laboratory	Mandatory for subcontracted or relied-upon laboratory activities where the applicable Profile requires accredited testing or calibration.
ISO/IEC 17021-1:2015, Conformity assessment — Requirements for bodies providing audit and certification of management systems — Part 1: Requirements	Audit and certification of management systems	Mandatory where a management-system audit is subcontracted or used as distinct conformity evidence.
ISO/IEC 17020:2026, Conformity assessment — Requirements for bodies performing inspection	Inspection activities used as conformity evidence	Mandatory where inspection is subcontracted or relied upon as a distinct assessment activity.
ISO 19011:2026, Guidelines for auditing management systems	Audit-programme management, audit planning, audit conduct and auditor competence	Applicable as supporting guidance where management-system audit methods form part of the assessment plan. It shall not replace ISO/IEC 17065, ETSI EN 319 403-1 or another mandatory conformity-assessment standard.

IDEHA-IG-SEC-CNF-001: Security and Confidentiality Implementation

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for security and Confidentiality under the Framework.

1.2. This Guideline shall apply to each Framework Body, Participating Actor, Trust Service Provider, Source Holder, Source Steward, Issuer, Relying Actor, Responsible Actor, Technical Exchange Route Operator, Intermediary, supporting Actor and technical operator responsible for implementing or operating a Controlled Matter, Controlled Environment, Trust Service, Source, Trust Object, Trust Service Output, mechanism, device, Authenticator, Endpoint, Technical Exchange Route, Register, Catalogue or Humanitarian Trust List component.

1.3. This Guideline shall govern, where applicable:

1. security governance, responsibility and Accountability;

2. security scope, inventory and dependency identification;

3. trust-boundary and Controlled Environment implementation;

4. security risk assessment and treatment;

5. information classification and handling;

6. Transport Confidentiality, Payload Confidentiality, storage confidentiality, processing confidentiality and disclosure control;

7. plaintext access and Intermediary exclusion;

8. access control and privileged functions;

9. Integrity, Authenticity and Accountability controls;

10. protected functions and Security-Sensitive Information;

11. secure acquisition, development, configuration and change;

12. vulnerability management;

13. security monitoring, logging and evidence;

14. Security Incident readiness and handoff;

15. security testing, exceptions and lifecycle evidence.

1.4. This Guideline shall not:

1. redefine the security architecture or structural relationships established by the Main Framework and Annex H;

2. establish a security category, Trust Service Category, Trust Object Category, Status category, qualification route or Controlled Effect;

3. assign recognition, Service Permission, Technical Exchange Permission, Status, Qualified Status, access, disclosure permission, Authorisation or Controlled Reliance;

4. replace a Framework Decision or a decision retained by a Responsible Actor within its assigned responsibility;

5. treat encryption, Authentication, successful testing, technical isolation or technical inaccessibility as Authorisation or disclosure permission;

6. prescribe exact algorithms, key sizes, protocol Versions, cipher suites, schemas, interfaces, configuration values, product settings or test vectors;

7. govern operational Security Incident response, containment, notification, Continuity, Degraded Operation, Recovery, reinstatement or incident closure.

1.5. Cryptographic policy, cryptographic mechanisms, key lifecycle, cryptographic agility and post-quantum transition shall be governed by IDEHA-IG-SEC-CRY-001.

1.6. Operational Security Incident response, Continuity, Degraded Operation, Recovery, reinstatement and closure shall be governed by IDEHA-IG-SEC-INC-001.

1.7. Compliance with this Guideline shall not, by itself, establish operational activation, Authorisation, disclosure permission, Qualified Status, External Legal Status, External Legal Effect or permission for Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the governed purpose and operational context;

2. the participating Actors and affected persons;

3. the Controlled Matters and interactions within scope;

4. the applicable risk context;

5. the required safeguards;

6. the applicable Review and Remedy arrangements.

2.2. The applicable Profile shall identify:

1. the security scope and Responsible Actors;

2. the Controlled Matters, Controlled Environments and trust boundaries;

3. the applicable information classes;

4. the Confidentiality, Integrity, Authenticity, Availability and Accountability requirements;

5. the applicable access and privileged-function requirements;

6. the protected functions and Security-Sensitive Information;

7. the required security controls and evidence;

8. the testing, Assurance and Conformity Assessment requirements;

9. the incident-readiness and handoff requirements;

10. the exception, change, Review and lifecycle conditions.

2.3. The applicable Technical Specification shall define the exact implementation and testing requirements, including:

1. algorithms and parameters;

2. technical formats and interfaces;

3. protocol options;

4. configuration values;

5. control settings;

6. test inputs and expected results;

7. technical conformance criteria.

2.4. A subject-specific Implementation Guideline shall establish only the additional security requirements necessary for its subject matter and shall not repeat the horizontal controls established by this Guideline.

2.5. A Profile, Technical Specification, test report, risk decision, exception record, monitoring record or security evidence artefact shall not alter a category, Decision Competence, Status or Controlled Effect established by the Main Framework.

Article 3: Security and Confidentiality Implementation Plan

3.1. A Responsible Actor shall maintain a Security and Confidentiality Implementation Plan for each implementation within its responsibility.

3.2. The Implementation Plan shall identify:

1. the governed purpose and implementation scope;

2. the applicable Federation Domain;

3. the Controlled Matters and Controlled Environments within scope;

4. each Responsible Actor, supporting Actor, technical operator and material dependency;

5. the organisational, physical, technical and Federation Boundaries;

6. the information classes and applicable Confidentiality requirements;

7. the security risks, treatment decisions and residual risks;

8. the access, Integrity, Authenticity, Availability and Accountability controls;

9. the protected functions and Security-Sensitive Information;

10. the monitoring, logging, vulnerability-management and evidence arrangements;

11. the Security Incident readiness and handoff arrangements;

12. the testing, Assurance and Conformity Assessment requirements;

13. the exception, Change Control, Review, Remedy, Retention and lifecycle arrangements.

3.3. The Implementation Plan shall distinguish:

1. governance responsibility from technical operation;

2. security-control operation from Decision Competence;

3. Transport Confidentiality from Payload Confidentiality;

4. storage confidentiality from processing confidentiality;

5. Confidentiality from Authorisation and disclosure permission;

6. Authentication from access permission;

7. Integrity from Authenticity;

8. service security from object-level protection;

9. security monitoring from Security Incident response;

10. technical Recovery from Status or permission reinstatement.

3.4. The Responsible Actor shall approve the Implementation Plan before operational activation within the affected scope.

3.5. Approval of the Implementation Plan shall not replace a Framework Decision, Service Permission, Technical Exchange Permission, Source-access decision, Authorisation Outcome or qualification decision required by the Framework.

3.6. The Responsible Actor shall update the Implementation Plan where a material change affects the scope, risk, Actors, dependencies, information classification, controls, evidence, monitoring, Assurance or incident readiness.

Section 2: Governance, scope and risk

Article 4: Security governance, responsibility and Accountability

4.1. Each Responsible Actor shall assign security responsibility for every Controlled Matter and security function within its scope.

4.2. The responsibility record shall identify:

1. the accountable organisational function;

2. the operational security function;

3. the Controlled Matter and function within scope;

4. the supporting Actors and technical operators;

5. the approval, escalation and Review routes;

6. the evidence and reporting obligations.

4.3. A Trust Service Provider shall retain responsibility for the security of each Trust Service within its Provider Scope and Service Scope.

4.4. A Source Holder and Source Steward shall retain their respective security responsibilities for the Source and Source Scope assigned by the applicable Source Profile.

4.5. A Technical Exchange Route Operator, Intermediary, supporting Actor or technical operator shall remain responsible for its assigned security functions without acquiring the Role, Status, responsibility or Decision Competence of another Actor.

4.6. Outsourcing, shared infrastructure or delegation of technical operation shall not remove the responsibility assigned to the Responsible Actor.

4.7. Security responsibilities shall remain identifiable during:

1. normal operation;

2. maintenance;

3. privileged or emergency access;

4. incident handoff;

5. transition;

6. cessation.

4.8. The Responsible Actor shall review the responsibility allocation following each material organisational, technical or dependency change.

Article 5: Controlled Matter inventory, trust boundaries and Controlled Environments

5.1. A Responsible Actor shall maintain an inventory of the Controlled Matters and material dependencies within its security scope.

5.2. The inventory shall identify, where applicable:

1. Actors, Roles and Mandates;

2. Trust Service Providers and Trust Services;

3. Sources and Source Scopes;

4. Trust Objects and Trust Service Outputs;

5. mechanisms, devices and Authenticators;

6. Endpoints, Technical Exchange Routes and Intermediaries;

7. Registers, Catalogues, Humanitarian Trust List components and publication channels;

8. information stores, processing environments and evidence repositories;

9. external services, supporting Actors and material dependencies;

10. applicable Status, Version and lifecycle information.

5.3. The Responsible Actor shall identify each organisational, physical, technical and Federation Boundary crossed by a Controlled Interaction or information flow.

5.4. A trust-boundary record shall identify:

1. the originating and receiving Actors;

2. the Controlled Matters crossing the boundary;

3. the applicable Authentication and Authorisation conditions;

4. the applicable Confidentiality, Integrity, Authenticity and evidence requirements;

5. the permitted processing and disclosure scope;

6. each Intermediary and technical operator;

7. the monitoring and incident-handoff arrangements.

5.5. The Responsible Actor shall identify each Controlled Environment required for:

1. a protected function;

2. a qualified dependency;

3. Restricted Information;

4. Protection-Sensitive Information;

5. Security-Sensitive Information;

6. an elevated Assurance condition.

5.6. The inventory, trust-boundary record and Controlled Environment record shall remain current and traceable to the applicable Profile and Version.

5.7. Inclusion in an inventory, architecture record or trust-boundary record shall not create recognition, access, Service Permission, Technical Exchange Permission or Authorisation.

Article 6: Security risk assessment and treatment

6.1. A Responsible Actor shall assess security risks before operational activation and throughout the implementation lifecycle.

6.2. The risk assessment shall identify, where applicable:

1. the Controlled Matters, Actors, persons and operations exposed to harm;

2. threats, vulnerabilities and adverse conditions;

3. Confidentiality, Integrity, Authenticity, Availability, Accountability and protection impacts;

4. risks arising from aggregation, inference, correlation, linkability and onward transfer;

5. risks arising from shared infrastructure, outsourcing and cross-domain dependencies;

6. risks affecting Trust Services, Sources, Trust Objects, mechanisms, devices, Endpoints and Technical Exchange Routes;

7. risks affecting Assurance, Conformity Assessment and Qualified Status;

8. risks affecting Correction, Review, Remedy and Historical State;

9. likelihood, consequence, uncertainty and the evidence basis.

6.3. A risk-treatment record shall identify:

1. the selected controls;

2. the Responsible Actor for each control;

3. the implementation and verification time;

4. the expected residual risk;

5. the monitoring and reassessment requirements;

6. the escalation and incident-handoff conditions.

6.4. A material risk affecting a mandatory dependency shall be addressed before that dependency supports a positive Assurance, Verification, Validation, qualification or Controlled Reliance outcome.

6.5. Residual risk shall be accepted only by the Actor or Framework Body holding the applicable responsibility or Decision Competence.

6.6. A residual-risk decision shall identify:

1. the affected scope;

2. the evidence basis;

3. the controls applied;

4. the duration and review date;

5. the limitations;

6. the continuing obligations.

6.7. Risk acceptance shall not create Authorisation, disclosure permission, Qualified Status or permission for Controlled Reliance.

Article 7: Shared infrastructure, supplier and dependency security

7.1. A Responsible Actor shall identify and assess each material security dependency before relying on shared infrastructure, an outsourced function, a supplier, a supporting Actor or another Federation Domain.

7.2. A dependency record shall identify:

1. the dependent and supporting Controlled Matters;

2. the responsible and supporting Actors;

3. the assigned security function and scope;

4. the service, information and trust boundaries;

5. the applicable Profile, Technical Specification and Version;

6. the evidence, monitoring and notification obligations;

7. the restriction, transition and termination conditions.

7.3. A contractual, operational or Federation arrangement shall allocate:

1. access and privileged-function responsibilities;

2. Confidentiality, Integrity, Authenticity and Availability responsibilities;

3. logging, monitoring and evidence responsibilities;

4. vulnerability, update and remediation responsibilities;

5. Security Incident notification and cooperation responsibilities;

6. return, transfer, Retention and Deletion responsibilities;

7. Assurance and Conformity Assessment access rights;

8. transition and exit responsibilities.

7.4. A supporting Actor shall provide the evidence required to demonstrate performance of its assigned security functions.

7.5. Shared infrastructure shall not merge the Status, Service Scope, Qualified Scope, security responsibility or lifecycle of the Controlled Matters using that infrastructure.

7.6. A security weakness or Security Incident affecting shared infrastructure shall affect a dependent Controlled Matter only according to the identified dependency, relevant time, evidence and affected scope.

7.7. Termination of a dependency shall include:

1. secure transition;

2. access removal;

3. information return or transfer;

4. Retention and Deletion treatment;

5. evidence preservation;

6. verification of completed exit actions.

Section 3: Information protection and access

Article 8: Information classification and handling

8.1. A Responsible Actor shall classify information according to the harm capable of arising from unauthorised access, use, combination, alteration, loss, disclosure or Retention.

8.2. The classification process shall identify:

1. information authorised for public disclosure;

2. information subject to restricted operational or supervisory access;

3. Restricted Information;

4. Protection-Sensitive Information;

5. Security-Sensitive Information;

6. each narrower class established by the applicable Profile.

8.3. A classification record shall identify:

1. the information class;

2. the responsible Actor;

3. the authorised purposes and recipients;

4. the applicable access and disclosure controls;

5. the storage, transmission and processing controls;

6. the logging and monitoring controls;

7. the Retention, archival and Deletion conditions;

8. the review and reclassification triggers.

8.4. Information that is not individually sensitive shall be classified according to the additional risk created by aggregation, combination, inference, correlation or linkability.

8.5. A Humanitarian Trust List Entry, Register Entry, Catalogue Entry, Status Response, error message, log or evidence record shall contain only information authorised for its assigned access or publication class.

8.6. Information shall retain its applicable handling requirements when copied, transformed, cached, backed up, archived or transferred.

8.7. Reclassification shall preserve:

1. the earlier classification;

2. the reason and evidence basis;

3. the responsible Actor;

4. the Effective Date;

5. the effect on access, disclosure, Retention and existing copies.

Article 9: Confidentiality control implementation

9.1. A Responsible Actor shall implement Confidentiality controls throughout:

1. collection and creation;

2. issuance;

3. transmission and receipt;

4. processing;

5. storage and backup;

6. disclosure;

7. Retention and archival;

8. Deletion and destruction.

9.2. The implementation shall distinguish:

1. Transport Confidentiality;

2. Payload Confidentiality;

3. storage confidentiality;

4. processing confidentiality;

5. disclosure control.

9.3. The applicable Profile shall identify the Confidentiality layer required for each information class, interaction, trust boundary, processing activity and lifecycle state.

9.4. A Confidentiality-control record shall identify:

1. the protected information and scope;

2. the authorised Actors and purposes;

3. the protection and termination points;

4. the mechanism, dependency and responsible Actor;

5. the Validation, monitoring and evidence requirements;

6. the failure, restriction and incident-handoff conditions.

9.5. Confidentiality controls shall preserve data minimisation and shall not require disclosure of additional information merely to operate the control.

9.6. Confidentiality protection shall not replace:

1. Integrity;

2. Authenticity;

3. Authentication;

4. Authorisation;

5. Status;

6. Validation;

7. Controlled Reliance requirements.

9.7. Encryption, isolation or technical inaccessibility shall not, by itself, authorise collection, processing, exchange, disclosure, onward transfer or Retention.

9.8. Each failure of a required Confidentiality control shall receive the restriction and incident-handoff treatment assigned by the applicable Profile.

Article 10: Payload Confidentiality and plaintext access

10.1. Where Payload Confidentiality is required, the originating Actor shall protect the payload before it enters the Technical Exchange Route.

10.2. Plaintext access shall be limited to:

1. the authorised originating Actor;

2. the authorised receiving Actor;

3. each additional processing Actor expressly identified by the applicable Profile and Authorisation Outcome.

10.3. A Technical Exchange Route Operator, Intermediary, gateway operator, relay operator or Federated Data Exchange Service Provider shall not access plaintext payload content solely because that Actor carries, routes, stores, monitors or evidences the exchange.

10.4. Decryption material shall not be made available to an Intermediary or unrelated component unless:

1. the applicable Profile assigns that Actor a processing function;

2. the applicable Authorisation Outcome covers the processing;

3. the required safeguards and evidence apply.

10.5. The payload-protection record shall identify:

1. the originating and receiving Actors;

2. the protected payload and associated Metadata;

3. the encryption and decryption responsibilities;

4. the authorised processing points;

5. the applicable key or credential dependency;

6. the Integrity and Authenticity controls;

7. the failure and incident-handoff conditions.

10.6. Discovery Metadata, routing Metadata and Exchange Evidence shall be limited to the information necessary and authorised for routing, security, Accountability and error handling.

10.7. Transport Confidentiality shall not replace Payload Confidentiality where Payload Confidentiality is required.

10.8. Payload Confidentiality shall not replace an Electronic Signature, Electronic Seal, Electronic Timestamp or other object-level protection required for independent Verification or Validation.

10.9. Payload signing, sealing and encryption for the Federated Data Exchange Service shall be implemented in accordance with IDEHA-IG-SVC-FDX-001 and the applicable Profile and Technical Specification.

Article 11: Access control and privileged functions

11.1. A Responsible Actor shall limit access to a Controlled Matter, Trust Service, Source, Endpoint, mechanism, device, administrative function or evidence repository to authorised Actors and the minimum scope necessary for the assigned purpose.

11.2. The access-control arrangement shall address, where applicable:

1. Identification and Authentication;

2. Authorisation;

3. least privilege;

4. separation of duties;

5. privileged access;

6. emergency access;

7. periodic access Review;

8. restriction and removal of access;

9. auditable access evidence.

11.3. An access record shall identify:

1. the Actor and applicable Role;

2. the purpose;

3. the Controlled Matter;

4. the permitted action and scope;

5. the Effective Date;

6. the expiry or review date;

7. the approval basis;

8. the evidence reference.

11.4. Privileged access shall be:

1. separately authorised;

2. limited to the assigned function;

3. time-limited where practicable;

4. monitored;

5. periodically reviewed.

11.5. Emergency access shall be limited to the emergency scope, recorded, monitored, reviewed and terminated when the emergency condition ends.

11.6. A successful Authentication Outcome shall not, by itself, create Authorisation, disclosure permission or access to another Controlled Matter.

11.7. Administrative, maintenance or support access shall not assign the Role, Status or Decision Competence of the Actor responsible for the controlled function.

11.8. Access shall be removed without undue delay where the applicable Role, Mandate, employment, contract, purpose, dependency or Authorisation condition ends or changes.

11.9. Access Reviews shall identify and correct excessive, conflicting, dormant, unauthorised or no longer necessary access.

Section 4: Integrity, protected functions and operational security

Article 12: Integrity, Authenticity and Accountability

12.1. A Responsible Actor shall protect a Controlled Matter against unauthorised alteration, substitution, deletion, corruption, replay and incorrect lifecycle transition.

12.2. The applicable Profile shall identify the Integrity, Authenticity and Accountability controls required for each:

1. Trust Object and Trust Service Output;

2. request, response and message;

3. record and evidence artefact;

4. decision and Status publication;

5. policy and configuration package;

6. lifecycle event.

12.3. A statement-bearing Trust Object or Trust Service Output crossing an organisational or Federation Boundary shall receive the object-level protection required by the applicable Framework Instruments and Profile.

12.4. Transport protection shall not replace an Electronic Signature, Electronic Seal, Electronic Timestamp, Certificate or other object-level evidence required for independent Verification or Validation.

12.5. A material action, access, disclosure, change, decision and lifecycle transition shall be attributable to the responsible Actor, service, mechanism, device or system where Accountability requires that attribution.

12.6. A Controlled Interaction shall include replay, duplication, sequencing and correlation controls where the applicable Profile identifies those risks.

12.7. Integrity, Authenticity and Accountability evidence shall be protected against unauthorised alteration and retained according to the applicable Profile and Retention requirements.

12.8. Successful Integrity or Authenticity Verification shall not, by itself, establish correctness, lawfulness, Authorisation, acceptance or Controlled Reliance.

Article 13: Protected functions and Security-Sensitive Information

13.1. A Responsible Actor shall identify each protected function and item of Security-Sensitive Information within its scope.

13.2. Protected functions and Security-Sensitive Information shall include, where applicable:

1. Digital Signature Creation Data and protected creation functions;

2. Digital Signature Validation Data and trust anchors;

3. encryption and decryption keys;

4. Authentication secrets and recovery material;

5. privileged administrative credentials;

6. creation mechanisms and devices;

7. security policies and configurations;

8. vulnerability and Security Incident information;

9. certificate, Status and Validation dependencies;

10. monitoring, detection and response configurations.

13.3. The protected-function record shall identify:

1. the responsible Actor;

2. the authorised functions and users;

3. the applicable Controlled Environment;

4. the access and separation-of-duties controls;

5. the monitoring and evidence requirements;

6. the restriction, compromise and incident-handoff conditions.

13.4. Access to a protected function or item of Security-Sensitive Information shall be separately authorised, logged, monitored and reviewed.

13.5. Digital Signature Creation Data and Digital Signature Creation Devices shall be governed by IDEHA-IG-OBJ-DSG-001.

13.6. Cryptographic mechanisms, key lifecycle, trust-anchor controls, cryptographic agility and post-quantum transition shall be governed by IDEHA-IG-SEC-CRY-001.

13.7. A remote or shared protected-function arrangement shall preserve the control, activation, separation and evidence requirements assigned by the applicable Profile.

13.8. Compromise or suspected compromise of a protected function, Authenticator, mechanism, device, credential or item of Security-Sensitive Information shall trigger the handoff required by Article 17.

Article 14: Secure design, acquisition, development, configuration and change

14.1. A Responsible Actor shall integrate security and Confidentiality requirements into:

1. design;

2. acquisition;

3. development;

4. configuration;

5. deployment;

6. operation and maintenance;

7. retirement.

14.2. Security design shall identify:

1. the governed purpose and security assumptions;

2. the trust boundaries and Controlled Environments;

3. the threat and risk model;

4. the information flows and processing points;

5. the required access, Confidentiality, Integrity, Authenticity and evidence controls;

6. the failure, exception and incident-handoff behaviour;

7. the testing and acceptance criteria.

14.3. Acquisition, development and configuration controls shall address, where applicable:

1. separation of development, testing and operational environments;

2. source, build and configuration Integrity;

3. supplier, dependency and component review;

4. secure default configuration;

5. removal or restriction of unnecessary functions and access;

6. secret and credential protection;

7. code, configuration and change Review;

8. security testing before operational use.

14.4. A material security change shall undergo the assessment, testing, approval and evidence requirements assigned by the applicable Profile before operational use.

14.5. Emergency change shall remain subject to:

1. recorded scope and approval;

2. compensating controls;

3. proportionate testing;

4. post-implementation Review;

5. rollback arrangements.

14.6. Technical availability or successful deployment shall not, by itself, establish operational activation, Service Permission, Technical Exchange Permission or permission for Controlled Reliance.

Article 15: Vulnerability management and remediation

15.1. A Responsible Actor shall maintain a vulnerability-management process for each system, Trust Service, Source, mechanism, device, Endpoint, Technical Exchange Route and material dependency within its scope.

15.2. The process shall include:

1. vulnerability identification and intake;

2. validation and affected-scope determination;

3. risk assessment and prioritisation;

4. remediation, mitigation or restriction;

5. testing and Verification;

6. notification and controlled disclosure where required;

7. evidence and closure.

15.3. A vulnerability assessment shall consider the possible effect on:

1. Trust Service Provider Status, Trust Service Status and Service Permission;

2. Trust Object Status and Validation;

3. Source Status and Source Verification;

4. mechanisms, devices and Authenticators;

5. Technical Exchange Permission and Endpoint operation;

6. Assurance, Conformity Assessment and Qualified Status;

7. dependent Actors and Federation Domains.

15.4. A Responsible Actor shall apply an urgent restriction or compensating control where continued operation creates an unacceptable risk.

15.5. Vulnerability information shall be restricted where premature or unnecessary disclosure would increase the risk.

15.6. Closure shall require evidence that the assigned remediation or mitigation is effective within the affected scope.

15.7. A vulnerability that indicates actual or suspected compromise shall be handed to the process governed by IDEHA-IG-SEC-INC-001 without undue delay.

15.8. Vulnerability closure shall not, by itself, reinstate a Status, permission or Qualified Status affected by a separate Framework Decision.

Article 16: Security monitoring, logging and evidence

16.1. A Responsible Actor shall monitor the security state of the Controlled Matters and dependencies within its scope.

16.2. Monitoring shall address, where applicable:

1. access and privileged activity;

2. Authentication and Authorisation events;

3. configuration and policy changes;

4. Trust Service, Source, mechanism, device, Endpoint and Technical Exchange Route state;

5. Confidentiality, Integrity and Authenticity control operation;

6. vulnerability and remediation state;

7. unusual, failed, repeated or unauthorised activity;

8. dependency, Status and qualified-condition changes.

16.3. Logging shall be limited to information necessary and authorised for security, Accountability, evidence and error handling.

16.4. Logs and monitoring records shall not contain plaintext payload content, Digital Signature Creation Data, Authentication secrets or other Restricted Information beyond what is necessary and authorised for the assigned purpose.

16.5. Security logs and evidence shall preserve:

1. trusted time and event sequence;

2. Actor, service, mechanism, device or system attribution;

3. the event and affected scope;

4. Integrity and Authenticity;

5. access controls;

6. Version and configuration context;

7. Retention and Historical State.

16.6. The applicable Profile shall identify the logs or evidence sets requiring an Electronic Seal, Electronic Timestamp or periodic evidence aggregation.

16.7. Monitoring and evidence shall support detection, assessment, Assurance, Conformity Assessment, Review, Remedy and Historical Validation.

16.8. A monitoring alert shall not, by itself, establish a Security Incident, Status change, non-conformity, fault or adverse finding against an Actor or person.

Article 17: Security Incident readiness and handoff

17.1. A Responsible Actor shall maintain readiness to detect, initially assess and hand off a suspected Security Incident to the process governed by IDEHA-IG-SEC-INC-001.

17.2. Readiness arrangements shall identify:

1. detection sources and monitoring responsibilities;

2. initial assessment and triage responsibilities;

3. incident-classification and severity inputs;

4. escalation, notification and contact routes;

5. evidence-preservation requirements;

6. affected-Actor and Federation Domain coordination routes;

7. Protection-Sensitive Information and Security-Sensitive Information handling;

8. the transition to containment, Continuity, Degraded Operation and Recovery.

17.3. A suspected-incident record shall identify:

1. the known affected scope;

2. the detection and occurrence times where known;

3. the available evidence;

4. the reporting source;

5. the initial protective controls;

6. the responsible handoff function.

17.4. A Responsible Actor shall preserve evidence before taking an action capable of destroying or materially altering that evidence, unless immediate action is necessary to prevent serious harm.

17.5. An incident-readiness exercise shall test:

1. communication;

2. escalation;

3. evidence preservation;

4. cross-Actor handoff;

5. Federation Domain coordination.

17.6. An incident-readiness exercise shall not require unauthorised access to live Protected-Person data.

17.7. Detection or notification of a suspected Security Incident shall not, by itself, suspend or withdraw Trust Service Provider Status, Trust Service Status, Source Status, Trust Object Status, Qualified Status or Technical Exchange Permission.

17.8. Operational containment, Status evaluation, notification, Continuity, Degraded Operation, Recovery, reinstatement and closure shall be governed by IDEHA-IG-SEC-INC-001 and the applicable Framework Decision.

Section 5: Assurance, exceptions and lifecycle

Article 18: Security testing, Assurance and Conformity Assessment

18.1. A Responsible Actor shall test security and Confidentiality controls:

1. before operational activation;

2. after each material change affecting the assessed scope;

3. at the interval required by the applicable Profile;

4. following a material vulnerability or Security Incident where reassessment is required.

18.2. Testing shall address, where applicable:

1. access and privileged-function controls;

2. Authentication and Authorisation enforcement;

3. Transport Confidentiality and Payload Confidentiality;

4. storage and processing confidentiality;

5. Integrity, Authenticity and object-level protection;

6. protected functions and Security-Sensitive Information;

7. configuration, supplier, dependency and change controls;

8. monitoring, logging and evidence;

9. vulnerability handling and incident handoff.

18.3. The test plan shall identify:

1. the tested scope;

2. the applicable Profile and Technical Specification Versions;

3. the test environment;

4. the methods and inputs;

5. the expected results and acceptance criteria;

6. the Responsible Actors;

7. the required evidence.

18.4. Testing in an operational environment shall protect persons, live information, Trust Services, Sources, dependencies and ongoing Controlled Interactions from unauthorised effect.

18.5. A test result shall identify each limitation, deviation, unresolved finding and residual risk.

18.6. A material unresolved security non-conformity shall prevent positive Conformity Assessment or operational use within the affected scope until the applicable corrective, restriction or acceptance condition is satisfied.

18.7. Security Assurance and Conformity Assessment shall be implemented in accordance with IDEHA-IG-ASR-QLF-001 and the applicable Assurance or Qualified Profile.

18.8. Successful testing or positive Conformity Assessment shall not, by itself, assign Qualified Status, Service Permission, Technical Exchange Permission or Controlled Reliance.

Article 19: Security exceptions and temporary controls

19.1. A Responsible Actor shall use a security exception only where:

1. the applicable requirement cannot be satisfied within the required time;

2. the unresolved condition does not create an unacceptable risk;

3. a time-limited remediation or transition plan is available.

19.2. A security-exception record shall identify:

1. the affected requirement and Controlled Matter;

2. the reason and evidence basis;

3. the affected scope and persons;

4. the risk and potential Controlled Effect;

5. the compensating controls;

6. the approving Actor;

7. the Effective Date and expiry date;

8. the monitoring and Review conditions;

9. the remediation or transition plan;

10. the incident-handoff condition.

19.3. A security exception shall be approved only by the Actor or Framework Body holding the applicable responsibility or Decision Competence.

19.4. An exception shall remain limited to the identified:

1. scope;

2. duration;

3. Version;

4. configuration.

19.5. An exception shall not:

1. waive a Protected-Person Safeguard;

2. create access or disclosure permission;

3. extend Qualified Status;

4. bypass a mandatory Framework Decision;

5. permit continued operation where the residual risk is unacceptable.

19.6. The Responsible Actor shall withdraw the exception where the approval conditions cease to be satisfied or the residual risk becomes unacceptable.

19.7. Expiry, withdrawal or remediation of an exception shall be recorded and verified.

Article 20: Records, Review, Remedy and lifecycle

20.1. A Responsible Actor shall retain the security-governance, inventory, boundary, risk, classification, access, control, testing, vulnerability, monitoring, exception and readiness records required by the applicable Profile and Retention requirements.

20.2. Records shall preserve:

1. Integrity;

2. Authenticity;

3. Provenance;

4. Version;

5. time;

6. the responsible Actor;

7. access controls;

8. Historical State.

20.3. Records shall remain available to the authorised Framework Body, Conformity Assessment Body, Review function or Remedy function within the applicable scope.

20.4. A security record shall not disclose Protection-Sensitive Information or Security-Sensitive Information beyond the authorised purpose and requester scope.

20.5. A material security change shall follow the applicable Change Control, Versioning, transition and Historical State requirements.

20.6. Restriction, Suspension, Withdrawal or cessation of a Trust Service, Source, mechanism, device, Endpoint, Technical Exchange Route or dependency shall not remove continuing Confidentiality, evidence, Retention, Review, Remedy or historical-reconstruction obligations.

20.7. An affected Actor or person shall have access to the applicable Correction, Complaint, Review and Remedy Routes.

20.8. Review shall distinguish between:

1. the security-risk or control evaluation;

2. the technical test result;

3. the Conformity Assessment Result;

4. a Framework Decision or Status action;

5. the Relying Actor’s separate acceptance and Controlled Reliance decision.

20.9. Correction of a security record shall preserve the earlier record and identify the correcting Actor, reason, evidence, Effective Date and effect.

20.10. A Remedy shall apply only within the competence and affected scope identified by the applicable Review outcome and shall not create recognition, Status, permission or Qualified Status by implication.

Article 21: Reference standards and specifications

21.1. The reference standards applicable to the implementation of this Guideline are set out in Annex I.

21.2. A reference identified in Annex I shall apply only within the implementation function, subject and scope identified in that Annex.

21.3. The applicable Profile shall identify the controls selected from a referenced standard and their application to the relevant Controlled Matters, Controlled Environments and risks.

21.4. Exact algorithms, parameter sets, cryptographic mechanisms, protocol configurations, test conditions and product settings shall be established through the applicable Profile and Technical Specification.

21.5. Standards governed principally by the following Framework Instruments shall apply through those instruments and shall not be repeated in Annex I:

1. cryptographic mechanisms, key management, cryptographic modules and post-quantum transition under IDEHA-IG-SEC-CRY-001;

2. Security Incident response, Continuity and Recovery under IDEHA-IG-SEC-INC-001;

3. Trust Service Provider common controls under IDEHA-IG-SVC-TSP-001;

4. subject-specific Trust Service, Trust Object, Source and Technical Exchange requirements.

21.6. A later edition, amendment or replacement of a standard identified in Annex I shall not apply automatically.

21.7. A later edition, amendment or replacement shall undergo standards evaluation and Change Control before it is assigned Framework effect.

21.8. Conformity with a referenced standard shall constitute evidence only for the requirements and scope mapped to that reference.

21.9. Conformity with a referenced standard shall not, by itself, establish operational activation, Service Permission, Technical Exchange Permission, Authorisation, Qualified Status or Controlled Reliance.

Annex I: Reference standards

Reference	Implementation function	Applicability and controlled treatment
ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, including ISO/IEC 27001:2022/Amd 1:2024	Information security management system	Applicable to establishment, implementation, maintenance and continual improvement of security governance. Certification shall be required only where the applicable Profile or qualification condition expressly requires it.
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls	Information security control selection and implementation	Applicable as the principal horizontal control reference. The applicable Profile shall identify the controls selected, excluded or supplemented for the relevant scope.
ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks	Security risk assessment and treatment	Applicable to the risk-assessment, treatment, monitoring and reassessment processes governed by Article 6.
ISO/IEC 27701:2025, Information security, cybersecurity and privacy protection — Privacy information management systems — Requirements and guidance	Privacy management for personal data	Applicable where the implementation processes personal data or maintains privacy-management responsibilities. It shall not create an access, disclosure or processing basis.
ISO/IEC 29100:2024, Information technology — Security techniques — Privacy framework	Privacy roles, principles and safeguarding considerations	Applicable as a supporting reference for classification, confidentiality, data minimisation, linkability and privacy-risk treatment. Part II terminology shall prevail where meanings differ.
ISO/IEC 27036-2:2022, Cybersecurity — Supplier relationships — Part 2: Requirements	Supplier and acquirer security requirements	Applicable to material supplier, outsourcing and supporting-Actor relationships governed by Article 7.
ISO/IEC 27036-3:2023, Cybersecurity — Supplier relationships — Part 3: Guidelines for hardware, software, and services supply chain security	Supply-chain security	Applicable to acquisition, development, component, dependency and supply-chain controls governed by Articles 7 and 14.
ISO/IEC 27040:2024, Information technology — Security techniques — Storage security	Storage confidentiality, Integrity and lifecycle protection	Applicable where information, evidence, backups or cryptographic dependencies are stored in ICT storage environments.
ISO/IEC 27034-1:2011, Information technology — Security techniques — Application security — Part 1: Overview and concepts, including ISO/IEC 27034-1:2011/Cor 1:2014	Application-security governance and secure development	Applicable to application acquisition, development, operation and retirement under Article 14. Exact technical controls shall remain Profile and Technical Specification matters.
ISO/IEC 27017:2015, Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services	Cloud-service security controls	Conditionally applicable where a cloud service forms part of the implementation. A successor edition shall not apply until published, assessed and recognised through the standards-management route.
ISO/IEC 27018:2025, Information security, cybersecurity and privacy protection — Guidelines for protection of personally identifiable information in public clouds acting as PII processors	Protection of personal data in public-cloud processing	Conditionally applicable where a public-cloud provider processes personal data on behalf of a Responsible Actor. It shall be applied together with the applicable Profile, Authorisation and Confidentiality requirements.

IDEHA-IG-SEC-CRY-001: Cryptographic Controls and Cryptographic Agility Implementation

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for cryptographic controls and cryptographic agility under the Framework.

1.2. This Guideline shall apply to each Responsible Actor, Framework Body, Trust Service Provider, Source Holder, Source Steward, Issuer, Technical Exchange Route Operator, Intermediary, supporting Actor and technical operator responsible for implementing, operating, assessing or relying upon cryptographic protection.

1.3. This Guideline shall govern, where applicable:

1. cryptographic governance and responsibility;

2. cryptographic inventories and dependency records;

3. protection-lifetime and cryptographic-risk assessment;

4. selection and controlled use of Recognised Standards and cryptographic mechanisms;

5. algorithm and parameter identification;

6. random-bit generation and entropy management;

7. key, secret and cryptographic-material lifecycle management;

8. cryptographic modules and protected execution environments;

9. trust anchors and cryptographic Validation dependencies;

10. cryptographic agility and transition readiness;

11. algorithm restriction, deprecation, replacement and emergency transition;

12. post-quantum migration;

13. hybrid and composite cryptographic arrangements;

14. cryptographic compromise handoff;

15. testing, conformity evidence and Historical State.

1.4. This Guideline shall not:

1. redefine Digital Signature Creation Data, Digital Signature Validation Data, Digital Signature Creation Mechanisms or Digital Signature Creation Devices;

2. establish the conditions for an Electronic Signature, Electronic Seal, Electronic Timestamp, Certificate or Electronic Attestation;

3. establish a Trust Service Category, Trust Object Category, Status category, qualification route or Controlled Effect;

4. assign recognition, Service Permission, Technical Exchange Permission, Authorisation, Status or Qualified Status;

5. prescribe exact algorithms, parameter sets, key lengths, encodings, protocol bindings, certificate extensions, signature formats, product configurations or test vectors;

6. replace the security architecture established by the Main Framework and Annex H;

7. replace operational Security Incident response, containment, notification, Continuity, Recovery, reinstatement or closure;

8. treat the availability or use of a cryptographic mechanism as proof of Authorisation, lawfulness, correctness, acceptance or Controlled Reliance.

1.5. Digital Signature Creation Data, Digital Signature Creation Mechanisms and Digital Signature Creation Devices shall be implemented in accordance with IDEHA-IG-OBJ-DSG-001.

1.6. Horizontal security and Confidentiality controls shall be implemented in accordance with IDEHA-IG-SEC-CNF-001.

1.7. Operational response to cryptographic compromise shall be governed by IDEHA-IG-SEC-INC-001.

1.8. Assurance, Conformity Assessment and qualification evidence shall be governed by IDEHA-IG-ASR-QLF-001.

1.9. Compliance with this Guideline shall not, by itself, establish cryptographic suitability for an unidentified purpose, Qualified Status, operational activation, External Legal Status, External Legal Effect or permission for Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the governed purpose and operational context;

2. the participating Actors and Federation Domains;

3. the Controlled Matters and interactions requiring cryptographic protection;

4. the information and evidence protection periods;

5. the consequences of cryptographic failure;

6. the applicable safeguards, Review Routes and Remedy Routes.

2.2. The applicable Profile shall identify:

1. the cryptographic functions required within its scope;

2. the permitted mechanism and algorithm categories;

3. the required security strength;

4. the applicable protection lifetime;

5. the permitted key and secret lifecycle models;

6. the required module, mechanism or device assurance;

7. the permitted backup, Recovery, escrow and replacement arrangements;

8. the applicable agility and transition requirements;

9. the post-quantum and hybrid requirements, where applicable;

10. the required testing, evidence and reassessment conditions.

2.3. The applicable Technical Specification shall define:

1. exact algorithms and parameter sets;

2. key and output lengths;

3. algorithm and parameter identifiers;

4. key, signature, ciphertext and certificate representations;

5. cryptographic container and protocol bindings;

6. algorithm-negotiation behaviour;

7. key-derivation, key-agreement and key-encapsulation constructions;

8. hybrid and composite constructions;

9. module and interface requirements;

10. test vectors and conformance criteria;

11. migration and interoperability behaviour.

2.4. A deployment instruction shall define environment-specific:

1. cryptographic module configuration;

2. key and trust-anchor locations;

3. access and administration assignments;

4. operational rotation schedules;

5. monitoring settings;

6. backup and Recovery procedures;

7. emergency transition procedures.

2.5. A subject-specific Implementation Guideline shall identify only the additional cryptographic requirements required for its subject matter and shall not repeat the horizontal controls established by this Guideline.

2.6. A Scheme, Profile, Technical Specification, test result or deployment instruction shall not create a category, Status, permission, qualification route or Controlled Effect not established by the Main Framework.

Article 3: Cryptographic Implementation Plan

3.1. A Responsible Actor shall maintain an approved Cryptographic Implementation Plan for each implementation within its responsibility.

3.2. The Implementation Plan shall identify:

1. the implementation and cryptographic scope;

2. the Responsible Actors and supporting Actors;

3. the applicable Scheme, Profile and Technical Specification Versions;

4. the cryptographic functions and protected information;

5. the protection lifetime and required security strength;

6. the cryptographic inventory;

7. the permitted cryptographic mechanisms;

8. the key, secret and cryptographic-material lifecycle arrangements;

9. the cryptographic modules, mechanisms, devices and Controlled Environments;

10. the trust anchors and Validation dependencies;

11. the cryptographic agility arrangements;

12. the post-quantum migration arrangements;

13. the permitted hybrid or composite arrangements;

14. the monitoring, testing and evidence arrangements;

15. the compromise, transition and incident-handoff arrangements;

16. the Retention and Historical State requirements.

3.3. The Implementation Plan shall distinguish:

1. cryptographic policy from technical implementation;

2. a key or secret from the mechanism, device or module using it;

3. cryptographic protection from Authorisation;

4. encryption from disclosure permission;

5. Integrity from Authenticity;

6. key establishment from entity Authentication;

7. algorithm support from permission to use that algorithm;

8. technical Recovery from reinstatement of Status or permission;

9. current algorithm acceptability from historical Validation acceptability.

3.4. The Responsible Actor shall approve the Implementation Plan before operational activation within the affected scope.

3.5. The Responsible Actor shall update the Implementation Plan following a material change affecting the cryptographic scope, protection lifetime, algorithm, parameter, key, module, device, trust anchor, protocol, dependency, transition plan or post-quantum risk.

3.6. Approval of the Implementation Plan shall not create Service Permission, Technical Exchange Permission, Qualified Status or permission for Controlled Reliance.

Section 2: Cryptographic inventory and mechanism selection

Article 4: Cryptographic inventory

4.1. A Responsible Actor shall maintain a cryptographic inventory covering each cryptographic asset, use and dependency within its scope.

4.2. The cryptographic inventory shall identify, where applicable:

1. the Controlled Matter protected;

2. the cryptographic function;

3. the algorithm and parameter identifier;

4. the key, secret or cryptographic-material category;

5. the responsible and operating Actors;

6. the cryptographic module, mechanism, device or software component;

7. the applicable certificate, trust anchor or Validation dependency;

8. the applicable protocol, format and Technical Specification Version;

9. the information-protection lifetime;

10. the key or secret validity and use period;

11. the implementation and operational locations;

12. each supporting Actor and external dependency;

13. the current use classification;

14. the replacement and migration route;

15. the evidence and monitoring references.

4.3. The inventory shall include cryptographic use that is:

1. directly implemented;

2. embedded within a product or service;

3. provided by a supporting Actor;

4. inherited through a protocol, library, platform, module or device;

5. used for archived or historically retained information;

6. inactive but capable of reactivation.

4.4. The Responsible Actor shall identify each cryptographic dependency not under its direct control and the Actor responsible for its migration, replacement or withdrawal.

4.5. An unrecorded cryptographic mechanism shall not be used for a controlled production function unless an urgent exception has been approved under the applicable security-exception process.

4.6. The inventory shall be updated following:

1. activation of a new cryptographic function;

2. replacement or rotation;

3. module, mechanism, device or software change;

4. algorithm or parameter transition;

5. certificate or trust-anchor change;

6. identification of an unknown or inherited dependency;

7. compromise, restriction or deprecation.

4.7. Inclusion in the inventory shall not establish recognition, approval, suitability, Status or permission to use the recorded mechanism.

Article 5: Protection lifetime and required security strength

5.1. Before selecting a cryptographic mechanism, the Responsible Actor shall determine the period during which the protected matter requires Confidentiality, Integrity, Authenticity, Accountability or evidential reliability.

5.2. The protection-lifetime assessment shall consider:

1. the information sensitivity and classification;

2. the expected Retention period;

3. the period of intended Controlled Reliance;

4. the expected lifecycle of the relevant system, mechanism or device;

5. the time required to replace the implementation;

6. the time required to migrate retained information and evidence;

7. the expected cryptanalytic and technological threat horizon;

8. the consequence of retrospective decryption, forgery or trust-anchor compromise;

9. the need for Historical Validation.

5.3. The required security strength shall be sufficient for the complete protection lifetime and migration period.

5.4. A mechanism shall not be selected merely because it is currently interoperable where its expected security lifetime is shorter than the required protection period.

5.5. Long-lived Confidentiality requirements shall consider the risk that encrypted information may be collected and retained for later decryption.

5.6. Long-lived Authenticity and Integrity requirements shall consider the risk of future forgery affecting:

1. trust anchors;

2. Certificates;

3. Electronic Signatures and Electronic Seals;

4. Electronic Timestamps;

5. Electronic Attestations;

6. policy and configuration packages;

7. preserved evidence.

5.7. The applicable Profile shall identify the required security-strength category and the date or condition by which migration shall be completed.

5.8. The protection-lifetime assessment shall be reviewed following a material change in cryptanalytic knowledge, implementation capability, standards status or threat assessment.

Article 6: Approved cryptographic mechanisms and controlled catalogue

6.1. A cryptographic mechanism shall be used for a controlled production function only where it is:

1. identified in the Standards Register;

2. permitted by the applicable Profile;

3. implemented through the applicable Technical Specification;

4. suitable for the required function, security strength and protection lifetime;

5. supported by the required conformity and Validation evidence.

6.2. The Responsible Actor shall maintain or use a controlled cryptographic-mechanism catalogue.

6.3. The catalogue shall identify:

1. the mechanism and algorithm identifier;

2. the applicable standard and edition;

3. the cryptographic function;

4. the permitted parameter categories;

5. the permitted implementation contexts;

6. the minimum and maximum permitted use periods;

7. each restriction and caveat;

8. the predecessor and successor mechanisms;

9. the transition and coexistence conditions;

10. the testing and conformity requirements.

6.4. The catalogue shall distinguish mechanisms that are:

1. permitted for new protection;

2. permitted only for Verification or Historical Validation;

3. restricted to an identified transitional scope;

4. prohibited for new or continuing use;

5. permitted only for testing or migration preparation.

6.5. A mechanism permitted for Verification or Historical Validation shall not thereby be permitted for new creation, encryption, signing, sealing, timestamping, Authentication or key establishment.

6.6. A mechanism shall not be represented as approved merely because it:

1. is implemented by a product;

2. is enabled by default;

3. appears in a protocol negotiation;

4. is included in a certificate or file format;

5. has previously been used within the same Federation Domain.

6.7. A draft standard, candidate algorithm, experimental construction or vendor-defined mechanism shall not be used within a qualified or production scope unless the applicable Profile expressly permits controlled testing and excludes production reliance.

6.8. The Standards Register and cryptographic-mechanism catalogue shall preserve earlier use classifications and Effective Dates for Historical Validation.

Article 7: Algorithm identification, negotiation and downgrade protection

7.1. Each cryptographic operation shall identify the algorithm and parameter set used in a manner sufficient for deterministic Verification and Validation.

7.2. An algorithm identifier shall not rely on:

1. an unstated default;

2. an implementation-specific assumption;

3. the ordering of an undocumented list;

4. an ambiguous or reused identifier.

7.3. The applicable Technical Specification shall define:

1. algorithm identifiers;

2. parameter identifiers;

3. identifier encoding;

4. algorithm-agility fields;

5. mandatory processing behaviour;

6. unsupported-algorithm behaviour.

7.4. Algorithm negotiation shall:

1. permit only mechanisms authorised by the applicable Profile;

2. bind the selected mechanism to the protected interaction;

3. prevent unauthorised substitution;

4. prevent silent downgrade;

5. produce evidence of the offered and selected mechanisms where material.

7.5. Failure to establish an authorised common mechanism shall result in secure failure and shall not trigger an undocumented fallback.

7.6. A legacy mechanism shall not be selected solely because a participating component does not support the required replacement mechanism.

7.7. Where coexistence is permitted, the applicable Profile shall identify:

1. the permitted mechanism combinations;

2. the affected Actors and systems;

3. the beginning and end of the coexistence period;

4. the required evidence;

5. the final cutover condition.

7.8. Algorithm aliases, equivalent identifiers and external catalogue mappings shall be controlled and traceable to one authoritative mechanism entry.

Section 3: Key, secret and cryptographic-module lifecycle

Article 8: Generation, entropy and random-bit generation

8.1. A key, secret, nonce, seed or other random-dependent cryptographic value shall be generated using an approved random-bit generation arrangement.

8.2. The generation arrangement shall identify:

1. the random-bit generator;

2. the entropy source;

3. the cryptographic module or environment;

4. the health and failure tests;

5. the responsible Actor;

6. the applicable standard and Technical Specification;

7. the evidence retained.

8.3. Generation shall provide the unpredictability and security strength required by the applicable Profile.

8.4. The Responsible Actor shall ensure that:

1. entropy sources are appropriate to the operational environment;

2. deterministic generators are correctly seeded and reseeded;

3. generator state is protected;

4. repeated or predictable output is detected where practicable;

5. generator failure results in secure failure.

8.5. A virtualised, shared, remote or constrained environment shall be assessed for risks affecting entropy availability, generator state separation and output independence.

8.6. A generated key shall be subject to the required validity, structural and pairwise-consistency checks before use.

8.7. Generation evidence shall not disclose a private key, secret, seed or generator state.

8.8. A generation process that cannot establish the required entropy or generator condition shall not produce material represented as suitable for controlled use.

Article 9: Key establishment, provisioning, distribution and derivation

9.1. Key establishment, provisioning, distribution, agreement, encapsulation and derivation shall use mechanisms permitted by the applicable Profile and Technical Specification.

9.2. The applicable arrangement shall identify:

1. the participating Actors and systems;

2. the key or secret purpose;

3. the originating and receiving environments;

4. the Authentication and Authorisation conditions;

5. the mechanism and parameter identifiers;

6. the confirmation requirements;

7. the protection and evidence requirements;

8. the failure and retry behaviour.

9.3. A key or secret shall be bound to:

1. its intended cryptographic function;

2. its authorised Actor, system, service or device;

3. its applicable scope;

4. its permitted use period;

5. its applicable algorithm and parameter set.

9.4. Key derivation shall identify:

1. the input material;

2. the derivation function;

3. the context and purpose information;

4. the output-key separation rules;

5. the applicable Version.

9.5. Derived keys used for different functions, Actors, sessions, purposes or directions shall be cryptographically separated.

9.6. Key-distribution and key-establishment messages shall be protected against:

1. unauthorised disclosure;

2. substitution;

3. replay;

4. redirection;

5. unknown-key-share conditions;

6. unauthorised downgrade.

9.7. Where a key-encapsulation mechanism is used, the implementation shall apply the decapsulation-failure, key-confirmation and context-binding requirements assigned by the applicable Technical Specification.

9.8. A key or secret shall not be accepted merely because transport of the material succeeded.

Article 10: Storage, use, access, backup and Recovery

10.1. A key, secret or other cryptographic material shall be stored and used only within the Controlled Environment and purpose assigned by the applicable Profile.

10.2. Access shall be limited according to:

1. the cryptographic function;

2. the responsible Role;

3. least privilege;

4. separation of duties;

5. the applicable activation and Authorisation conditions.

10.3. Private keys, secret keys, Digital Signature Creation Data, Authentication secrets and recovery material shall be protected against:

1. unauthorised disclosure;

2. extraction;

3. duplication;

4. substitution;

5. unauthorised use;

6. rollback to an earlier state.

10.4. Separate keys shall be used for materially different functions, including where applicable:

1. Electronic Signature creation;

2. Electronic Seal creation;

3. Electronic Timestamp protection;

4. Authentication;

5. payload encryption;

6. transport protection;

7. policy or configuration-package protection;

8. Humanitarian Trust List protection;

9. Exchange Evidence protection.

10.5. A single key shall be used for more than one function only where the applicable Profile expressly permits that use and the risk, certificate, module and lifecycle conditions remain compatible.

10.6. Backup or Recovery of private or secret material shall be permitted only where:

1. the applicable Profile permits it;

2. equivalent or stronger protection is maintained;

3. the authorised custody and access model is preserved;

4. creation, access, restoration and destruction are evidenced.

10.7. A backup, escrow, reconstruction or Recovery arrangement shall not be used where it would defeat:

1. the required control of Digital Signature Creation Data;

2. the non-exportability requirement of an Authenticator or device;

3. the assigned qualified condition;

4. the required separation of duties.

10.8. Recovery of technical access to a key or secret shall not, by itself, reinstate a Status, permission, Certificate, Authenticator or Trust Service.

10.9. Plaintext key material shall not be recorded in operational logs, monitoring data, evidence records or support tickets.

Article 11: Rotation, replacement, restriction, Revocation and destruction

11.1. A Responsible Actor shall define lifecycle conditions for each key, secret, certificate-dependent key pair and trust anchor.

11.2. Lifecycle conditions shall identify:

1. generation or provisioning;

2. activation;

3. permitted use;

4. rotation or renewal;

5. restriction or Suspension;

6. Revocation;

7. replacement;

8. expiry;

9. destruction;

10. preservation of non-secret evidence.

11.3. Rotation and replacement shall occur before:

1. the permitted use period ends;

2. the mechanism becomes unsuitable;

3. the required security strength is no longer met;

4. a dependency expires or is withdrawn;

5. continued use creates an unacceptable risk.

11.4. Replacement shall preserve the relationship between:

1. the earlier and replacement keys;

2. the applicable Certificates;

3. the affected mechanisms, devices and Trust Services;

4. the Effective Dates;

5. the affected historical evidence.

11.5. Restriction, Suspension or Revocation shall prevent further use within the affected scope from the applicable Effective Date.

11.6. A revoked, destroyed or rendered-unusable private key, secret or Digital Signature Creation Data shall not be reactivated.

11.7. Secure destruction shall:

1. apply to each active, backup, cached, replicated and recoverable copy;

2. address residual material in modules, memory, storage and support systems;

3. be verified;

4. produce evidence without preserving the destroyed secret.

11.8. Destruction of secret material shall not destroy the public, Status, lifecycle and evidence information required for Historical Validation.

Article 12: Cryptographic modules, mechanisms and protected environments

12.1. A cryptographic module, mechanism, device or protected execution environment shall be selected according to:

1. the cryptographic function;

2. the sensitivity of the protected material;

3. the required security strength;

4. the operational environment;

5. the applicable Assurance and qualified conditions.

12.2. The implementation record shall identify:

1. the module, mechanism, device or environment;

2. the security boundary;

3. the hardware, firmware and software Versions;

4. the approved configuration;

5. the supported cryptographic mechanisms;

6. the assigned keys, secrets and functions;

7. the conformity or certification evidence;

8. the operational and lifecycle restrictions.

12.3. A cryptographic module shall maintain:

1. role and service separation;

2. authorised activation;

3. protection of critical security parameters;

4. approved-state control;

5. self-tests and error handling;

6. secure update and configuration control;

7. evidence of material security events.

12.4. A failed self-test, Integrity check or approved-state condition shall result in secure failure within the affected function.

12.5. A software implementation outside a certified cryptographic module shall require the risk, protection and testing evidence assigned by the applicable Profile.

12.6. Certification of a cryptographic module shall not, by itself:

1. qualify a Digital Signature Creation Device;

2. qualify a Trust Service;

3. qualify a Trust Service Provider;

4. establish the suitability of every supported mechanism;

5. assign Qualified Status to an output.

12.7. Qualified Digital Signature Creation Devices and their minimum assurance requirements shall be governed by IDEHA-IG-OBJ-DSG-001.

12.8. A material change to a cryptographic module, mechanism, device, firmware, software, configuration or operating environment shall undergo Change Control and reassessment before continued use within the earlier assessed scope.

Article 13: Trust anchors, Certificates and Validation dependencies

13.1. A Responsible Actor shall maintain a controlled record of each trust anchor and cryptographic Validation dependency within its scope.

13.2. The record shall identify:

1. the trust anchor or dependency;

2. the responsible Actor;

3. the permitted purpose and scope;

4. the algorithm and parameter identifiers;

5. the applicable Certificate or public-key information;

6. the activation and expiry times;

7. the Status and publication source;

8. the predecessor and successor relationship;

9. the distribution and update method;

10. the Historical State requirements.

13.3. Trust-anchor distribution and update packages shall be protected against unauthorised modification and substitution.

13.4. A trust anchor shall be accepted only for the purpose, scope, Federation Domain, Profile and period assigned to it.

13.5. Replacement or rollover shall preserve:

1. continuity of Validation;

2. predecessor and successor relationships;

3. overlap or transition conditions;

4. protection against unauthorised substitution;

5. historical evidence.

13.6. Removal of a trust anchor from current use shall not remove the information required to validate earlier Certificates, Trust Objects, Trust Service Outputs or evidence.

13.7. A Certificate, Humanitarian Trust List Entry or trust-anchor record shall not be accepted solely because its cryptographic protection verifies.

13.8. Validation shall also establish the applicable Status, scope, time, policy, dependency and Historical State.

Section 4: Cryptographic agility and post-quantum transition

Article 14: Cryptographic agility

14.1. A Responsible Actor shall implement cryptographic agility proportionate to the scale, criticality, protection lifetime and replacement complexity of the implementation.

14.2. Cryptographic agility shall enable controlled replacement or adaptation of:

1. algorithms;

2. parameter sets;

3. keys and secrets;

4. certificates and trust anchors;

5. modules, mechanisms and devices;

6. protocols and cryptographic containers;

7. cryptographic libraries and interfaces;

8. Validation rules.

14.3. The implementation shall avoid unnecessary hard-coding of:

1. algorithm identifiers;

2. parameter sets;

3. key lengths;

4. certificate profiles;

5. trust anchors;

6. permitted mechanism lists.

14.4. Agility controls shall include, where applicable:

1. machine-processable mechanism catalogues;

2. configurable permitted-mechanism lists;

3. explicit Version and algorithm identifiers;

4. modular cryptographic interfaces;

5. controlled negotiation;

6. dual-operation and coexistence capability;

7. migration and rollback testing;

8. visibility of current cryptographic use;

9. removal of prohibited mechanisms.

14.5. Cryptographic agility shall not permit an unauthorised component, administrator, peer or downgrade process to select a weaker mechanism.

14.6. An agility mechanism shall fail securely where the selected cryptographic configuration is not authorised or cannot be validated.

14.7. Agility shall preserve interoperability only within the conditions authorised by the applicable Profile and Technical Specification.

14.8. A capability to support several algorithms shall not create permission to use every supported algorithm.

Article 15: Restriction, deprecation and cryptographic transition

15.1. A Responsible Actor shall maintain a transition plan for each mechanism expected to become unsuitable before the end of the implementation or protection lifetime.

15.2. The transition plan shall identify:

1. the current and replacement mechanisms;

2. the affected keys, Certificates, systems, Trust Services, Trust Objects and dependencies;

3. the reason and evidence basis;

4. the target architecture;

5. the migration sequence;

6. the coexistence period;

7. the testing and conformity requirements;

8. the Effective Dates;

9. the final end of permitted use;

10. the rollback and emergency conditions;

11. the historical-evidence treatment.

15.3. Restriction or deprecation shall identify whether the affected mechanism remains permitted for:

1. new protection;

2. existing protected information;

3. Verification;

4. Historical Validation;

5. migration processing;

6. controlled testing.

15.4. A transition shall prevent:

1. silent downgrade;

2. unplanned fallback;

3. reuse of revoked or retired material;

4. loss of historical Validation evidence;

5. reintroduction of a prohibited mechanism through a dependency.

15.5. Where re-protection is required, the migration record shall preserve:

1. the original protected matter;

2. the original cryptographic evidence;

3. the migration action;

4. the replacement protection;

5. the responsible Actor;

6. the migration time.

15.6. Emergency restriction may take effect before completion of ordinary transition activities where continued use creates an unacceptable risk.

15.7. Emergency technical restriction shall not, by itself, alter governance Status, Service Permission, Qualified Status or the validity of an earlier Trust Object.

Article 16: Quantum-risk assessment and migration planning

16.1. A Responsible Actor shall assess the effect of quantum computing on each public-key cryptographic dependency within its scope.

16.2. The assessment shall consider:

1. the information-protection lifetime;

2. the time required to replace systems, devices, protocols and dependencies;

3. the time required to migrate retained data and evidence;

4. the time required to obtain confidence, interoperability and conformity evidence for replacement mechanisms;

5. the risk of retrospective decryption;

6. the risk of future signature or trust-anchor forgery;

7. the effect on qualified and historically relied-upon matters;

8. supplier and cross-domain dependencies.

16.3. The quantum-risk record shall identify:

1. the affected cryptographic asset or process;

2. the current quantum-vulnerable mechanism;

3. the protected matter and required protection period;

4. the migration priority;

5. the target mechanism category;

6. the responsible Actor;

7. the target completion date;

8. the dependencies and blockers;

9. the required testing and evidence.

16.4. The migration plan shall address:

1. inventory completion;

2. target-state definition;

3. pilot and interoperability testing;

4. certificate, key and trust-anchor transition;

5. module, mechanism and device availability;

6. protocol and format transition;

7. hybrid or coexistence arrangements where required;

8. Validation and Historical State;

9. final removal of quantum-vulnerable mechanisms.

16.5. A long-lived Confidentiality use shall be prioritised where the protected information may remain sensitive after a cryptographically relevant quantum capability could become available.

16.6. A long-lived trust anchor, archival signature or evidence-protection use shall be prioritised where future forgery could invalidate or undermine retained evidence.

16.7. A draft, candidate or non-standardised post-quantum mechanism shall not be used for production or qualified protection merely because migration urgency exists.

Article 17: Post-quantum and hybrid cryptographic arrangements

17.1. A post-quantum mechanism shall be used only where:

1. it is identified in the Standards Register;

2. the applicable Profile permits its use;

3. the applicable Technical Specification defines its integration;

4. the required module, certificate, format, protocol and Validation support exists;

5. the required testing and conformity evidence is available.

17.2. A hybrid or composite arrangement shall identify:

1. each component mechanism;

2. the function of each component;

3. the combination rule;

4. the key and lifecycle relationship;

5. the security property intended to be preserved;

6. the Validation rule;

7. the downgrade and failure behaviour;

8. the transition and retirement condition.

17.3. A hybrid arrangement shall not be constructed through an undocumented or ad hoc combination of algorithms.

17.4. The applicable Technical Specification shall establish whether successful Validation requires:

1. every component mechanism to validate;

2. an identified minimum set of component mechanisms to validate;

3. another formally defined combination rule.

17.5. A component key shall not be reused across unrelated hybrid arrangements where that reuse would create unintended dependency, Revocation or compromise propagation.

17.6. The implementation shall bind the component algorithms, keys, ciphertexts or signatures to the same cryptographic context and protected matter.

17.7. Hybrid negotiation shall be protected against downgrade to:

1. a traditional-only mechanism;

2. an unauthorised post-quantum mechanism;

3. an incomplete component set;

4. a weaker parameter set.

17.8. Hybrid operation shall preserve separately identifiable evidence for each component mechanism and the combined result.

17.9. Compromise, restriction or failure of one component shall be evaluated according to the documented combination rule and shall not be concealed by the successful operation of another component.

17.10. A hybrid arrangement shall be removed when its transitional or risk-reduction purpose no longer applies and the applicable Profile requires migration to a post-quantum-only arrangement.

Article 18: Cryptographic compromise and incident handoff

18.1. Compromise or suspected compromise of a key, secret, random-bit generator, cryptographic module, trust anchor, algorithm implementation or protected cryptographic process shall be treated as a Security Incident.

18.2. The Responsible Actor shall identify without undue delay:

1. the affected cryptographic material and mechanism;

2. the known or suspected compromise period;

3. the affected systems, Trust Services, Sources, Trust Objects, outputs and interactions;

4. the affected Certificates and trust anchors;

5. the affected protection and Validation functions;

6. the required restriction, rotation, replacement, Revocation or destruction action;

7. the required notification and incident handoff;

8. the effect on Historical State.

18.3. Immediate cryptographic containment may include:

1. prevention of further use;

2. removal from permitted-mechanism lists;

3. key or certificate Revocation;

4. trust-anchor restriction;

5. algorithm-negotiation restriction;

6. activation of a replacement mechanism.

18.4. Technical containment shall not, by itself, assign or alter Status, Qualified Status, Service Permission or Technical Exchange Permission.

18.5. The effect on an earlier Trust Object, Trust Service Output, Certificate, interaction or evidence record shall be determined according to:

1. the relevant creation or issuance time;

2. the known affected period;

3. the cryptographic evidence;

4. the applicable Status and Historical State;

5. the applicable Profile.

18.6. Recovery of a cryptographic function shall not automatically reinstate an earlier Status, permission, qualified condition or trust-anchor acceptance.

18.7. Operational containment, notification, Continuity, Recovery, reinstatement and closure shall proceed under IDEHA-IG-SEC-INC-001.

Section 5: Assurance, evidence and standards

Article 19: Testing, Assurance and Conformity Assessment

19.1. Cryptographic controls shall be tested:

1. before operational activation;

2. following a material cryptographic change;

3. before and during a cryptographic transition;

4. at the interval required by the applicable Profile;

5. following a material vulnerability or Security Incident where reassessment is required.

19.2. Testing shall address, where applicable:

1. algorithm and parameter processing;

2. random-bit generation;

3. key generation and establishment;

4. key separation and use restrictions;

5. module approved-state operation;

6. self-tests and error handling;

7. certificate and trust-anchor processing;

8. algorithm negotiation and downgrade resistance;

9. rotation, replacement and Revocation;

10. backup, Recovery and destruction;

11. hybrid and post-quantum processing;

12. interoperability and Historical Validation.

19.3. The test plan shall identify:

1. the tested scope;

2. the applicable Profile and Technical Specification Versions;

3. the algorithms and parameter sets;

4. the module, mechanism, device or software Version;

5. the methods, inputs and expected results;

6. the acceptance criteria;

7. the Responsible Actors;

8. the evidence retained.

19.4. Testing shall include negative and failure cases sufficient to demonstrate secure failure.

19.5. Known-answer, pairwise-consistency, entropy, health, interoperability and migration tests shall be performed where required by the applicable standard or Profile.

19.6. A material unresolved cryptographic non-conformity shall prevent operational use within the affected scope.

19.7. Module, mechanism, device and implementation certification shall be accepted only within the evaluated configuration and certification scope.

19.8. Successful cryptographic testing or certification shall not, by itself, establish:

1. the suitability of the mechanism for every use;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission;

5. Authorisation;

6. Controlled Reliance.

19.9. Assurance and Conformity Assessment shall be implemented in accordance with IDEHA-IG-ASR-QLF-001.

Article 20: Records and Historical State

20.1. A Responsible Actor shall retain records sufficient to reconstruct cryptographic protection and lifecycle conditions within the applicable scope.

20.2. Records shall include, where applicable:

1. the Cryptographic Implementation Plan;

2. the cryptographic inventory;

3. protection-lifetime and risk assessments;

4. mechanism-catalogue entries;

5. algorithm and parameter identifiers;

6. generation and entropy evidence;

7. key establishment, provisioning and derivation evidence;

8. module, mechanism, device and configuration evidence;

9. trust-anchor and Certificate dependencies;

10. rotation, replacement, restriction, Revocation and destruction records;

11. transition and migration records;

12. post-quantum and hybrid-arrangement records;

13. testing and Conformity Assessment evidence;

14. compromise and incident-handoff records.

20.3. Cryptographic records shall not contain secret material beyond what is strictly necessary and authorised for the assigned function.

20.4. Historical State shall preserve, where required:

1. the algorithm and parameter set;

2. the applicable standard and Technical Specification Version;

3. the key, Certificate and trust-anchor Status;

4. the module, mechanism, device and configuration;

5. the use and protection periods;

6. the applicable mechanism use classification;

7. the Validation rules applicable at the relevant time.

20.5. A mechanism prohibited for new use may remain available in an isolated Validation environment where required to validate historical evidence.

20.6. A historical Validation environment shall prevent the prohibited mechanism from being used for new protection.

20.7. Correction of a cryptographic record shall preserve:

1. the earlier record;

2. the correction basis;

3. the responsible Actor;

4. the Effective Date;

5. the affected scope.

20.8. A later mechanism, parameter, certificate, trust anchor or Validation rule shall not silently replace the Historical State applicable to an earlier protected matter.

Article 21: Reference standards and technical references

21.1. The reference standards and technical references applicable to the implementation of this Guideline are set out in Annex I.

21.2. A reference identified in Annex I shall apply only within the implementation function, scope and condition identified in that Annex.

21.3. The applicable Profile and Technical Specification shall select the exact mechanism, parameter set, identifier, format, protocol integration and test condition.

21.4. Subject-specific standards for Electronic Signatures, Electronic Seals, Electronic Timestamps, Certificates, Electronic Attestations, Authentication, Technical Exchange and Digital Signature Creation Devices shall apply through their respective Framework Instruments and shall not be repeated in Annex I.

21.5. A later edition, amendment or replacement of a reference identified in Annex I shall not apply automatically.

21.6. A later edition, amendment or replacement shall undergo standards evaluation and Change Control before it is assigned Framework effect.

21.7. Conformity with a reference standard or technical reference shall constitute evidence only for the requirements and scope mapped to that reference.

21.8. Conformity with a reference shall not, by itself, establish operational activation, Service Permission, Technical Exchange Permission, Authorisation, Qualified Status or Controlled Reliance.

Annex I: Reference standards and technical references

Reference	Implementation function	Applicability and controlled treatment
ETSI TS 119 312 V2.1.1, 2026-06, Electronic Signatures and Trust Infrastructures — Cryptographic Suites	Cryptographic suites for Electronic Signatures, Electronic Seals, Certificates, Electronic Timestamps and related Trust Services	Mandatory within its applicable subject scope. Exact suites and parameters shall be selected through the applicable Profile and Technical Specification.
ETSI TS 119 322 V1.2.1, 2024-12, Electronic Signatures and Trust Infrastructure — Schema for machine-readable cryptographic algorithms and cipher-suite catalogues	Machine-processable cryptographic-mechanism catalogue	Applicable where the cryptographic-mechanism catalogue is distributed or processed in machine-readable form.
ECCG Agreed Cryptographic Mechanisms, Version 2.0, April 2025	Current European technical reference for agreed cryptographic mechanisms used in evaluated ICT products	Applicable as the recognised mechanism-selection baseline where the applicable Profile requires alignment with European cybersecurity certification practice. Draft Version 3 shall not apply until formally adopted and recognised through the standards-management route.
ISO/IEC 11770-1:2010, Information technology — Security techniques — Key management — Part 1: Framework	General key-management framework and lifecycle model	Mandatory as the horizontal key-management reference. Subject-specific mechanisms shall be selected from the applicable further parts or another Recognised Standard.
ISO/IEC 11770-2:2018, IT Security techniques — Key management — Part 2: Mechanisms using symmetric techniques	Symmetric-key establishment mechanisms	Conditionally applicable where symmetric key-establishment mechanisms are selected.
ISO/IEC 11770-3:2021, including ISO/IEC 11770-3:2021/Amd 1:2025, Information security — Key management — Part 3: Mechanisms using asymmetric techniques	Asymmetric key agreement, transport and establishment	Conditionally applicable where the selected mechanism falls within its scope. Exact mechanism selection remains a Profile and Technical Specification matter.
ISO/IEC 11770-5:2020, Information security — Key management — Part 5: Group key management	Group-key establishment and rekeying	Conditionally applicable where a controlled group-key arrangement is selected.
ISO/IEC 11770-6:2016, Information technology — Security techniques — Key management — Part 6: Key derivation	Key-derivation functions	Applicable where keys are derived from secret input material. Context and purpose separation shall be defined by the applicable Technical Specification.
ISO/IEC 18031:2025, Information technology — Security techniques — Random bit generation	Random-bit generation model and security requirements	Mandatory for random-bit generation used in controlled cryptographic functions unless the applicable Profile selects an equivalent recognised standard.
ISO/IEC 20543:2019, Information technology — Security techniques — Test and analysis methods for random bit generators within ISO/IEC 19790 and ISO/IEC 15408	Random-bit generator testing and analysis	Applicable where independent random-bit generator testing is required.
ISO/IEC 19790:2025, Information security, cybersecurity and privacy protection — Security requirements for cryptographic modules	Cryptographic-module security requirements	Mandatory where a Profile requires an evaluated cryptographic module. The required security level and configuration shall be selected by the applicable Profile.
ISO/IEC 24759:2025, Information security, cybersecurity and privacy protection — Test requirements for cryptographic modules	Cryptographic-module conformity testing	Mandatory together with ISO/IEC 19790:2025 where module testing under that framework is required.
ISO/IEC 17825:2024, Information technology — Security techniques — Testing methods for the mitigation of non-invasive attack classes against cryptographic modules	Testing of resistance to non-invasive attacks	Conditionally applicable where side-channel and related non-invasive attack resistance is required by the applicable Profile.
NIST FIPS 203, 2024, Module-Lattice-Based Key-Encapsulation Mechanism Standard	Post-quantum key encapsulation using ML-KEM	Conditionally applicable where a post-quantum key-encapsulation mechanism is selected. The parameter set and protocol integration shall be defined by the applicable Profile and Technical Specification.
NIST FIPS 204, 2024, Module-Lattice-Based Digital Signature Standard	Post-quantum Digital Signatures using ML-DSA	Conditionally applicable where a post-quantum Digital Signature mechanism is selected and the applicable Certificate, format, device and Validation support is available.
NIST FIPS 205, 2024, Stateless Hash-Based Digital Signature Standard	Post-quantum Digital Signatures using SLH-DSA	Conditionally applicable where a stateless hash-based Digital Signature mechanism is selected and the applicable Certificate, format, device and Validation support is available.
NIST SP 800-227, 2025, Recommendations for Key-Encapsulation Mechanisms	Secure implementation and use of key-encapsulation mechanisms	Applicable where a key-encapsulation mechanism, including ML-KEM, is used.
NIST CSWP 39-upd1, 2026, Considerations for Achieving Crypto Agility: Strategies and Practices	Cryptographic-agility planning and implementation	Applicable as supporting guidance for Article 14 and cryptographic-transition planning.
ETSI TR 103 619 V1.1.1, 2020-07, Migration strategies and recommendations to Quantum Safe schemes	Quantum-safe inventory, migration planning and execution	Applicable as supporting guidance for the migration process governed by Article 16.
ETSI TR 104 016 V1.1.1, 2024-10, Quantum-Safe Cryptography — A Repeatable Framework for Quantum-Safe Migrations	Repeatable quantum-safe migration framework	Applicable as supporting guidance for planning, prioritisation and execution of quantum-safe migration.
ETSI TR 103 966 V1.1.1, 2024-10, Quantum-Safe Cryptography — Deployment Considerations for Hybrid Schemes	Design and deployment considerations for traditional and post-quantum hybrid schemes	Applicable as supporting guidance where a hybrid arrangement is permitted under Article 17.

IDEHA-IG-SEC-INC-001: Security Incident, Continuity and Recovery Implementation

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for Security Incident readiness, assessment, response, Continuity, Degraded Operation, Recovery and post-incident improvement under the Framework.

1.2. This Guideline shall apply to each Responsible Actor, Framework Body, Trust Service Provider, Source Holder, Source Steward, Issuer, Relying Actor, Technical Exchange Route Operator, Intermediary, supporting Actor and technical operator responsible for a Controlled Matter, Controlled Environment, Trust Service, Source, Trust Object, Trust Service Output, mechanism, device, Authenticator, Endpoint, Technical Exchange Route, Register, Catalogue or Humanitarian Trust List component.

1.3. This Guideline shall govern, where applicable:

1. Security Incident readiness;

2. detection and initial assessment;

3. incident classification;

4. incident coordination and escalation;

5. evidence preservation;

6. containment and corrective action;

7. notification and communication;

8. Continuity arrangements;

9. Degraded Operation;

10. Recovery and restoration;

11. reinstatement support;

12. post-incident Review and improvement.

1.4. This Guideline shall not:

1. redefine Security Incident, Continuity, Degraded Operation, Recovery, Reinstatement, Status, Suspension, Withdrawal, Revocation or Controlled Effects established by the Main Framework;

2. replace preventive security controls established by IDEHA-IG-SEC-CNF-001;

3. replace cryptographic controls established by IDEHA-IG-SEC-CRY-001;

4. assign Status, Qualified Status, Service Permission, Technical Exchange Permission, Authorisation or Controlled Reliance;

5. determine the legal consequences of a Security Incident;

6. replace a Framework Decision required for restriction, Suspension, Withdrawal, Revocation, reinstatement or qualification action;

7. prescribe exact technical response tools, forensic products, communication platforms, protocol bindings or recovery technologies.

1.5. Security controls, cryptographic controls, access controls, confidentiality controls and vulnerability controls shall continue to apply during Security Incident response, Degraded Operation and Recovery unless a formally approved exception applies.

1.6. Compliance with this Guideline shall not, by itself, establish a Security Incident classification, Status change, qualification action, Remedy outcome or permission for Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the governed operational context;

2. the participating Actors;

3. the affected Federation Domains;

4. the applicable Review Routes and Remedy Routes;

5. the coordination and notification expectations.

2.2. The applicable Security Incident, Continuity and Recovery Profile shall identify:

1. incident categories and severity conditions;

2. Responsible Actors;

3. notification thresholds;

4. evidence requirements;

5. coordination arrangements;

6. Degraded Operation conditions;

7. Recovery objectives;

8. restoration conditions;

9. reinstatement evidence;

10. testing and exercise requirements;

11. historical reconstruction requirements.

2.3. The applicable Technical Specification shall define:

1. technical monitoring interfaces;

2. event formats;

3. notification formats;

4. communication protocols;

5. recovery automation interfaces;

6. technical test procedures.

2.4. Subject-specific Implementation Guidelines shall establish additional incident, Continuity and Recovery requirements only where required by their subject matter.

2.5. A Security Incident process, technical event, monitoring alert, continuity action or recovery activity shall not create a Framework Decision, Status change, Authorisation or Controlled Effect.

Article 3: Security Incident and Continuity Implementation Plan

3.1. A Responsible Actor shall maintain a Security Incident and Continuity Implementation Plan for each Controlled Matter within its responsibility.

3.2. The Implementation Plan shall identify:

1. the scope of the plan;

2. Responsible Actors;

3. supporting Actors;

4. Security Incident roles;

5. communication and escalation routes;

6. affected Controlled Matters;

7. dependencies;

8. evidence sources;

9. detection and monitoring arrangements;

10. initial assessment procedures;

11. containment procedures;

12. Continuity arrangements;

13. Degraded Operation conditions;

14. Recovery procedures;

15. reinstatement support;

16. testing and exercise arrangements;

17. Review and improvement processes.

3.3. The Implementation Plan shall distinguish:

1. preventive security controls from incident response;

2. an operational event from a Security Incident;

3. technical containment from Status restriction;

4. Recovery from reinstatement;

5. reinstatement support from a Framework Decision;

6. incident evidence from substantive business records;

7. availability restoration from Controlled Reliance restoration.

3.4. The Responsible Actor shall review and update the Implementation Plan following:

1. a material Security Incident;

2. a material dependency change;

3. a material architectural change;

4. a major exercise result;

5. a material vulnerability.

3.5. Approval of an Implementation Plan shall not create a right to continue operation where mandatory security, Status, permission or qualified conditions are not satisfied.

Section 2: Incident readiness and assessment

Article 4: Incident readiness

4.1. A Responsible Actor shall maintain readiness to detect, assess, coordinate and respond to Security Incidents affecting its scope.

4.2. Readiness arrangements shall identify:

1. incident detection sources;

2. monitoring responsibilities;

3. incident contacts;

4. escalation routes;

5. evidence-preservation responsibilities;

6. affected-Actor communication routes;

7. decision and approval routes;

8. external coordination requirements where applicable.

4.3. The Responsible Actor shall maintain current contact information for:

1. internal incident functions;

2. supporting Actors;

3. affected Framework Bodies;

4. Conformity Assessment Bodies where required;

5. other Actors identified by the applicable Profile.

4.4. Incident-readiness arrangements shall consider:

1. Trust Services;

2. Sources;

3. Trust Objects;

4. Trust Service Outputs;

5. Humanitarian Trust List information;

6. Endpoints;

7. Technical Exchange Routes;

8. cryptographic dependencies;

9. protected functions;

10. Protected-Person Safeguards.

4.5. Incident-readiness exercises shall verify:

1. communication;

2. escalation;

3. evidence preservation;

4. coordination;

5. Continuity;

6. Recovery;

7. reinstatement support.

4.6. Exercise results shall identify:

1. scope;

2. date;

3. participants;

4. findings;

5. corrective actions;

6. responsible Actor;

7. completion date.

Article 5: Detection and initial assessment

5.1. A Responsible Actor shall assess detected events to determine whether they may constitute a Security Incident.

5.2. Initial assessment shall identify:

1. affected Controlled Matter;

2. affected Actor;

3. affected system, service, Source, Trust Object, Endpoint or dependency;

4. detection source;

5. occurrence time where known;

6. detection time;

7. available evidence;

8. potential Confidentiality, Integrity, Authenticity, Availability or Accountability impact;

9. required immediate protective measures.

5.3. An event shall remain distinguishable from a Security Incident until sufficient information exists to classify it.

5.4. Lack of complete information shall not prevent protective action where delay may increase harm.

5.5. Initial assessment shall not:

1. assign Status;

2. establish liability;

3. determine legal effect;

4. determine Remedy outcome.

5.6. Where an event cannot be ruled out as a Security Incident, the Responsible Actor shall apply the protective and coordination measures required by the applicable Profile.

Article 6: Incident classification

6.1. A Responsible Actor shall classify Security Incidents according to the applicable Incident Profile.

6.2. Classification shall consider:

1. affected Controlled Matters;

2. affected persons;

3. affected Actors;

4. Confidentiality impact;

5. Integrity impact;

6. Authenticity impact;

7. Availability impact;

8. Accountability impact;

9. geographic or Federation Domain scope;

10. duration;

11. dependency impact;

12. potential effect on Status, Qualification or Controlled Reliance.

6.3. Incident severity shall identify:

1. classification basis;

2. evidence supporting classification;

3. affected scope;

4. required response level;

5. notification obligations.

6.4. Incident severity shall be reviewed where new evidence materially changes the assessed impact.

6.5. Classification shall not automatically result in:

1. Suspension;

2. Withdrawal;

3. Revocation;

4. Status change;

5. Remedy outcome.

Those actions require the applicable Framework process.

Section 3: Incident response and coordination

Article 7: Incident response roles and coordination

7.1. A Responsible Actor shall assign incident-response roles.

7.2. Incident-response roles shall identify:

1. incident coordinator;

2. technical responders;

3. evidence-preservation function;

4. communication function;

5. Framework coordination function;

6. Recovery coordination function.

7.3. Roles shall remain separate from Framework Decision Competence unless expressly assigned.

7.4. A technical responder shall not acquire Decision Competence merely by controlling technical recovery.

7.5. A Framework Body shall be notified where the incident may affect:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission;

5. Humanitarian Trust List publication;

6. Controlled Reliance.

Article 8: Evidence preservation

8.1. A Responsible Actor shall preserve evidence necessary to understand, assess, respond to and review a Security Incident.

8.2. Evidence preservation shall identify:

1. affected systems and Controlled Matters;

2. relevant times;

3. event records;

4. configuration state;

5. access records;

6. authentication records;

7. cryptographic evidence;

8. dependency information;

9. response actions.

8.3. Evidence shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. access history;

5. time information;

6. chain of custody where applicable.

8.4. Evidence preservation shall avoid unnecessary collection of personal data or Protected-Person Information.

8.5. Evidence shall be protected against:

1. unauthorised access;

2. alteration;

3. deletion;

4. disclosure.

8.6. Incident evidence shall remain separate from:

1. substantive Source records;

2. Trust Objects;

3. Trust Service Outputs;

4. Authorisation Outcomes.

Article 9: Containment and corrective action

9.1. A Responsible Actor shall implement containment measures appropriate to the incident scope and risk.

9.2. Containment measures may include:

1. isolation;

2. restriction of access;

3. credential restriction;

4. key or certificate restriction;

5. Endpoint restriction;

6. Technical Exchange Route restriction;

7. service restriction;

8. temporary processing limitation.

9.3. Containment shall preserve evidence required for:

1. Review;

2. Remedy;

3. Assurance;

4. Conformity Assessment;

5. Historical State.

9.4. Corrective actions shall identify:

1. affected scope;

2. root cause where determined;

3. correction performed;

4. responsible Actor;

5. verification method;

6. completion date;

7. remaining risks.

9.5. Containment or corrective action shall not:

1. create Authorisation;

2. create Status;

3. reinstate Qualified Status;

4. replace a Framework Decision.

Article 10: Notification and communication

10.1. A Responsible Actor shall notify the Actors and Framework Bodies identified by the applicable Incident Profile.

10.2. Notification shall identify, where applicable:

1. incident identifier;

2. affected scope;

3. classification;

4. known impact;

5. protective measures;

6. required actions;

7. communication contact;

8. update schedule.

10.3. Notification shall contain sufficient information for coordination while protecting:

1. Security-Sensitive Information;

2. Protection-Sensitive Information;

3. personal data;

4. operationally sensitive information.

10.4. Notification shall not disclose information beyond the recipient’s authorised purpose and scope.

10.5. A notification shall be corrected where new material information changes:

1. impact;

2. affected scope;

3. required action;

4. Recovery conditions.

Section 4: Continuity, Degraded Operation and Recovery

Article 11: Continuity arrangements

11.1. A Responsible Actor shall maintain Continuity arrangements for each critical Controlled Matter.

11.2. Continuity arrangements shall identify:

1. critical functions;

2. Recovery objectives;

3. dependencies;

4. alternative operating conditions;

5. responsible Actors;

6. communication routes;

7. evidence preservation requirements.

11.3. Continuity arrangements shall consider:

1. Trust Services;

2. Sources;

3. Trust Objects;

4. Technical Exchange Routes;

5. Humanitarian Trust List availability;

6. cryptographic dependencies;

7. supporting Actors.

11.4. A Continuity arrangement shall not bypass:

1. Authorisation;

2. Confidentiality;

3. Integrity;

4. Authenticity;

5. required Status checks;

6. qualified conditions.

Article 12: Degraded Operation

12.1. A Responsible Actor may operate in Degraded Operation only where:

1. the condition is identified by the applicable Profile;

2. the residual risk is assessed;

3. the permitted scope is defined;

4. responsible approval is obtained;

5. monitoring remains active.

12.2. Degraded Operation shall identify:

1. permitted functions;

2. prohibited functions;

3. affected Actors;

4. duration;

5. compensating controls;

6. exit conditions.

12.3. Degraded Operation shall not permit:

1. unauthorised disclosure;

2. bypass of Authorisation;

3. bypass of payload protection;

4. creation of unvalidated Trust Objects;

5. unrecorded privileged actions.

12.4. Degraded Operation records shall identify all actions performed during the degraded period.

12.5. A Degraded Operation condition shall end when:

1. normal operation is restored; or

2. the permitted period expires; or

3. risk exceeds the approved condition.

Article 13: Recovery and restoration

13.1. Recovery shall restore affected functions according to the applicable Recovery Plan.

13.2. Recovery shall verify:

1. system Integrity;

2. configuration correctness;

3. dependency availability;

4. security-control operation;

5. monitoring capability;

6. evidence availability.

13.3. Recovery shall not restore:

1. expired Status;

2. revoked credentials;

3. withdrawn Trust Services;

4. removed permissions.

13.4. Before return to normal operation, the Responsible Actor shall verify:

1. security conditions;

2. Authorisation conditions;

3. dependency conditions;

4. operational readiness;

5. evidence continuity.

13.5. Restoration shall be recorded.

Section 5: Reassessment, improvement and lifecycle

Article 14: Reassessment and reinstatement support

14.1. A Responsible Actor shall determine whether reassessment is required following a Security Incident.

14.2. Reassessment shall be considered where the incident affects:

1. Assurance conditions;

2. Conformity Assessment scope;

3. Qualified Scope;

4. Security boundary;

5. cryptographic protection;

6. Trust Service operation;

7. Source reliability;

8. Technical Exchange Permission.

14.3. Reassessment evidence shall identify:

1. incident reference;

2. affected scope;

3. corrective actions;

4. verification performed;

5. remaining risks;

6. required decisions.

14.4. A Responsible Actor seeking reinstatement of an affected Status or permission shall submit evidence according to the applicable Framework process.

14.5. Recovery completion, technical correction or incident closure shall not automatically reinstate:

1. Service Permission;

2. Technical Exchange Permission;

3. Status;

4. Qualified Status;

5. Controlled Reliance.

14.6. Reinstatement shall occur only through the applicable Framework Decision or lifecycle process.

Article 15: Post-incident review and improvement

15.1. A Responsible Actor shall conduct a post-incident Review following each material Security Incident.

15.2. The Review shall consider:

1. detection effectiveness;

2. assessment accuracy;

3. response effectiveness;

4. evidence handling;

5. communication effectiveness;

6. Continuity performance;

7. Recovery performance;

8. dependency performance;

9. control effectiveness;

10. required improvements.

15.3. The Review record shall identify:

1. lessons learned;

2. corrective actions;

3. responsible Actor;

4. completion date;

5. verification method.

15.4. Improvements shall be incorporated into:

1. security controls;

2. risk assessments;

3. Implementation Plans;

4. Continuity arrangements;

5. training and exercises;

6. Profiles or Technical Specifications where required.

15.5. A post-incident Review shall not replace a Complaint, Review Route or Remedy Route available to affected persons or Actors.

Article 16: Records and Historical State

16.1. A Responsible Actor shall retain records sufficient to reconstruct the Security Incident lifecycle.

16.2. Records shall include, where applicable:

1. detection records;

2. initial assessment;

3. classification;

4. evidence preservation;

5. coordination records;

6. notification records;

7. containment actions;

8. Continuity actions;

9. Degraded Operation records;

10. Recovery actions;

11. reassessment evidence;

12. reinstatement support;

13. post-incident Review.

16.3. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. access history;

5. relevant time information;

6. affected scope.

16.4. Records shall remain protected against unauthorised alteration, disclosure and deletion.

16.5. Historical State shall remain reconstructable for:

1. Validation;

2. Assurance;

3. Conformity Assessment;

4. supervision;

5. Review;

6. Remedy;

7. Controlled Reliance.

16.6. Correction of an incident record shall preserve:

1. the earlier record;

2. correction basis;

3. responsible Actor;

4. Effective Date;

5. affected scope.

Article 17: Reference standards and specifications

17.1. The reference standards applicable to this Guideline are set out in Annex I.

17.2. A reference identified in Annex I shall apply only within the implementation function and scope identified in that Annex.

17.3. Exact incident tools, communication protocols, recovery automation interfaces and technical procedures shall be defined through the applicable Profile and Technical Specification.

17.4. Security governance, security controls and cryptographic controls shall apply through IDEHA-IG-SEC-CNF-001 and IDEHA-IG-SEC-CRY-001.

17.5. A later edition, amendment or replacement of a reference identified in Annex I shall not apply automatically.

17.6. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that reference.

17.7. Conformity with a referenced standard shall not, by itself, establish Security Incident classification, Status change, qualification action, Service Permission, Technical Exchange Permission or Controlled Reliance.

Annex I: Reference standards

Reference	Implementation function	Applicability and controlled treatment
ISO/IEC 27035-1:2023, Information security incident management — Part 1: Principles and process	Security Incident management principles	Applicable as the principal Security Incident management reference.
ISO/IEC 27035-2:2016, Information security incident management — Part 2: Guidelines to plan and prepare for incident response	Incident preparedness and planning	Applicable for readiness, roles, procedures and response preparation.
ISO/IEC 27035-3:2020, Information security incident management — Part 3: Guidelines for ICT incident response operations	ICT incident response operations	Applicable for technical incident response activities.
ISO/IEC 27031:2025, Cybersecurity — ICT readiness for business continuity	ICT continuity and recovery readiness	Applicable for ICT continuity planning, recovery capability and restoration readiness.
ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements	Business continuity management	Applicable where a formal business continuity management system is implemented or required by the applicable Profile.
ISO 22320:2018, Security and resilience — Emergency management — Requirements for incident response	Incident-response coordination	Applicable where multi-Actor emergency coordination arrangements are required.
ISO 22361:2022, Security and resilience — Crisis management — Guidance	Crisis-management guidance	Applicable as supporting guidance for significant cross-domain incidents.
ISO/IEC 27002:2022, Information security, cybersecurity and privacy protection — Information security controls	Security controls supporting incident prevention, detection and response	Applied through IDEHA-IG-SEC-CNF-001. Repeated controls shall not be duplicated here.
ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks	Risk reassessment after incidents	Applicable for post-incident risk reassessment and improvement.
ISO 19011:2018, Guidelines for auditing management systems	Post-incident review and audit methods	Applicable where formal audit activities are performed.

IDEHA-IG-GOV-SUP-001: Supervision and Corrective Action Implementation

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for supervisory activities, compliance monitoring, findings management, corrective action and follow-up verification under the Framework.

1.2. This Guideline shall apply to Framework Bodies, supervisory functions, Responsible Actors, Trust Service Providers, Source Holders, Source Stewards, Issuers, Conformity Assessment Bodies, supporting Actors and other Actors subject to supervision under the applicable Framework Instrument.

1.3. This Guideline shall govern, where applicable:

1. supervisory planning;

2. supervisory scope definition;

3. evidence requests and evidence review;

4. supervisory activities and monitoring;

5. findings identification and classification;

6. corrective action planning;

7. remediation monitoring;

8. escalation recommendations;

9. closure verification;

10. supervisory records and Historical State.

1.4. This Guideline shall not:

1. establish Framework governance roles;

2. assign Decision Competence;

3. create supervisory authority;

4. assign Status, Qualified Status, Service Permission or Technical Exchange Permission;

5. determine sanctions, legal consequences or External Legal Effect;

6. replace Assurance evaluation, Conformity Assessment or qualification processes;

7. replace Security Incident response;

8. replace Complaint, Review or Remedy Routes.

1.5. Supervision shall operate within the competence, scope and authority established by the Main Framework and applicable Annexes.

1.6. A supervisory activity, finding, corrective action or recommendation shall not, by itself, create a Framework Decision or Controlled Effect.

Article 2: Supervision planning and scope

2.1. A supervisory function shall maintain a supervision plan for each supervised scope.

2.2. The supervision plan shall identify:

1. the supervised Actor;

2. the supervised Controlled Matters;

3. the applicable Framework Instruments;

4. the applicable Profiles and Versions;

5. the supervisory objectives;

6. the supervision frequency;

7. the supervisory methods;

8. the evidence requirements;

9. the reporting arrangements;

10. the escalation conditions;

11. the follow-up arrangements.

2.3. The supervision plan shall consider:

1. the nature and criticality of the supervised Service, Source, Trust Object, Trust Service Output or dependency;

2. the applicable Assurance Conditions;

3. previous findings;

4. Security Incidents;

5. material changes;

6. dependency risks;

7. complaints, Review outcomes and Remedy outcomes where relevant.

2.4. Supervision scope shall identify separately:

1. Trust Service Provider;

2. individual Trust Service;

3. Source;

4. Trust Object or Trust Service Output;

5. mechanism or device;

6. Endpoint or Technical Exchange Route;

7. supporting Actor.

2.5. Supervision of a Trust Service Provider shall not automatically constitute supervision of each Trust Service operated by that Provider.

2.6. Supervision of one Trust Service shall not automatically establish compliance of another Trust Service.

2.7. The supervision plan shall be reviewed following:

1. material change;

2. repeated findings;

3. Security Incident;

4. significant dependency failure;

5. change in applicable Framework requirements.

Article 3: Supervisory methods

3.1. Supervisory activities may include:

1. document review;

2. evidence review;

3. interviews;

4. inspection;

5. observation;

6. technical verification;

7. sampling;

8. remote assessment;

9. onsite activity where required.

3.2. The supervisory function shall select methods proportionate to:

1. the supervised scope;

2. the risk;

3. the applicable Assurance Conditions;

4. previous findings;

5. available evidence.

3.3. Supervisory methods shall identify:

1. purpose;

2. scope;

3. evidence examined;

4. responsible supervisory function;

5. date and duration;

6. limitations.

3.4. Remote supervisory methods may be used where they provide sufficient evidence for the supervisory objective.

3.5. A supervisory function shall not infer compliance solely from:

1. absence of complaints;

2. absence of known incidents;

3. existence of certification;

4. existence of a previous positive finding.

3.6. A supervisory activity shall remain separate from:

1. Conformity Assessment;

2. qualification decision;

3. Status assignment;

4. Remedy decision.

Article 4: Supervisory evidence

4.1. A supervised Actor shall provide evidence necessary for the supervisory activity within the applicable scope.

4.2. Evidence provided for supervision shall identify:

1. the source;

2. responsible Actor;

3. creation time;

4. Version;

5. applicable scope;

6. Integrity and Authenticity information where required.

4.3. The supervisory function shall evaluate:

1. relevance;

2. completeness;

3. reliability;

4. consistency;

5. applicability period.

4.4. Evidence shall be protected against:

1. unauthorised access;

2. alteration;

3. deletion;

4. disclosure.

4.5. The supervisory function shall limit collection of information to what is necessary for the supervisory purpose.

4.6. Protection-Sensitive Information and Security-Sensitive Information shall be handled according to the applicable Security Conditions.

4.7. Evidence used for supervision shall remain attributable to its originating Actor.

4.8. A supervisory function shall not become the owner of evidence solely because it reviews or stores that evidence.

Article 5: Supervisory findings

5.1. A supervisory function shall record findings identified during supervision.

5.2. A finding shall identify:

1. supervised Actor;

2. affected Controlled Matter;

3. applicable requirement;

4. evidence basis;

5. observation;

6. impact;

7. severity;

8. required action;

9. responsible Actor;

10. due date.

5.3. Findings may include:

1. conformity confirmation;

2. observation;

3. improvement opportunity;

4. non-conformity;

5. material non-conformity.

5.4. A finding shall distinguish between:

1. evidence;

2. supervisory evaluation;

3. recommended action;

4. Framework Decision requiring separate competence.

5.5. A finding shall not:

1. assign Status;

2. withdraw Status;

3. suspend Service Permission;

4. create liability;

5. determine Remedy.

Article 6: Non-conformity management

6.1. A non-conformity shall identify the failed requirement and affected scope.

6.2. A non-conformity record shall include:

1. requirement reference;

2. affected Actor;

3. affected Controlled Matter;

4. evidence basis;

5. impact assessment;

6. corrective action requirement;

7. completion deadline;

8. verification method.

6.3. A material non-conformity shall be escalated where it may affect:

1. Qualified Status;

2. Service Permission;

3. Technical Exchange Permission;

4. Source Status;

5. Trust Object reliance;

6. Protected-Person Safeguards.

6.4. A non-conformity shall remain open until:

1. corrective action is completed;

2. evidence is provided;

3. verification is performed;

4. closure is recorded.

6.5. A supervised Actor shall not close its own non-conformity without the required independent verification where applicable.

6.6. Closure of a non-conformity shall not automatically restore:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Technical Exchange Permission.

Article 7: Corrective action plans

7.1. Where corrective action is required, the responsible Actor shall prepare a corrective action plan.

7.2. The corrective action plan shall identify:

1. identified deficiency;

2. root cause where applicable;

3. corrective action;

4. responsible Actor;

5. implementation date;

6. verification evidence;

7. residual risk;

8. preventive improvement.

7.3. Corrective action shall address both:

1. immediate correction;

2. prevention of recurrence.

7.4. The supervisory function shall evaluate whether the proposed corrective action is proportionate to:

1. the finding;

2. the risk;

3. the affected scope;

4. the potential impact.

7.5. A corrective action plan shall not replace:

1. incident response;

2. Conformity Assessment;

3. qualification reassessment;

4. Framework Decision.

Article 8: Follow-up verification

8.1. A supervisory function shall verify completion of corrective actions according to the corrective action plan.

8.2. Verification shall determine:

1. completion;

2. evidence sufficiency;

3. effectiveness;

4. remaining risks;

5. need for additional action.

8.3. Follow-up verification shall identify:

1. verification date;

2. verified scope;

3. evidence examined;

4. verification method;

5. conclusion.

8.4. Where corrective action is insufficient, the supervisory function shall:

1. maintain the finding;

2. require additional corrective action;

3. escalate according to competence.

8.5. Repeated or systemic findings shall trigger supervisory review of:

1. risk;

2. supervision frequency;

3. need for escalation;

4. need for reassessment.

Article 9: Escalation and recommendations

9.1. A supervisory function shall escalate matters where:

1. corrective action is not completed;

2. repeated findings occur;

3. a material risk remains;

4. Qualified Conditions may no longer be satisfied;

5. Protected-Person Safeguards may be affected.

9.2. Escalation information shall identify:

1. affected scope;

2. evidence basis;

3. supervisory findings;

4. corrective action history;

5. recommended next steps.

9.3. Recommendations shall remain separate from Framework Decisions.

9.4. The competent Framework Body shall determine any action requiring Decision Competence.

9.5. A supervisory function shall not:

1. assign Status;

2. revoke Status;

3. suspend Status;

4. create a qualification decision.

Article 10: Supervision of material changes

10.1. A supervised Actor shall notify material changes affecting the supervised scope where required by the applicable Framework Instrument.

10.2. Material changes may include:

1. organisational changes;

2. Service Scope changes;

3. Source changes;

4. technical architecture changes;

5. cryptographic changes;

6. dependency changes;

7. security boundary changes;

8. qualification-impacting changes.

10.3. The supervisory function shall determine whether:

1. additional supervision is required;

2. reassessment is required;

3. corrective action is required;

4. escalation is required.

10.4. A material change shall not automatically alter Status or Qualified Status.

Article 11: Supervisory records

11.1. A supervisory function shall maintain records sufficient to reconstruct supervisory activities.

11.2. Records shall include:

1. supervision plans;

2. evidence requests;

3. evidence received;

4. supervisory activities;

5. findings;

6. corrective action plans;

7. verification results;

8. escalation records;

9. closure decisions.

11.3. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. Version;

5. time;

6. responsible Actor.

11.4. Supervisory records shall remain available for:

1. Review;

2. Remedy;

3. Assurance;

4. Conformity Assessment;

5. Historical State determination.

11.5. Correction of supervisory records shall preserve:

1. previous record;

2. correction basis;

3. responsible Actor;

4. Effective Date

Article 12: Reference standards and specifications

12.1. The reference standards applicable to this Guideline are set out in Annex I.

12.2. Standards shall apply only within the implementation function identified in Annex I.

12.3. Exact supervisory methods, evidence formats and reporting structures may be established through applicable Profiles and Technical Specifications.

12.4. Conformity with a referenced standard shall not create:

1. supervisory authority;

2. Status;

3. Qualified Status;

4. Controlled Effects.

Annex I: Reference standards

Reference	Implementation function	Applicability
ISO 19011:2018, Guidelines for auditing management systems	Supervisory audit methods	Applicable as guidance for planning, conducting and documenting supervisory reviews.
ISO/IEC 17021-1:2015, Conformity assessment — Requirements for bodies providing audit and certification of management systems	Management-system audit competence where supervisory activities use such methods	Applicable only where management-system audit functions are performed.
ISO/IEC 17065:2012, Conformity assessment — Requirements for bodies certifying products, processes and services	Certification relationship distinction	Applicable only to distinguish certification activities from supervision.
ISO/IEC 27005:2022, Information security, cybersecurity and privacy protection — Guidance on managing information security risks	Risk-based supervisory planning	Applicable where supervision evaluates security-risk treatment.
ISO/IEC 27001:2022, Information security management systems — Requirements	Security-management evidence review	Applicable where supervised Actors operate an information security management system.
ISO/IEC 27701:2025, Privacy information management systems	Privacy-management supervision	Applicable where supervision includes personal-data processing controls.

IDEHA-IG-RMR-GEN-001: Protected-Person Safeguards, Complaint, Correction, Review and Remedy Implementation

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for Protected-Person Safeguards, accessibility, complaint handling, correction requests, Review Routes and Remedy Routes under the Framework.

1.2. This Guideline shall apply to each Framework Body, Responsible Actor, Trust Service Provider, Source Holder, Source Steward, Issuer, Relying Actor, supporting Actor and technical operator whose implementation affects a Protected Person.

1.3. This Guideline shall govern, where applicable:

1. safeguard implementation planning;

2. accessibility and Accessible Alternatives;

3. non-exclusion measures;

4. adverse-effect assessment;

5. complaint intake and handling;

6. correction requests;

7. Review Route implementation;

8. Remedy Route implementation;

9. affected-person communication;

10. records, evidence and improvement.

1.4. This Guideline shall not:

1. create rights, obligations, entitlements or legal remedies beyond those established by the Main Framework;

2. replace judicial, administrative or external legal procedures;

3. assign Decision Competence;

4. determine Status, Qualified Status, Service Permission or Technical Exchange Permission;

5. replace Security Incident response;

6. replace supervision, Assurance, Conformity Assessment or qualification processes;

7. determine compensation, sanctions or external legal consequences.

1.5. Compliance with this Guideline shall not, by itself, establish a Remedy outcome, Framework Decision, External Legal Status, External Legal Effect or permission for Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the affected persons and operational context;

2. the participating Actors;

3. the relevant services, Sources, Trust Objects or Trust Service Outputs;

4. the applicable safeguards;

5. the Review and Remedy arrangements.

2.2. The applicable Profile shall identify:

1. the Protected-Person Safeguards applicable to the implementation;

2. accessibility requirements;

3. Accessible Alternatives;

4. non-exclusion measures;

5. adverse-effect assessment requirements;

6. communication requirements;

7. complaint and correction processes;

8. Review Route conditions;

9. Remedy Route conditions;

10. evidence and record requirements.

2.3. The applicable Technical Specification shall define:

1. accessibility interfaces;

2. communication formats;

3. technical support mechanisms;

4. accessibility testing requirements;

5. technical implementation details.

2.4. A safeguard, accessibility measure, complaint, correction, Review or Remedy process shall not modify:

1. Trust Service Categories;

2. Trust Object Categories;

3. Status;

4. Qualified Status;

5. Decision Competence;

6. Controlled Effects.

Article 3: Safeguard Implementation Plan

3.1. A Responsible Actor shall maintain a Protected-Person Safeguard Implementation Plan where its implementation may affect Protected Persons.

3.2. The Implementation Plan shall identify:

1. affected persons and groups;

2. affected services, Sources, Trust Objects or Trust Service Outputs;

3. potential adverse effects;

4. accessibility requirements;

5. Accessible Alternatives;

6. communication arrangements;

7. complaint and correction routes;

8. Review Routes;

9. Remedy Routes;

10. responsible Actors;

11. monitoring and improvement arrangements.

3.3. The Implementation Plan shall distinguish:

1. accessibility from identity verification;

2. assistance from representation;

3. complaint handling from Security Incident response;

4. correction from modification of authoritative records;

5. Review from supervision;

6. Remedy from qualification or Status decisions.

3.4. The Responsible Actor shall review the Implementation Plan following:

1. material service changes;

2. adverse-effect findings;

3. repeated complaints;

4. accessibility failures;

5. material changes affecting Protected Persons.

3.5. Approval of a Safeguard Implementation Plan shall not create access, entitlement, Status or Authorisation.

Article 4: Accessibility requirements

4.1. A Responsible Actor shall implement accessibility measures appropriate to the affected service, Source, Trust Object, Trust Service Output or interaction.

4.2. Accessibility measures shall consider:

1. different communication needs;

2. different levels of digital capability;

3. assistive technology compatibility;

4. language and communication barriers;

5. temporary or permanent limitations affecting interaction;

6. environmental and operational constraints.

4.3. Accessibility requirements shall be proportionate to:

1. the purpose of the implementation;

2. the potential adverse effect;

3. the available safeguards;

4. the operational context.

4.4. A lack of accessibility shall not result in unnecessary exclusion where a lawful and secure alternative interaction method can be provided.

4.5. Accessibility measures shall preserve applicable:

1. Security Conditions;

2. Assurance Conditions;

3. Integrity requirements;

4. Authenticity requirements.

Article 5: Accessible Alternatives

5.1. Where a primary interaction method may create exclusion, the Responsible Actor shall provide an Accessible Alternative where required by the applicable Profile.

5.2. An Accessible Alternative may include:

1. assisted interaction;

2. alternative communication channels;

3. human-supported processes;

4. alternative verification methods;

5. alternative presentation formats;

6. additional support mechanisms.

5.3. An Accessible Alternative shall identify:

1. the applicable service function;

2. the alternative process;

3. the responsible Actor;

4. the security conditions;

5. the evidence requirements;

6. the limitations.

5.4. An Accessible Alternative shall not:

1. reduce mandatory safeguards;

2. create an unauthorised exception;

3. transfer responsibility to the Protected Person.

5.5. The use of an Accessible Alternative shall be recorded where required for Accountability, Review or Remedy.

Article 6: Non-exclusion implementation

6.1. A Responsible Actor shall assess whether an implementation may exclude a Protected Person from accessing a lawful service, exercising a Framework right or using an available interaction route.

6.2. The assessment shall consider:

1. accessibility barriers;

2. identity and Authentication barriers;

3. geographic or infrastructure limitations;

4. language barriers;

5. economic or operational constraints;

6. security measures creating disproportionate exclusion.

6.3. Where a risk of exclusion is identified, the Responsible Actor shall:

1. assess alternatives;

2. implement mitigation where appropriate;

3. document the decision;

4. monitor the outcome.

6.4. A security requirement shall not be removed solely to avoid exclusion where the requirement protects a necessary Assurance or Security Condition.

6.5. A Responsible Actor shall seek proportionate solutions preserving both:

1. inclusion;

2. trust and security requirements.

Article 7: Adverse-effect assessment

7.1. A Responsible Actor shall perform an adverse-effect assessment where an implementation may materially affect a Protected Person.

7.2. The assessment shall identify:

1. affected persons;

2. affected service or process;

3. potential adverse effects;

4. causes and contributing factors;

5. existing safeguards;

6. mitigation measures;

7. responsible Actor;

8. review date.

7.3. Adverse effects may include:

1. exclusion;

2. inability to access a service;

3. incorrect identity association;

4. incorrect Attribute use;

5. inability to correct information;

6. inability to exercise a Review or Remedy Route.

7.4. The Responsible Actor shall document the assessment outcome.

7.5. The assessment shall not determine legal liability or external legal effect.

Article 8: Adverse-effect mitigation

8.1. Where adverse effects are identified, the Responsible Actor shall implement proportionate mitigation.

8.2. Mitigation may include:

1. Accessible Alternatives;

2. additional human review;

3. correction procedures;

4. improved communication;

5. additional verification;

6. process modification.

8.3. Mitigation shall identify:

1. responsible Actor;

2. implementation date;

3. evidence;

4. effectiveness review.

8.4. Repeated adverse effects shall trigger review of:

1. service design;

2. Profile requirements;

3. operational procedures;

4. safeguards.

Article 9: Complaint intake

9.1. A Responsible Actor shall provide a Complaint Route accessible to affected persons.

9.2. The Complaint Route shall identify:

1. submission method;

2. required information;

3. communication method;

4. expected response time;

5. responsible function.

9.3. A complaint shall identify, where available:

1. complainant reference;

2. affected service or process;

3. issue description;

4. supporting information;

5. requested outcome.

9.4. A Responsible Actor shall provide reasonable assistance where a person cannot independently submit a complaint.

9.5. A complaint shall not require unnecessary disclosure of personal or sensitive information.

Article 10: Complaint assessment and handlin

10.1. A Responsible Actor shall assess each complaint within the applicable scope.

10.2. Assessment shall determine:

1. subject matter;

2. affected Controlled Matter;

3. responsible Actor;

4. applicable process;

5. required action.

10.3. A complaint shall be classified as:

1. information request;

2. correction request;

3. Review request;

4. Remedy request;

5. another applicable category.

10.4. The Responsible Actor shall communicate:

1. acknowledgement;

2. assessment result;

3. required next steps;

4. outcome or escalation.

10.5. Complaint handling shall preserve:

1. confidentiality;

2. Integrity;

3. evidence;

4. Accountability.

Article 11: Correction requests

11.1. A Responsible Actor shall provide a Correction Route where inaccurate, incomplete or outdated information affects a Protected Person.

11.2. A Correction Route shall distinguish:

1. correction of an operational record;

2. correction of a derived record;

3. correction request to an authoritative Source;

4. correction of a Trust Object or Trust Service Output.

11.3. A Responsible Actor shall not modify an authoritative Source record unless authorised to do so.

11.4. A correction request shall identify:

1. affected information;

2. requested correction;

3. evidence supporting the request;

4. responsible Actor.

11.5. A correction decision shall identify:

1. action taken;

2. evidence considered;

3. Effective Date;

4. limitations.

11.6. Historical records shall remain identifiable where required for Accountability, Validation or Remedy.

Article 12: Review Routes

12.1. A Responsible Actor shall provide access to the applicable Review Route established by the Main Framework.

12.2. A Review request shall identify:

1. requester;

2. affected matter;

3. contested action or decision;

4. reasons for review;

5. supporting evidence.

12.3. The Review process shall:

1. identify the responsible Review function;

2. consider available evidence;

3. provide an impartial evaluation;

4. record the outcome.

12.4. A Review outcome shall identify:

1. reviewed matter;

2. evidence considered;

3. findings;

4. corrective actions;

5. further Remedy options.

12.5. A Review function shall not exceed its assigned competence.

Article 13: Remedy Routes

13.1. A Responsible Actor shall implement Remedy Routes according to the applicable Framework provisions.

13.2. Remedy may include:

1. correction;

2. restoration of an affected process;

3. additional review;

4. modification of an operational action;

5. other measures permitted by the Framework.

13.3. A Remedy outcome shall identify:

1. affected person;

2. affected matter;

3. remedy measure;

4. responsible Actor;

5. implementation date;

6. evidence.

13.4. Remedy shall be limited to the competence and scope established by the Framework.

13.5. Remedy shall not:

1. assign Status;

2. create Qualified Status;

3. create Authorisation;

4. replace a Framework Decision.

Article 14: Communication with affected persons

14.1. Communication with affected persons shall be:

1. understandable;

2. accessible;

3. proportionate;

4. timely.

14.2. Communication shall identify:

1. the matter concerned;

2. available actions;

3. responsible Actor;

4. applicable timelines;

5. available Review and Remedy Routes.

14.3. Communication shall avoid unnecessary disclosure of:

1. Security-Sensitive Information;

2. Protection-Sensitive Information;

3. third-party confidential information.

Article 15: Records

15.1. A Responsible Actor shall maintain records sufficient to reconstruct:

1. safeguard assessments;

2. accessibility measures;

3. adverse-effect assessments;

4. complaints;

5. correction requests;

6. Review requests;

7. Remedy requests;

8. outcomes and corrective actions.

15.2. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. time;

5. responsible Actor;

6. affected scope.

15.3. Records shall be protected according to applicable Security Conditions.

15.4. Correction of records shall preserve:

1. earlier record;

2. correction basis;

3. responsible Actor;

4. Effective Date.

Article 16: Improvement and monitoring

16.1. A Responsible Actor shall monitor:

1. complaint trends;

2. correction trends;

3. adverse effects;

4. accessibility issues;

5. Review outcomes;

6. Remedy outcomes.

16.2. Monitoring results shall inform:

1. service improvement;

2. safeguard improvement;

3. Profile updates;

4. training;

5. operational changes.

16.3. Repeated adverse effects shall trigger review of the underlying implementation.

16.4. Improvement actions shall identify:

1. responsible Actor;

2. implementation date;

3. evidence;

4. effectiveness review.

Article 17: Reference standards and specifications

17.1. The reference standards applicable to this Guideline are set out in Annex I.

17.2. A reference shall apply only within the implementation function identified in Annex I.

17.3. Exact accessibility interfaces, communication formats and technical support mechanisms shall be defined through applicable Profiles and Technical Specifications.

17.4. Conformity with a referenced standard shall not create:

1. rights;

2. obligations;

3. Status;

4. Qualified Status;

5. Controlled Effects.

Annex I: Reference standards

Reference	Implementation function	Applicability
ISO 10002:2018, Quality management — Customer satisfaction — Guidelines for complaints handling in organizations	Complaint handling processes	Applicable for complaint intake, classification, handling and improvement processes.
ISO 10003:2018, Quality management — Customer satisfaction — Guidelines for dispute resolution external to organizations	External dispute resolution guidance	Applicable where external dispute-resolution mechanisms are implemented.
ISO 9241-171:2008, Ergonomics of human-system interaction — Part 171: Guidance on software accessibility	Software accessibility	Applicable for accessible software interaction design.
ISO 9241-210:2019, Human-centred design for interactive systems	Human-centred design	Applicable for service design affecting Protected Persons.
ISO/IEC 40500:2012, W3C Web Content Accessibility Guidelines 2.0	Web accessibility guidance	Applicable where web-based interfaces are used.
ISO/IEC 30071-1:2019, Information technology — Development of user interface accessibility	Accessibility management	Applicable for accessibility governance and implementation.
ISO/IEC 29184:2020, Online privacy notices and consent	Communication and transparency	Applicable where online privacy communication and consent information are provided.
ISO/IEC 27701:2025, Privacy information management systems	Privacy-related safeguards	Applicable where personal data processing affects Protected Persons.

IDEHA-IG-BIO-GEN-001: Biometric Implementation Controls

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for biometric data processing under the Framework.

1.2. This Guideline shall apply to each Responsible Actor, Identification Service Provider, Authentication Service Provider, Source Holder, Source Steward, Trust Service Provider, Issuer, Relying Actor and supporting Actor processing biometric information within an approved scope.

1.3. This Guideline shall govern, where applicable:

1. biometric modality selection;

2. biometric collection and capture;

3. capture environment requirements;

4. biometric quality assessment;

5. biometric reference creation;

6. biometric template protection;

7. biometric comparison and performance evaluation;

8. presentation attack detection;

9. biometric algorithm governance;

10. demographic performance monitoring;

11. biometric lifecycle management;

12. biometric evidence management;

13. biometric interoperability.

1.4. This Guideline shall not:

1. establish identity;

2. establish legal identity;

3. determine Identity Proofing requirements;

4. create Identification Results;

5. create Authentication Outcomes;

6. establish Source authority;

7. determine whether a person shall be enrolled;

8. define legal grounds for biometric processing;

9. prescribe a mandatory biometric modality for all implementations.

1.5. Identity Registration Records containing biometric information shall be governed by IDEHA-IG-SVC-IDN-001.

1.6. Biometric use as an Authentication factor shall be governed by IDEHA-IG-SVC-AUT-001.

1.7. Biometric information contained within Electronic Attestations shall be governed by IDEHA-IG-SVC-EAS-001 and IDEHA-IG-OBJ-EAA-001.

1.8. Security, Confidentiality, access control and incident requirements shall be governed by IDEHA-IG-SEC-CNF-001 and IDEHA-IG-SEC-INC-001.

1.9. Compliance with this Guideline shall not, by itself, establish identity, Authentication, Authorisation, Status, Qualified Status, Service Permission or Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the operational purpose for biometric processing;

2. the affected persons;

3. the responsible Actors;

4. the permitted biometric use cases;

5. the applicable safeguards.

2.2. The applicable Biometric Profile shall identify:

1. permitted biometric modalities;

2. collection conditions;

3. capture requirements;

4. quality requirements;

5. presentation attack detection requirements;

6. template protection requirements;

7. matching-performance requirements;

8. algorithm governance requirements;

9. retention and deletion conditions;

10. interoperability requirements.

2.3. The applicable Technical Specification shall define:

1. biometric data formats;

2. image or sample encoding;

3. template encoding;

4. compression;

5. biometric exchange structures;

6. technical interfaces;

7. algorithm parameters;

8. testing procedures.

2.4. A biometric reference shall remain separate from:

1. Identity Identifier;

2. Identification Number;

3. Subject Identifier;

4. Trust Object Identifier;

5. Authentication Outcome.

2.5. A biometric comparison result shall not, by itself, establish identity, entitlement or Authorisation.

Article 3: Biometric Implementation Plan

3.1. A Responsible Actor shall maintain a Biometric Implementation Plan where biometric information is collected, stored, compared or reused.

3.2. The Implementation Plan shall identify:

1. biometric purpose;

2. affected persons;

3. responsible Actor;

4. biometric modalities;

5. collection processes;

6. capture environments;

7. storage arrangements;

8. protection mechanisms;

9. matching processes;

10. performance evaluation;

11. retention and deletion;

12. interoperability requirements;

13. incident and compromise handling.

3.3. The Implementation Plan shall distinguish:

1. biometric sample from biometric template;

2. biometric reference from biometric comparison result;

3. biometric matching from identity determination;

4. biometric Authentication from identity registration;

5. biometric protection from Authorisation.

3.4. The Responsible Actor shall review the Implementation Plan following:

1. introduction of a new modality;

2. algorithm change;

3. material performance change;

4. security incident;

5. material lifecycle change.

Section 2: Biometric modality governance

Article 4: Modality selection

4.1. A Responsible Actor shall select biometric modalities according to the intended purpose and operational context.

4.2. Modality selection shall consider:

1. reliability;

2. accessibility;

3. availability;

4. environmental conditions;

5. population characteristics;

6. performance requirements;

7. risk of misuse;

8. interoperability requirements.

4.3. A modality-selection record shall identify:

1. selected modality;

2. purpose;

3. justification;

4. affected population;

5. limitations;

6. review conditions.

4.4. No biometric modality shall be considered universally suitable for all purposes.

4.5. A Responsible Actor shall consider non-biometric or alternative methods where biometric collection may create disproportionate exclusion or adverse effects.

Article 5: Biometric modality lifecycle

5.1. Each biometric modality shall have lifecycle management.

5.2. Lifecycle information shall identify:

1. introduction;

2. approved use cases;

3. applicable algorithms;

4. performance evidence;

5. restrictions;

6. retirement conditions.

5.3. A retired modality shall remain identifiable for Historical State where previously created biometric references require evaluation.

5.4. Retirement of a modality shall include:

1. migration conditions;

2. retention treatment;

3. deletion conditions;

4. interoperability arrangements

Section 3: Collection and capture controls

Article 6: Biometric collection

6.1. Biometric collection shall be performed according to the applicable Biometric Profile.

6.2. Collection shall identify:

1. biometric modality;

2. collection purpose;

3. collection event;

4. collection Actor;

5. collection environment;

6. applicable quality requirements.

6.3. The collection process shall maintain evidence sufficient to establish:

1. when collection occurred;

2. which modality was collected;

3. which equipment was used;

4. which process was applied.

6.4. Collection evidence shall not contain unnecessary biometric content beyond the authorised purpose.

Article 7: Capture environment

7.1. A biometric capture environment shall provide conditions appropriate for the selected modality.

7.2. The capture environment shall consider:

1. lighting;

2. positioning;

3. background conditions;

4. sensor performance;

5. operator assistance;

6. environmental interference.

7.3. The Responsible Actor shall define capture-quality requirements.

7.4. Capture equipment shall be identified and maintained according to the applicable Profile.

7.5. Material changes to capture equipment shall be assessed before continued use.

Article 8: Biometric quality assessment

8.1. Each collected biometric sample shall be assessed according to applicable quality requirements.

8.2. Quality assessment shall consider:

1. completeness;

2. usability;

3. distortion;

4. environmental effects;

5. capture errors;

6. modality-specific characteristics.

8.3. Quality results shall identify:

1. quality assessment method;

2. result;

3. threshold;

4. processing decision.

8.4. A failed quality assessment shall not automatically determine identity failure.

8.5. The applicable Profile shall define whether:

1. recapture;

2. alternative modality;

3. human review;

4. another process

is required.

Section 4: Biometric reference protection

Article 9: Biometric reference creation

9.1. A biometric reference shall be created only within the approved scope.

9.2. A biometric reference record shall identify:

1. reference identifier;

2. biometric modality;

3. creation process;

4. creation time;

5. responsible Actor;

6. algorithm Version;

7. protection method;

8. lifecycle Status.

9.3. A biometric reference identifier shall:

1. remain opaque;

2. not disclose identity information;

3. not encode demographic information;

4. remain separate from Subject Identifiers.

9.4. A biometric reference shall not be considered the biometric source sample.

Article 10: Template protection

10.1. Biometric references shall be protected against:

1. unauthorised access;

2. unauthorised disclosure;

3. unauthorised modification;

4. unauthorised reconstruction;

5. unauthorised reuse.

10.2. Protection mechanisms may include:

1. encryption;

2. transformation;

3. secure storage;

4. access control;

5. template-protection mechanisms.

10.3. A biometric reference shall not be stored in plaintext unless expressly permitted by the applicable Profile.

10.4. A biometric reference shall not be reusable across unrelated purposes without an approved purpose and protection assessment.

10.5. Protection mechanisms shall preserve:

1. performance requirements;

2. interoperability requirements;

3. lifecycle requirements.

Section 5: Biometric comparison and performance

Article 11: Biometric comparison

11.1. A biometric comparison process shall identify:

1. input biometric information;

2. biometric reference used;

3. comparison method;

4. algorithm Version;

5. result;

6. confidence or score where applicable.

11.2. A biometric comparison result shall remain separate from:

1. identity;

2. Authentication;

3. Authorisation.

11.3. Automated biometric comparison shall operate according to approved thresholds and review procedures.

11.4. A comparison failure shall not automatically create adverse consequences without the applicable review or alternative process where required.

Article 12: Performance evaluation

12.1. A Responsible Actor shall evaluate biometric-system performance according to the applicable Profile.

12.2. Performance evaluation shall consider:

1. false match rate;

2. false non-match rate;

3. failure to acquire rate;

4. failure to enrol rate;

5. processing time;

6. population impact.

12.3. Performance evaluation shall identify:

1. dataset or evaluation population;

2. methodology;

3. algorithm Version;

4. testing conditions;

5. limitations.

12.4. Performance results shall not be generalised beyond the evaluated scope.

Article 13: Demographic performance monitoring

13.1. Where biometric systems may produce different performance outcomes across populations, the Responsible Actor shall monitor demographic performance.

13.2. Monitoring shall consider:

1. identified performance differences;

2. possible causes;

3. mitigation measures;

4. accessibility impact.

13.3. Demographic performance monitoring shall respect applicable safeguards and shall not create discriminatory profiling.

13.4. Results shall be used to improve:

1. algorithms;

2. capture processes;

3. training;

4. alternative processes.

Section 6: Presentation attack detection and remote collection

Article 14: Presentation attack detection

14.1. Where biometric presentation attacks create a material risk, the Responsible Actor shall implement presentation attack detection controls.

14.2. Presentation attack detection shall identify:

1. applicable modality;

2. attack classes addressed;

3. detection method;

4. testing evidence;

5. limitations.

14.3. Presentation attack detection shall be evaluated according to the applicable Profile.

14.4. Failure of presentation attack detection shall not automatically determine fraud, identity failure or adverse action without applicable review procedures.

Article 15: Remote biometric collection

15.1. Remote biometric collection shall apply additional controls appropriate to the risk.

15.2. Remote collection controls shall address:

1. device integrity;

2. capture environment uncertainty;

3. presentation attacks;

4. communication protection;

5. evidence collection;

6. operator assistance where required.

15.3. Remote biometric collection shall maintain evidence sufficient to reconstruct:

1. device used;

2. collection time;

3. collection process;

4. quality assessment;

5. outcome.

15.4. Remote collection shall not reduce required Assurance Conditions without an approved Profile condition.

Section 7: Lifecycle, security and records

Article 16: Biometric lifecycle management

16.1. Biometric information lifecycle shall include:

1. collection;

2. quality assessment;

3. reference creation;

4. storage;

5. use;

6. update;

7. restriction;

8. deletion.

16.2. Lifecycle events shall identify:

1. responsible Actor;

2. Effective Date;

3. reason;

4. evidence.

16.3. Biometric information shall not be retained beyond the applicable purpose and Retention conditions.

16.4. Deletion shall address:

1. active storage;

2. backup copies;

3. replicated copies;

4. temporary processing copies.

Article 17: Biometric compromise handling

17.1. A biometric compromise shall be treated as a Security Incident.

17.2. The Responsible Actor shall assess:

1. affected biometric references;

2. affected persons;

3. affected systems;

4. affected purposes;

5. possible misuse.

17.3. Response measures may include:

1. restricting use;

2. replacing protection mechanisms;

3. changing authentication methods;

4. increasing monitoring;

5. notifying affected persons.

17.4. Unlike cryptographic keys, biometric characteristics cannot generally be replaced. The response shall therefore prioritise protection, limitation and alternative safeguards.

Article 18: Records and evidence

18.1. A Responsible Actor shall maintain records sufficient to reconstruct biometric lifecycle.

18.2. Records shall include:

1. modality selection;

2. collection events;

3. capture equipment;

4. quality results;

5. reference creation;

6. algorithm Versions;

7. performance evaluations;

8. presentation attack detection testing;

9. lifecycle changes;

10. deletion evidence.

18.3. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. Version;

5. time;

6. responsible Actor.

18.4. Records shall be protected according to IDEHA-IG-SEC-CNF-001.

Article 19: Reference standards and specifications

19.1. The reference standards applicable to this Guideline are set out in Annex I.

19.2. Standards shall apply only within the implementation function identified in Annex I.

19.3. Exact biometric formats, encodings, algorithms and interface specifications shall be defined through applicable Technical Specifications.

19.4. Conformity with a referenced standard shall not establish identity, Authentication, Authorisation, Status or Controlled Effects.

Annex I: Reference standards

Reference	Implementation function	Applicability
ISO/IEC 2382-37:2022, Information technology — Vocabulary — Biometrics	Biometric terminology	Principal terminology reference.
ISO/IEC 19794 series	Biometric data interchange formats	Applicable where biometric data interchange formats are required.
ISO/IEC 39794 series	Extensible biometric data interchange formats	Applicable where modern extensible biometric formats are selected.
ISO/IEC 30107-1:2023, Presentation attack detection — Part 1: Framework	Presentation attack detection concepts	Applicable for PAD implementation governance.
ISO/IEC 30107-3:2023, Presentation attack detection — Part 3: Testing and reporting	PAD testing and reporting	Applicable where PAD testing is required.
ISO/IEC 29794 series	Biometric sample quality	Applicable for biometric quality assessment.
ISO/IEC 19795-1:2021, Biometric performance testing and reporting — Part 1: Principles and framework	Performance testing methodology	Applicable for biometric performance evaluation.
ISO/IEC 24745:2022, Information security, cybersecurity and privacy protection — Biometric information protection	Biometric template protection	Principal reference for biometric information protection.
ISO/IEC 30136:2018, Performance testing of biometric template protection schemes	Template protection evaluation	Applicable where biometric template protection performance is evaluated.
ISO/IEC 29109 series	Conformance testing methodology for biometric data interchange formats	Applicable where interchange-format conformity testing is required.
ISO/IEC 27001:2022	Security management controls	Applicable through IDEHA-IG-SEC-CNF-001.
ISO/IEC 27701:2025	Privacy information management	Applicable where biometric information processing includes personal data governanc

IDEHA-IG-CHG-GEN-001: Change Control, Versioning, Migration and Transition Implementation

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for controlled change, Version management, migration, transition, compatibility and Historical State preservation under the Framework.

1.2. This Guideline shall apply to each Responsible Actor, Framework Body, Trust Service Provider, Source Holder, Source Steward, Issuer, Relying Actor, supporting Actor and technical operator implementing, operating, maintaining or transitioning a Controlled Matter.

1.3. This Guideline shall govern, where applicable:

1. change identification;

2. change classification;

3. impact assessment;

4. change approval and implementation;

5. Version management;

6. migration planning;

7. transition management;

8. compatibility assessment;

9. deprecation and withdrawal;

10. cessation support;

11. Historical State preservation.

1.4. This Guideline shall not:

1. establish Framework amendment procedures;

2. assign Decision Competence;

3. create or modify Framework rules;

4. assign Status, Qualified Status, Service Permission or Technical Exchange Permission;

5. determine External Legal Status or External Legal Effect;

6. replace security change requirements established by IDEHA-IG-SEC-CNF-001;

7. replace cryptographic migration requirements established by IDEHA-IG-SEC-CRY-001;

8. replace Security Incident-driven changes established by IDEHA-IG-SEC-INC-001;

9. replace qualification reassessment requirements established by IDEHA-IG-ASR-QLF-001.

1.5. A change shall be implemented only within the authority, scope and responsibility assigned by the applicable Framework Instrument.

1.6. A change approval, migration completion, Version release or technical deployment shall not, by itself, create:

1. Authorisation;

2. Status;

3. Qualified Status;

4. Service Permission;

5. Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the governed operational context;

2. the participating Actors;

3. the affected Controlled Matters;

4. the applicable governance and approval routes;

5. the applicable Review and Remedy conditions.

2.2. The applicable Profile shall identify:

1. the change categories;

2. the material-change criteria;

3. the approval conditions;

4. the required impact assessment;

5. the Versioning rules;

6. migration requirements;

7. transition conditions;

8. compatibility requirements;

9. deprecation conditions;

10. evidence requirements.

2.3. The applicable Technical Specification shall define:

1. technical Version identifiers;

2. schema and interface changes;

3. compatibility requirements;

4. migration mechanisms;

5. technical validation procedures;

6. test requirements.

2.4. A change to a Technical Specification shall not automatically change:

1. a Framework rule;

2. a Scheme;

3. a Profile;

4. a Status;

5. a Qualified Scope.

2.5. A later Version shall remain identifiable from the earlier Version for Historical State determination.

Article 3: Change Implementation Plan

3.1. A Responsible Actor shall maintain a Change Implementation Plan for each material change.

3.2. The Change Implementation Plan shall identify:

1. the change owner;

2. the affected Controlled Matter;

3. the reason for change;

4. the current Version;

5. the target Version;

6. the applicable Framework Instruments;

7. the affected Actors;

8. the dependencies;

9. the impact assessment;

10. the migration approach;

11. the transition period;

12. testing requirements;

13. communication requirements;

14. rollback conditions;

15. Historical State treatment.

3.3. The Change Implementation Plan shall distinguish:

1. corrective change from enhancement;

2. emergency change from planned change;

3. technical change from Framework change;

4. migration from replacement;

5. Version update from creation of a new Controlled Matter.

3.4. A Change Implementation Plan shall be reviewed where:

1. scope changes;

2. dependencies change;

3. risks change;

4. implementation timing changes;

5. transition conditions change.

Section 2: Change governance and assessment

Article 4: Change identification and classification

4.1. A Responsible Actor shall classify each proposed change before implementation.

4.2. Change classification shall identify:

1. change identifier;

2. change owner;

3. affected Controlled Matter;

4. affected Version;

5. reason;

6. urgency;

7. impact category;

8. approval route.

4.3. Changes may be classified as:

1. corrective change;

2. preventive change;

3. maintenance change;

4. enhancement change;

5. migration change;

6. emergency change;

7. retirement change.

4.4. A change shall be considered material where it may affect:

1. Service Scope;

2. Qualified Scope;

3. Status;

4. Assurance Conditions;

5. Security Conditions;

6. interoperability;

7. dependencies;

8. Trust Object creation or Validation;

9. Source processing;

10. Protected-Person Safeguards.

4.5. A material change shall undergo impact assessment before implementation.

4.6. A non-material change shall remain recorded according to the applicable Profile.

Article 5: Change impact assessment

5.1. A Responsible Actor shall assess the impact of each material change.

5.2. The impact assessment shall identify:

1. affected Actors;

2. affected Controlled Matters;

3. affected Versions;

4. affected Dependencies;

5. affected Trust Services;

6. affected Trust Objects;

7. affected Sources;

8. affected Technical Exchange Routes;

9. affected Security Conditions;

10. affected Assurance Conditions;

11. affected Qualified Conditions;

12. affected Protected Persons.

5.3. The impact assessment shall consider:

1. security;

2. Confidentiality;

3. Integrity;

4. Authenticity;

5. Availability;

6. interoperability;

7. accessibility;

8. operational continuity;

9. Historical State;

10. Review and Remedy.

5.4. The impact assessment shall identify:

1. required testing;

2. required approvals;

3. required communication;

4. required migration;

5. rollback conditions.

5.5. A change shall not be implemented where the impact assessment identifies an unresolved unacceptable risk unless the applicable exception process permits it.

5.6. A change affecting Qualified Status shall be handled according to IDEHA-IG-ASR-QLF-001.

Article 6: Change approval and implementation

6.1. A material change shall require approval by the Actor or Framework Body holding the applicable responsibility.

6.2. Approval shall identify:

1. approved scope;

2. approved Version;

3. effective date;

4. implementation conditions;

5. testing requirements;

6. rollback conditions.

6.3. Implementation shall occur according to the approved Change Implementation Plan.

6.4. A change shall be verified after implementation.

6.5. Verification shall identify:

1. implemented Version;

2. affected scope;

3. test results;

4. outstanding issues;

5. completion status.

6.6. Implementation evidence shall be retained.

6.7. Successful implementation shall not automatically establish:

1. compliance;

2. qualification;

3. Status;

4. Authorisation.

Those matters require separate evaluation where applicable.

Section 3: Version management and lifecycle

Article 7: Version identification

7.1. Each Framework Instrument, Profile, Technical Specification, Trust Object, Trust Service Output, configuration package, policy package, mechanism, device and material implementation component shall have a Version identifier where required by the applicable Profile.

7.2. A Version identifier shall:

1. uniquely identify the applicable state;

2. remain immutable after publication;

3. support Historical State determination;

4. identify predecessor and successor relationships.

7.3. Version identifiers shall not be reused for materially different content.

7.4. A Version change shall identify:

1. previous Version;

2. new Version;

3. Effective Date;

4. change description;

5. compatibility conditions.

Article 8: Version lifecycle management

8.1. A Version lifecycle shall include, where applicable:

1. draft;

2. approved;

3. active;

4. restricted;

5. deprecated;

6. withdrawn;

7. archived.

8.2. Lifecycle transitions shall identify:

1. responsible Actor;

2. decision basis;

3. Effective Date;

4. affected scope;

5. transition conditions.

8.3. A withdrawn Version shall remain identifiable where required for:

1. Validation;

2. Historical State;

3. Review;

4. Remedy;

5. audit.

8.4. An archived Version shall not be used for new creation unless expressly permitted.

8.5. A deprecated Version shall identify:

1. remaining permitted use;

2. end-of-use date;

3. replacement Version;

4. migration requirements.

Section 4: Migration and transition management

Article 9: Migration planning

9.1. A Responsible Actor shall prepare a migration plan where a change requires movement from one Version, mechanism, system, service or dependency to another.

9.2. The migration plan shall identify:

1. current state;

2. target state;

3. migration scope;

4. affected Actors;

5. affected dependencies;

6. migration sequence;

7. testing;

8. transition period;

9. rollback conditions;

10. completion criteria.

9.3. Migration shall preserve:

1. Accountability;

2. Integrity;

3. Authenticity;

4. Historical State;

5. evidence continuity.

9.4. Migration shall not silently alter:

1. Source authority;

2. Trust Object meaning;

3. Status;

4. Qualified Scope;

5. Controlled Reliance conditions.

Article 10: Transition management

10.1. A transition period may be established where old and new Versions operate together.

10.2. A transition arrangement shall identify:

1. coexistence period;

2. permitted Versions;

3. affected Actors;

4. compatibility rules;

5. security requirements;

6. termination condition.

10.3. During transition, a Responsible Actor shall prevent:

1. unauthorised downgrade;

2. uncontrolled Version mixing;

3. ambiguous interpretation;

4. loss of historical evidence.

10.4. A transition shall define the final condition under which the previous Version is:

1. restricted;

2. deprecated;

3. withdrawn.

10.5. Transition completion shall be recorded.

Article 11: Compatibility management

11.1. A Responsible Actor shall assess compatibility before introducing a new Version.

11.2. Compatibility assessment shall identify:

1. technical compatibility;

2. semantic compatibility;

3. security compatibility;

4. operational compatibility;

5. dependency compatibility.

11.3. A compatible Version shall not automatically be considered equivalent.

11.4. Where semantic meaning changes, a new Version or separate Controlled Matter shall be created.

11.5. Compatibility claims shall identify:

1. tested scope;

2. limitations;

3. supported Versions;

4. unsupported conditions.

Section 5: Deprecation, withdrawal and cessation

Article 12: Deprecation

12.1. A Responsible Actor may deprecate a Version, mechanism, service function or dependency.

12.2. Deprecation shall identify:

1. reason;

2. affected scope;

3. remaining permitted use;

4. replacement;

5. end date.

12.3. Deprecated elements shall not be used for new creation unless expressly permitted.

12.4. Deprecation shall preserve historical Validation capability where required.

Article 13: Withdrawal and cessation

13.1. Withdrawal shall identify:

1. withdrawn element;

2. effective date;

3. affected Actors;

4. replacement arrangements;

5. evidence preservation requirements.

13.2. Cessation shall identify:

1. pending operations;

2. dependent Actors;

3. retained records;

4. transition obligations;

5. final Status.

13.3. Withdrawal or cessation shall not invalidate earlier actions where Historical State requires continued recognition.

13.4. Cessation shall preserve:

1. evidence;

2. Validation capability;

3. Review capability;

4. Remedy capability.

Section 6: Records and Historical State

Article 14: Change records

14.1. A Responsible Actor shall maintain records sufficient to reconstruct change lifecycle.

14.2. Records shall include:

1. change requests;

2. classifications;

3. impact assessments;

4. approvals;

5. implementation evidence;

6. testing results;

7. migration records;

8. transition records;

9. Version history;

10. rollback events;

11. withdrawal records.

14.3. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. Version;

5. time;

6. responsible Actor.

14.4. Records shall be protected according to applicable Security Conditions.

Article 15: Historical State preservation

15.1. A Responsible Actor shall preserve information necessary to determine the state of a Controlled Matter at a previous time.

15.2. Historical State records shall identify:

1. applicable Version;

2. applicable Profile;

3. applicable Technical Specification;

4. applicable Dependencies;

5. applicable Standards;

6. applicable Status;

7. effective period.

15.3. A current Version shall not automatically determine the state of an earlier interaction.

15.4. Migration shall preserve the relationship between:

1. predecessor;

2. successor;

3. transition condition;

4. effective time.

15.5. Historical State information shall remain available for:

1. Validation;

2. Assurance;

3. Conformity Assessment;

4. Review;

5. Remedy.

Section 7: Reference standards

Article 16: Reference standards and specifications

16.1. The reference standards applicable to this Guideline are set out in Annex I.

16.2. Standards shall apply only within the implementation function identified in Annex I.

16.3. Exact Version numbering schemes, technical identifiers, migration formats and interface behaviours shall be defined through applicable Profiles and Technical Specifications.

16.4. Conformity with a referenced standard shall not create:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Controlled Effects.

Annex I: Reference standards

Reference	Implementation function	Applicability
ISO/IEC/IEEE 24748-1:2024, Systems and software engineering — Life cycle management — Part 1: Guide for life cycle management	Lifecycle and transition planning	Applicable for structured lifecycle planning.
ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes	System lifecycle management	Applicable where changes affect complex systems or infrastructure.
ISO/IEC/IEEE 12207:2017, Systems and software engineering — Software life cycle processes	Software lifecycle changes	Applicable for software-related change management.
ISO/IEC 20000-1:2018, Information technology — Service management system requirements	Service change management	Applicable where formal service management processes are implemented.
ISO/IEC 27001:2022, Information security management systems — Requirements	Security-related change governance	Applicable where changes affect information-security management systems.
ISO/IEC 27002:2022, Information security controls	Change-control security controls	Applicable through selected controls identified in the applicable Profile.
ISO/IEC 27005:2022, Information security risk management	Change impact risk assessment	Applicable for change-related risk assessment.
ITIL 4 Change Enablement Practice	Operational change governance guidance	Applicable as supporting operational guidance where adopted by the Responsible Actor.

IDEHA-IG-PUB-HTL-001: Humanitarian Trust List, Status Publication, Registers, Catalogues

Section 1: General provisions

Article 1: Subject matter and scope

1.1. This Guideline lays down implementation requirements for Humanitarian Trust List operation, Status Publication, Registers, Catalogues and federation discovery under the Framework.

1.2. This Guideline shall apply to Framework Bodies, Status Publishers, Trust Service Providers, Responsible Actors, Trust Service operators, Source Holders, Source Stewards, Federation Domain operators, Discovery Metadata operators and supporting Actors responsible for publishing, maintaining, consuming or validating published trust information.

1.3. This Guideline shall govern, where applicable:

1. Humanitarian Trust List publication;

2. Status Publication implementation;

3. Trust Service discovery;

4. Actor and Endpoint discovery;

5. Register management;

6. Catalogue management;

7. federation discovery metadata;

8. publication integrity and authenticity;

9. Status update lifecycle;

10. correction, withdrawal and historical publication;

11. discovery and Validation evidence.

1.4. This Guideline shall not:

1. create Trust Service Categories;

2. create Trust Object Categories;

3. assign Status;

4. assign Qualified Status;

5. make qualification decisions;

6. establish Decision Competence;

7. create Service Permission;

8. create Technical Exchange Permission;

9. create Authorisation;

10. determine Source authority;

11. determine External Legal Status or External Legal Effect.

1.5. The Humanitarian Trust List shall publish authorised Status information and discovery information only.

1.6. Status creation, qualification decisions, Service Permission decisions and Framework Decisions shall remain with the competent Framework Body or responsible Actor identified by the Main Framework.

1.7. Compliance with this Guideline shall not, by itself, establish trust, recognition, Status, Qualified Status, Authorisation or Controlled Reliance.

Article 2: Application through Schemes, Profiles and Technical Specifications

2.1. The applicable Scheme shall identify:

1. the governed trust context;

2. the participating Actors;

3. the Status-Bearing Matters;

4. the applicable Federation Domains;

5. the discovery purposes;

6. the applicable safeguards.

2.2. The applicable Status Publication Profile shall identify:

1. publication scope;

2. Status information categories;

3. publication frequency;

4. update conditions;

5. correction procedures;

6. withdrawal procedures;

7. historical publication requirements;

8. integrity and authenticity requirements.

2.3. The applicable Discovery Profile shall identify:

1. discovery information categories;

2. Actor discovery;

3. Trust Service discovery;

4. Endpoint discovery;

5. Technical Exchange Route discovery;

6. Federation Domain discovery;

7. applicable freshness requirements.

2.4. The applicable Technical Specification shall define:

1. Trust List structure;

2. Register structure;

3. Catalogue structure;

4. discovery metadata formats;

5. publication interfaces;

6. integrity-protection formats;

7. exchange formats;

8. validation procedures.

2.5. A published Entry shall remain separate from:

1. the underlying Framework Decision;

2. the Status-Bearing Matter;

3. the Trust Service operation;

4. the Trust Object;

5. the Source record;

6. the Authorisation decision.

Article 3: Publication Implementation Plan

3.1. A Status Publisher shall maintain a Publication Implementation Plan.

3.2. The Publication Implementation Plan shall identify:

1. the publication scope;

2. responsible Actors;

3. publication functions;

4. Humanitarian Trust List structure;

5. Registers and Catalogues;

6. discovery metadata;

7. publication processes;

8. integrity and authenticity protection;

9. update processes;

10. correction processes;

11. withdrawal processes;

12. historical publication arrangements;

13. evidence and assurance requirements.

3.3. The Publication Implementation Plan shall distinguish:

1. Status decision from Status publication;

2. discovery from Authorisation;

3. publication from Validation;

4. Register entry from Source authority;

5. Catalogue entry from Service Permission.

3.4. The Publication Implementation Plan shall be reviewed following:

1. publication-model changes;

2. Status-model changes;

3. material technical changes;

4. Security Incident;

5. dependency changes.

Section 2: Humanitarian Trust List publication model

Article 4: Humanitarian Trust List purpose and scope

4.1. The Humanitarian Trust List shall provide a trusted publication mechanism for authorised trust information.

4.2. The Humanitarian Trust List may contain:

1. Status information;

2. Trust Service information;

3. Trust Service Provider information;

4. Actor discovery information;

5. Endpoint discovery information;

6. Federation Domain information;

7. Certificate and trust information;

8. publication metadata.

4.3. The Humanitarian Trust List shall identify:

1. the publishing Framework Body or authorised Status Publisher;

2. the publication Version;

3. the Effective Date;

4. the publication period;

5. the applicable Scheme;

6. the applicable Profile.

4.4. The Humanitarian Trust List shall not:

1. create Status;

2. replace a Framework Decision;

3. replace Source records;

4. replace Authorisation;

5. create entitlement.

Article 5: Humanitarian Trust List structure

5.1. The Humanitarian Trust List shall maintain separately identifiable Entries.

5.2. Each Entry shall identify, where applicable:

1. Entry Identifier;

2. Status-Bearing Matter;

3. category;

4. Status;

5. Effective Date;

6. expiry or review date;

7. publication source;

8. applicable scope;

9. restrictions;

10. caveats.

5.3. An Entry shall identify the relationship between:

1. published information;

2. underlying decision;

3. responsible Actor;

4. supporting evidence.

5.4. An Entry shall not include information beyond the authorised publication scope.

5.5. Publication of an Entry shall not transfer responsibility from the responsible Actor to the Status Publisher.

Article 6: Publication integrity and authenticity

6.1. A Humanitarian Trust List publication shall be protected against unauthorised alteration.

6.2. Publication protection shall establish:

1. publication origin;

2. publication Integrity;

3. publication Version;

4. publication time;

5. sequence continuity.

6.3. A Humanitarian Trust List package shall be protected using an Electronic Seal attributable to the authorised publishing Actor.

6.4. Where required by the applicable Profile, publication evidence shall include an Electronic Timestamp.

6.5. Publication protection shall not establish:

1. the correctness of the published Status decision;

2. the authority of the underlying decision;

3. the legality of reliance.

6.6. The receiving Actor shall validate:

1. publication authenticity;

2. publication Integrity;

3. publication Version;

4. Effective Date;

5. Status scope;

6. historical applicability.

Section 3: Status Publication lifecycle

Article 7: Status Publication creation

7.1. Status Publication shall occur only following an authorised Status decision or authorised publication event.

7.2. The publication process shall verify:

1. decision reference;

2. Status-Bearing Matter identity;

3. Status category;

4. Qualified Scope where applicable;

5. Effective Date;

6. restrictions;

7. caveats.

7.3. The Status Publisher shall not modify the substantive decision.

7.4. Publication metadata shall identify:

1. publication Actor;

2. publication time;

3. publication Version;

4. applicable Technical Specification.

Article 8: Status update, correction and withdrawal

8.1. Status updates shall identify:

1. previous Status;

2. new Status;

3. effective time;

4. reason;

5. responsible Actor.

8.2. Corrections shall preserve:

1. original publication;

2. correction basis;

3. correction time;

4. responsible Actor.

8.3. Withdrawal shall identify:

1. withdrawn Entry;

2. effective date;

3. reason;

4. successor Entry where applicable.

8.4. A withdrawn Entry shall remain available where required for:

1. Historical State;

2. Validation;

3. Review;

4. Remedy.

Article 9: Historical Status and publication state

9.1. The Humanitarian Trust List shall preserve historical publication states.

9.2. Historical publication information shall identify:

1. Entry Version;

2. Status at the relevant time;

3. Effective Date;

4. withdrawal or replacement events;

5. applicable publication Version.

9.3. A current Humanitarian Trust List publication shall not automatically determine historical Status.

9.4. Historical publication state shall support:

1. Validation;

2. Assurance;

3. Conformity Assessment;

4. Review;

5. Remedy.

Section 4: Registers and Catalogues

Article 10: Registers

10.1. A Register shall maintain controlled records of recognised Framework objects, Actors, Services or information categories assigned by the applicable Framework Instrument.

10.2. A Register Entry shall identify:

1. Register Identifier;

2. Entry Identifier;

3. responsible Actor;

4. recorded information;

5. Version;

6. lifecycle Status;

7. Effective Date.

10.3. A Register shall maintain:

1. creation;

2. update;

3. correction;

4. withdrawal;

5. historical preservation.

10.4. A Register Entry shall not create:

1. Source authority;

2. Status;

3. Authorisation;

4. Qualification.

Article 11: Catalogues

11.1. A Catalogue shall provide controlled discovery information for recognised items within an assigned scope.

11.2. A Catalogue may contain:

1. Service information;

2. technical capability information;

3. Profile information;

4. Version information;

5. compatibility information.

11.3. A Catalogue Entry shall identify:

1. Catalogue Identifier;

2. Entry Identifier;

3. responsible Actor;

4. Version;

5. Effective Date;

6. lifecycle Status.

11.4. Catalogue information shall remain separate from:

1. Status;

2. Qualification;

3. Authorisation;

4. Source authority.

Section 5: Federation discovery implementation

Article 12: Federation discovery metadata

12.1. Federation discovery metadata shall support discovery of recognised federation participants and technical capabilities.

12.2. Discovery metadata may identify:

1. Actor Identifier;

2. Trust Service Identifier;

3. Endpoint reference;

4. Technical Exchange Route reference;

5. Federation Domain;

6. supported Profiles;

7. supported Technical Specifications;

8. certificate references.

12.3. Discovery metadata shall identify:

1. responsible Actor;

2. publication time;

3. Version;

4. lifecycle Status.

12.4. Discovery metadata shall not establish:

1. access;

2. disclosure permission;

3. Authorisation;

4. Technical Exchange Permission.

12.5. Discovery information shall be validated before use in a controlled exchange context.

Article 13: Address resolution and service discovery

13.1. Where the Humanitarian Trust List provides address-resolution functionality, the resolution process shall identify:

1. requested service;

2. responsible Actor;

3. Endpoint;

4. Technical Exchange Route;

5. applicable Version.

13.2. Address resolution shall use current and validated discovery information.

13.3. Address resolution shall not:

1. bypass Authorisation;

2. bypass Endpoint Authentication;

3. replace Source access decisions;

4. create reliance rights.

13.4. A resolved Endpoint shall remain subject to:

1. Authentication;

2. Authorisation;

3. Security Conditions;

4. exchange policies.

Section 6: Assurance, lifecycle and records

Article 14: Assurance and Conformity Assessment

14.1. A Status Publisher shall maintain evidence sufficient to demonstrate:

1. publication processes;

2. integrity protection;

3. authenticity protection;

4. lifecycle management;

5. correction procedures;

6. historical preservation.

14.2. Assurance and Conformity Assessment shall be performed according to IDEHA-IG-ASR-QLF-001 where applicable.

14.3. Positive Conformity Assessment shall not create Status.

14.4. Publication integrity shall not replace the underlying Framework Decision.

Article 15: Records and evidence

15.1. A Status Publisher shall maintain records sufficient to reconstruct:

1. publication events;

2. Status updates;

3. corrections;

4. withdrawals;

5. discovery metadata changes;

6. Register changes;

7. Catalogue changes.

15.2. Records shall preserve:

1. Integrity;

2. Authenticity;

3. provenance;

4. Version;

5. time;

6. responsible Actor.

15.3. Records shall be protected according to IDEHA-IG-SEC-CNF-001.

15.4. Correction of records shall preserve:

1. earlier record;

2. correction basis;

3. responsible Actor;

4. Effective Date.

Article 16: Reference standards and specifications

16.1. The reference standards applicable to this Guideline are set out in Annex I.

16.2. Standards shall apply only within the implementation function identified in Annex I.

16.3. Exact publication structures, metadata formats, interfaces and validation procedures shall be defined through applicable Technical Specifications.

16.4. Conformity with a referenced standard shall not create:

1. Status;

2. Qualified Status;

3. Service Permission;

4. Controlled Effects.

Annex I: Reference standards

Reference	Implementation function	Applicability
ETSI TS 119 612 V2.3.1, Trusted Lists	Trusted List structure and publication model	Applicable as the baseline reference for trusted-list structure and publication semantics.
ETSI TS 119 615 V1.1.1, Trusted Lists — Protocols for obtaining trusted lists	Trusted List access and retrieval	Applicable where trusted-list retrieval protocols are implemented.
ETSI EN 319 102-1, Electronic Signatures and Trust Infrastructures — Procedures for signature validation	Validation of signed publication objects where applicable	Applicable where validation processes depend on signed trust information.
RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile	Certificate validation dependencies	Applicable where Certificates support publication authenticity or discovery identity.
ISO/IEC 9594-8:2020, Information technology — Open Systems Interconnection — The Directory — Part 8: Public-key and attribute certificate frameworks	Directory and certificate-related discovery concepts	Applicable as a supporting reference where directory-style discovery is implemented.
ISO/IEC 27001:2022, Information security management systems — Requirements	Publication security governance	Applicable through IDEHA-IG-SEC-CNF-001.
ISO/IEC 27002:2022, Information security controls	Publication security controls	Applicable through selected controls identified in the applicable Profile.
ISO 15489-1:2016, Records management	Publication records and lifecycle evidence	Applicable for publication record managemen

IDEHA-IG-SVC-IDN-001 Identification Service Identity Verification and Proofing Implementation

Section 1: General Provisions

Article 1: Subject matter and scope

1. This Guideline lays down implementation requirements for Identity Verification and Identity Proofing performed by a Trust Service Provider providing an Identification Service.

2. This Guideline applies to Trust Service Providers providing Identification Services and Actors performing, supporting or relying upon Identity Verification within an assigned Service Scope.

3. This Guideline establishes requirements for:

1. evaluation of Evidence Artefacts;

2. assessment of Evidence Strength;

3. assessment of Evidence Validity;

4. Identity Existence Assessment;

5. Identity Fraud Risk Assessment;

6. Identity Verification determination;

7. application of Identification Assurance Profiles;

8. creation of Identification Results.

4. This Guideline applies together with:

1. the applicable Identification Service Profile;

2. IDEHA-IG-SRC-ASO-001 Source and Authoritative Source Implementation;

3. IDEHA-IG-DAT-SEM-001 Controlled Data Elements, Semantics and Data Quality Implementation;

4. IDEHA-IG-BIO-GEN-001 Biometric Implementation Controls;

5. IDEHA-IG-RMR-GEN-001 Protected-Person Safeguards, Complaint, Correction, Review and Remedy Implementation.

5. This Guideline does not establish:

1. Identity Registration Record structure;

2. Identification Number allocation;

3. Identity Registration lifecycle;

4. Authentication Service requirements;

5. Authorisation Service requirements;

6. Electronic Attestation issuance requirements;

7. biometric technical specifications;

8. technical document formats, interfaces or protocols.

6. Identity Verification performed under this Guideline shall support the Identification Service functions assigned through the applicable Framework Instruments.

7. Identity Verification shall not determine substantive humanitarian, administrative, programme or operational decisions unless such determination is separately assigned through an applicable Framework Instrument.

Article 2: Identification Service Identity Verification model

1. Identity Verification is a function performed within an Identification Service through which a Trust Service Provider evaluates whether available information and Evidence Artefacts provide sufficient confidence that a Claimed Identity Representation relates to the Subject.

2. Identity Verification shall be performed against the applicable Identification Assurance Profile.

3. Identity Verification shall evaluate:

1. the Claimed Identity Representation;

2. Evidence Artefacts;

3. Source Basis where applicable;

4. identity-related Attributes;

5. biometric information where applicable;

6. identity fraud indicators;

7. applicable Assurance Conditions.

4. Identity Verification shall consist of the following assessment functions:

1. Evidence Strength Assessment;

2. Evidence Validity Assessment;

3. Identity Existence Assessment;

4. Identity Fraud Risk Assessment;

5. Identity Verification Assessment.

5. The Identification Service shall determine an Identification Assurance Level based on the applicable Identification Assurance Profile.

6. The result of Identity Verification shall be recorded as an Identification Result.

7. Identity Verification shall not:

1. create an Identity Registration Record;

2. allocate an Identification Number;

3. perform Authentication;

4. perform Authorisation;

5. determine eligibility or entitlement.

Article 3: Claimed Identity Representation

1. A Claimed Identity Representation is information presented or referenced for the purpose of establishing an identification basis concerning a Subject.

2. A Claimed Identity Representation may include:

1. biographic information;

2. demographic information;

3. biometric information;

4. Identifier references;

5. Identification Document references;

6. relationship information;

7. other identity-related information permitted by the applicable Identification Profile.

3. A Claimed Identity Representation shall be evaluated against:

1. Evidence Artefacts;

2. Source Basis where applicable;

3. applicable Assurance Conditions.

4. A Claimed Identity Representation shall not be considered verified solely because:

1. the information is internally consistent;

2. the information is self-asserted;

3. the information is obtained through an unauthenticated source.

5. A Claimed Identity Representation shall remain separate from:

1. Identity Registration Record;

2. Identification Result;

3. Authentication Outcome;

4. Authorisation Outcome.

Section 2: Evidence Evaluation

Article 4: Evidence Artefacts

1. An Evidence Artefact is information or an object evaluated by an Identification Service to support Identity Verification.

2. Evidence Artefacts may include:

1. Identification Document Evidence;

2. civil registration evidence;

3. Electronic Attestation Evidence;

4. Source records;

5. biometric evidence;

6. demographic evidence;

7. relationship evidence;

8. institutional evidence;

9. historical evidence.

3. The applicable Identification Assurance Profile shall define the permitted Evidence Artefact categories and minimum requirements.

4. Each Evidence Artefact shall be evaluated according to:

1. origin;

2. integrity;

3. authenticity;

4. validity;

5. relevance;

6. freshness;

7. relationship to the Subject.

5. The Identification Service shall record the Evidence Artefacts evaluated during Identity Verification.

6. An Evidence Artefact shall not by itself:

1. establish an Identity Registration Record;

2. establish Authentication;

3. establish Authorisation;

4. create Source Status;

5. create Authoritative Source Status.

7. Evidence Artefacts shall remain attributable to their originating Source, Issuer or responsible Actor.

Article 5: Evidence Strength Assessment

1. Evidence Strength Assessment shall determine the strength of an Evidence Artefact for the purpose of Identity Verification.

2. Evidence Strength Assessment shall consider:

1. information contained within the Evidence Artefact;

2. uniqueness of information;

3. resistance to alteration or duplication;

4. security features;

5. issuance controls;

6. identity binding performed during issuance;

7. cryptographic protection where applicable.

3. Evidence Strength shall be assessed according to the following levels:

1. Level 1: Basic Evidence;

2. Level 2: Verified Evidence;

3. Level 3: Strong Evidence;

4. Level 4: Very Strong Evidence.

4. The applicable Identification Assurance Profile shall define the minimum Evidence Strength required for each Identification Assurance Level.

5. Evidence Strength shall be assessed separately for each Evidence Artefact.

6. The existence of a higher-strength Evidence Artefact shall not remove the requirement to assess Evidence Validity.

Article 6: Evidence Validity Assessment

1. Evidence Validity Assessment shall determine whether an Evidence Artefact is genuine, valid and suitable for the intended Identity Verification purpose.

2. Evidence Validity Assessment shall consider:

1. authenticity;

2. integrity;

3. validity period;

4. Status information;

5. alteration or substitution indicators;

6. physical security features;

7. cryptographic security features where applicable.

3. Where an Evidence Artefact originates from a Source or Issuer, the Identification Service shall evaluate the applicable Source Basis or Issuer information.

4. The applicable Identification Assurance Profile shall define:

1. validity checks;

2. permitted verification methods;

3. escalation conditions;

4. human review requirements.

5. Evidence Validity Assessment shall remain separate from:

1. Subject identity determination;

2. Authentication;

3. Authorisation.

Article 7: Identity Existence Assessment

1. Identity Existence Assessment shall determine whether available information demonstrates continuity or existence of the Claimed Identity Representation over an identified period where required by the applicable Identification Assurance Profile.

2. Identity Existence Assessment may consider:

1. historical Source information;

2. records maintained by recognised organisations;

3. lifecycle events;

4. previous verified interactions;

5. historical Evidence Artefacts.

3. Identity Existence Assessment shall evaluate whether available information demonstrates continuity associated with the Claimed Identity Representation.

4. Identity Existence Assessment shall not determine:

1. eligibility;

2. entitlement;

3. programme participation;

4. legal status.

5. The applicable Identification Assurance Profile shall define:

1. when Identity Existence Assessment is required;

2. acceptable evidence;

3. assessment period;

4. minimum conditions.

Section 2: Evidence Evaluation

Article 8: Identity Fraud Risk Assessment

1. Identity Fraud Risk Assessment shall determine whether indicators exist that the Claimed Identity Representation may not relate to the Subject presenting or associated with that representation.

2. Identity Fraud Risk Assessment shall consider, where applicable:

1. conflicting identity information;

2. inconsistent Evidence Artefacts;

3. duplicate identity indicators;

4. synthetic identity indicators;

5. impersonation indicators;

6. presentation attack indicators;

7. unusual identity lifecycle patterns;

8. other indicators identified by the applicable Identification Assurance Profile.

3. Identity Fraud Risk Assessment shall evaluate risk indicators and shall not determine:

1. fraud;

2. misconduct;

3. liability;

4. criminal responsibility.

4. Where Identity Fraud Risk Assessment identifies material uncertainty or elevated risk, the Identification Service shall apply the applicable Identification Assurance Profile requirements.

5. Additional measures may include:

1. additional Evidence Artefacts;

2. additional Source Basis evaluation;

3. biometric assessment;

4. human review;

5. another Identification Verification method.

6. The outcome of Identity Fraud Risk Assessment shall be recorded as part of the Identity Verification assessment evidence.

Section 3: Identity Verification Determination

Article 9: Identity Verification Assessment

1. Identity Verification Assessment shall determine whether the evaluated information satisfies the requirements of the applicable Identification Assurance Profile.

2. Identity Verification Assessment shall consider:

1. Evidence Strength Assessment;

2. Evidence Validity Assessment;

3. Identity Existence Assessment where applicable;

4. Identity Fraud Risk Assessment;

5. biometric evidence assessment where applicable;

6. Source Basis;

7. applicable Assurance Conditions.

3. The Identification Service shall record:

1. Evidence Artefacts evaluated;

2. assessment methods applied;

3. Identification Assurance Profile applied;

4. resulting Identification Assurance Level;

5. limitations and caveats;

6. human review activities where applicable.

4. Identity Verification Assessment shall result in:

1. an Identification Result satisfying the applicable Assurance Conditions; or

2. a determination that the applicable Assurance Conditions have not been satisfied.

5. Where the applicable Assurance Conditions are not satisfied, the Identification Service shall record the reason and applicable next steps.

6. An Identity Verification Assessment shall not:

1. create an Identity Registration Record;

2. allocate an Identification Number;

3. establish Authentication;

4. establish Authorisation.

Article 10: Identification Assurance Levels

1. Identification Assurance Levels shall define the confidence achieved through the Identity Verification process.

2. The Identification Assurance Levels are:

1. Low Assurance;

2. Substantial Assurance;

3. High Assurance;

4. Very High Assurance.

3. Each Identification Assurance Level shall be implemented through an Identification Assurance Profile established in Annex III.

4. An Identification Assurance Profile shall define the minimum conditions required for the corresponding Identification Assurance Level.

5. Identification Assurance Levels shall be determined based on:

1. Evidence Strength;

2. Evidence Validity;

3. Identity Existence Assessment where applicable;

4. Identity Fraud Risk Assessment;

5. biometric evidence assessment where applicable;

6. human review conditions where applicable.

6. An Identification Assurance Level shall apply only to the Identification Result produced by the Identification Service.

7. An Identification Assurance Level shall not transfer to:

1. Authentication Outcomes;

2. Authorisation Outcomes;

3. Sources;

4. Evidence Artefacts;

5. Trust Objects;

6. Electronic Attestations.

Article 11: Identification Verification Profiles

1. An Identification Verification Profile shall define the implementation conditions applicable to an Identification Assurance Level.

2. An Identification Verification Profile shall specify:

1. intended purpose;

2. applicable Identification Assurance Level;

3. permitted Evidence Artefact categories;

4. minimum Evidence Strength requirements;

5. minimum Evidence Validity requirements;

6. Identity Existence Assessment requirements;

7. Identity Fraud Risk Assessment requirements;

8. biometric evidence requirements where applicable;

9. Source Basis requirements;

10. human review requirements;

11. Accessible Alternative requirements;

12. limitations and caveats.

3. Identification Verification Profiles shall be established in Annex III.

4. An Identification Verification Profile shall not:

1. create a new Identification Service category;

2. establish Authentication requirements;

3. establish Authorisation requirements;

4. assign Source Status;

5. assign Authoritative Source Status;

6. assign Qualified Status.

5. The Identification Service shall apply the Identification Verification Profile corresponding to:

1. the intended purpose;

2. the required Identification Assurance Level;

3. the applicable Scheme and Service Scope.

6. A Trust Service Provider providing an Identification Service shall not apply an Identification Verification Profile providing a lower Assurance Level than required by the applicable Framework Instrument.

Section 4: Identification Verification Implementation Conditions

Article 12: Remote Identity Verification

1. A Trust Service Provider providing remote Identity Verification shall apply the requirements established by the applicable Remote Identity Verification Profile.

2. Remote Identity Verification shall ensure that:

1. the Subject presenting the Evidence Artefact is associated with the Claimed Identity Representation;

2. the Evidence Artefact presented is genuine;

3. the Evidence Artefact has not been altered or substituted;

4. the communication channel satisfies applicable Security Conditions;

5. manipulation and replay risks are evaluated.

3. Remote Identity Verification may include:

1. remote examination of Identification Document Evidence;

2. cryptographic verification of electronic document features;

3. biometric comparison;

4. live interaction;

5. Source verification;

6. other methods permitted by the applicable Identification Verification Profile.

4. Remote Identity Verification shall apply controls against:

1. presentation attacks;

2. injection attacks;

3. replay attacks;

4. synthetic representations;

5. unauthorised substitution.

5. Where automated remote Identity Verification cannot establish sufficient confidence, the Identification Service shall apply:

1. additional Evidence Artefacts;

2. human review;

3. an Accessible Alternative;

4. another permitted Identification Verification route.

6. Remote Identity Verification shall not rely solely on:

1. a copied image of an Evidence Artefact;

2. self-asserted identity information;

3. an unverified contact point;

4. an isolated biometric comparison result.

Section 4: Identification Verification Implementation Conditions

Article 13: Biometric Evidence Assessment

1. Where biometric information is used during Identity Verification, the Identification Service shall apply the requirements established by the applicable Biometric Profile.

2. Biometric Evidence Assessment shall determine whether biometric information provides appropriate support for the applicable Identification Assurance Level.

3. Biometric Evidence Assessment shall consider:

1. biometric modality;

2. biometric sample quality;

3. biometric reference source;

4. biometric comparison purpose;

5. presentation attack risks;

6. protection of biometric information;

7. applicable Security Conditions.

4. The Identification Service shall distinguish between:

1. biometric sample;

2. biometric reference;

3. biometric template;

4. biometric quality result;

5. biometric comparison result;

6. biometric decision result.

5. A biometric comparison result shall not, by itself:

1. establish identity;

2. create an Identity Registration Record;

3. create an Authentication Outcome;

4. create an Authorisation Outcome.

6. Biometric information shall be processed according to:

1. the applicable Biometric Profile;

2. applicable Security Conditions;

3. applicable Protected-Person Safeguards;

4. applicable retention and lifecycle requirements.

7. Technical requirements concerning:

1. biometric data formats;

2. biometric encoding;

3. biometric algorithms;

4. biometric capture conditions;

5. biometric performance thresholds;

6. presentation attack detection implementation shall be established through the applicable Technical Specification.

Article 14: Source Basis and Authoritative Source reliance

1. Where Identity Verification relies upon information originating from a Source, the Identification Service shall identify the applicable Source Basis.

2. The Source Basis shall identify, where applicable:

1. Source Identifier;

2. Source Scope;

3. relevant Attribute or record category;

4. Source Status;

5. Authoritative Source Status where applicable;

6. Qualified Authoritative Source Status where applicable;

7. time of evaluation;

8. applicable restrictions and limitations.

3. A Trust Service Provider providing an Identification Service shall rely on Source information only within:

1. the recognised Source Scope;

2. the applicable Source Profile;

3. the permitted purpose;

4. the applicable Reliance Conditions.

4. Authoritative Source Status shall not be assumed solely because:

1. information originates from a public authority;

2. information is stored in a recognised system;

3. information is frequently relied upon;

4. information is transmitted through a recognised Technical Exchange Route.

5. A Source Basis shall remain separate from:

1. an Identification Result;

2. an Identity Registration Record;

3. an Authentication Outcome;

4. an Authorisation Outcome.

6. Where multiple Sources provide conflicting information, the Identification Service shall apply the conflict-resolution requirements established by the applicable Identification Verification Profile.

7. Resolution of conflicting Source information shall not alter Source Status unless determined through the applicable Framework Decision route.

Section 5: Safeguards and Identification Results

Article 15: Human review and Protected-Person Safeguards

1. The Identification Service shall provide human review where required by the applicable Identification Verification Profile.

2. Human review shall be required where:

1. automated evaluation cannot produce a reliable result;

2. Evidence Artefacts contain unresolved conflicts;

3. Identity Fraud Risk Assessment identifies material uncertainty;

4. biometric evaluation produces an unresolved result;

5. a Protected-Person Safeguard requires additional consideration;

6. the Subject requests review through an applicable Review Route.

3. Human review shall consider:

1. Evidence Artefacts;

2. assessment results;

3. Source Basis;

4. limitations and uncertainty;

5. applicable Safeguards.

4. The Identification Service shall ensure that:

1. inability to satisfy one Identity Verification route does not automatically result in exclusion;

2. Accessible Alternatives are available where required;

3. Correction Routes are available;

4. Review Routes are available;

5. Remedy Routes are available.

5. A negative Identity Verification result shall not, by itself:

1. establish fraud;

2. establish misconduct;

3. establish ineligibility;

4. remove rights or access outside the Identification Service scope.

6. Where Identity Verification may produce an Adverse Protected-Person Effect, the Identification Service shall apply the safeguards established by the applicable Scheme or Profile.

7. Human review shall not replace the requirement for sufficient evidence, applicable Security Conditions or Assurance Conditions.

Article 16: Identification Result

1. An Identification Result shall record the outcome of Identity Verification performed by an Identification Service.

2. An Identification Result shall identify or reference:

1. the Trust Service Provider;

2. the Identification Service;

3. the Subject or Claimed Identity Representation;

4. the applied Identification Verification Profile;

5. the Identification Assurance Level;

6. Evidence Artefacts evaluated;

7. Source Basis where applicable;

8. assessment time;

9. validity conditions;

10. limitations and caveats.

3. The Identification Result shall contain sufficient information to determine the basis of the Identity Verification outcome.

4. An Identification Result may be used as an input to:

1. Identity Registration;

2. Authentication Services;

3. Authorisation Services;

4. Electronic Attestation Services;

5. other permitted Trust Service functions.

5. Use of an Identification Result by another Trust Service shall remain subject to:

1. applicable Reliance Conditions;

2. the receiving Actorʼs Trust Acceptance Policy;

3. applicable Assurance Conditions.

6. An Identification Result shall not:

1. create an Identity Registration Record;

2. allocate an Identification Number;

3. authenticate a Subject;

4. authorise an action;

5. establish eligibility or entitlement.

7. Where an Identification Result is represented as an Electronic Attestation, the resulting Electronic Attestation shall constitute a separate Trust Object.

Article 17: Records and evidence

1. A Trust Service Provider providing an Identification Service shall maintain records sufficient to reconstruct the Identity Verification process.

2. Records shall include, where applicable:

1. Claimed Identity Representation;

2. Evidence Artefacts evaluated;

3. Evidence Strength Assessment;

4. Evidence Validity Assessment;

5. Identity Existence Assessment;

6. Identity Fraud Risk Assessment;

7. Identity Verification Assessment;

8. applied Identification Verification Profile;

9. Identification Assurance Level;

10. Source Basis;

11. Identification Result;

12. human review activities;

13. Correction, Review and Remedy actions.

3. Records shall enable determination of the basis of an Identification Result at the relevant time.

4. Records shall be protected according to applicable:

1. Security Conditions;

2. Confidentiality requirements;

3. retention requirements;

4. Protected-Person Safeguards.

5. Records shall not contain information beyond the scope required for the Identity Verification purpose.

Section 6: Standards and Technical References

Article 18: Applicable standards

1. The standards applicable to this Guideline are set out in Annex V.

2. A standard referenced in Annex V shall apply only for the implementation function identified in that Annex.

3. Conformity with a referenced standard shall constitute evidence only for the requirements mapped to that standard.

4. A referenced standard shall not create:

1. Identification Service Status;

2. Trust Service Provider Status;

3. Authoritative Source Status;

4. Qualified Status;

5. Controlled Effects.

Annex I: Evidence Strength Matrix

1. General requirements

1. The Evidence Strength Matrix defines the criteria used to determine the strength of an Evidence Artefact for Identity Verification.

2. Evidence Strength shall be assessed separately for each Evidence Artefact.

3. Evidence Strength shall be determined based on the characteristics of the Evidence Artefact and the assurance of the process through which the Evidence Artefact was created, issued or maintained.

4. The Evidence Strength Matrix shall be applied together with:

1. the Evidence Validity Matrix;

2. the applicable Identification Assurance Profile;

3. the applicable Source Basis requirements.

2. Evidence Strength Level 1: Basic Evidence

An Evidence Artefact may achieve Level 1 where it contains sufficient information to establish a basic identification reference.

The assessment may consider:

Requirement	Description
Identity information	Contains one or more identity-related Attributes
Identifier information	Contains an Identifier or reference number where applicable
Personal information	Contains basic biographic or demographic information
Origin	Issued or provided by an identifiable Actor
Availability	Can be presented or accessed for evaluation

Level 1 Evidence does not provide strong assurance that:

1. the Evidence Artefact has strong resistance against alteration;

2. the Evidence Artefact was issued following strong identity proofing;

3. the Evidence Artefact remains valid at the time of evaluation.

3. Evidence Strength Level 2: Verified Evidence

An Evidence Artefact may achieve Level 2 where it satisfies Level 1 and includes additional controls.

The assessment may consider:

Requirement	Description
Unique association	Contains information uniquely associated with the Subject
Issuance process	Issuer applied identity-related verification controls
Protection features	Contains physical or digital protection features
Issuer recognition	Issuer can be identified and verified
Controlled issuance	Issuance process applies defined controls

Level 2 Evidence provides increased confidence but does not necessarily provide strong Subject binding.

4. Evidence Strength Level 3: Strong Evidence

An Evidence Artefact may achieve Level 3 where it satisfies Level 2 and includes stronger identity binding.

The assessment may consider:

Requirement	Description
Strong identity binding	Issuer verified the relationship between Subject and Evidence Artefact
Secure issuance	Issuance process applies enhanced identity verification
Protected representation	Physical or cryptographic protection prevents unauthorised alteration
Subject association	Evidence includes photograph, biometric reference or equivalent binding information
Integrity protection	Integrity can be verified

Level 3 Evidence provides strong confidence that the Evidence Artefact relates to the identified Subject.

5. Evidence Strength Level 4: Very Strong Evidence

An Evidence Artefact may achieve Level 4 where it satisfies Level 3 and provides the highest available identity binding.

The assessment may consider:

Requirement	Description
Biometric binding	Includes biometric information linked to the Subject
Cryptographic protection	Digital information is protected using cryptographic mechanisms
Verified issuer	Issuing organisation can be cryptographically verified
Authoritative comparison	Issuer compared the Subject against authoritative identity information
Controlled issuance	Issuance process provides very high confidence

Level 4 Evidence provides the highest Evidence Strength available under this Guideline.

Annex II: Evidence Validity Matrix

1. General requirements

1. The Evidence Validity Matrix defines the controls used to determine whether an Evidence Artefact is genuine, valid and suitable for Identity Verification.

2. Evidence Validity Assessment shall consider the state of the Evidence Artefact at the time of evaluation.

3. The applicable Identification Assurance Profile shall define the minimum Evidence Validity Level required.

2. Evidence Validity Level 1: Basic Validity

The evaluator shall determine whether:

1. the Evidence Artefact appears consistent;

2. required information is present;

3. obvious alteration indicators are absent;

4. the representation corresponds to the expected format.

3. Evidence Validity Level 2: Verified Validity

The evaluator shall determine whether:

1. Level 1 conditions are satisfied;

2. visible security features appear genuine;

3. validity period remains applicable;

4. available issuer information can be confirmed;

5. the Evidence Artefact has not been visibly altered.

4. Evidence Validity Level 3: Strong Validity

The evaluator shall determine whether:

1. Level 2 conditions are satisfied;

2. advanced security features are verified;

3. replay or substitution risks are addressed;

4. cryptographic protection is validated where available;

5. issuer validation information remains valid.

5. Evidence Validity Level 4: Very Strong Validity

The evaluator shall determine whether:

1. Level 3 conditions are satisfied;

2. advanced physical security features are verified;

3. cryptographic security features are validated;

4. issuer authenticity is confirmed;

5. controlled evaluation conditions are applied where required.

Annex III: Identification Assurance Profiles

1. General requirements

1. Identification Assurance Profiles define the evidence and assessment combinations required to achieve an Identification Assurance Level.

2. Each Identification Assurance Profile shall identify:

1. purpose;

2. required Evidence Strength;

3. required Evidence Validity;

4. Identity Existence requirements;

5. Identity Fraud Risk Assessment requirements;

6. biometric requirements;

7. human review requirements;

8. Accessible Alternative requirements.

2. Low Assurance Identification Profile

IDEHA-IDV-L

Purpose:

Identity Verification where limited assurance is sufficient and where the consequences of incorrect identification are limited.

Minimum conditions:

Condition	Requirement
Evidence Strength	Level 1 or above
Evidence Validity	Level 1 or above
Identity Existence	Optional
Fraud assessment	Required
Human review	According to risk
Biometric evidence	Optional

Limitations:

1. shall not be used where High Assurance or Very High Assurance is required;

2. shall not support Controlled Reliance requiring stronger assurance.

3. Substantial Assurance Identification Profile

IDEHA-IDV-S

Purpose:

Identity Verification requiring increased confidence and controlled reuse.

Minimum conditions:

Condition	Requirement
Evidence Strength	Level 2 or above
Evidence Validity	Level 2 or above
Identity Existence	Required where defined
Fraud assessment	Required
Human review	Risk-based
Source Basis	Required where Source information is used

Annex III: Identification Assurance Profiles

4. High Assurance Identification Profile

IDEHA-IDV-H

Purpose:

Identity Verification where a high level of confidence is required and where incorrect identification may create material adverse consequences.

Minimum conditions:

Condition	Requirement
Evidence Strength	Level 3 or above
Evidence Validity	Level 3 or above
Identity Existence	Required
Fraud assessment	Required
Source Basis	Required where Source information is used
Biometric evidence	Required where defined by the applicable purpose
Human review	Required for unresolved conflicts or elevated risk

Evidence requirements:

1. at least one Strong Evidence Artefact;

or

2. multiple independent Evidence Artefacts meeting the applicable combination rules.

The Identification Service shall verify:

1. the relationship between the Evidence Artefacts and the Subject;

2. the validity of the Evidence Artefacts;

3. the applicable Source Basis;

4. the absence of unresolved material conflicts.

The Identification Result shall contain:

1. applied Identification Profile;

2. High Assurance Identification Level;

3. evaluated Evidence Artefacts;

4. assessment results;

5. limitations and caveats.

Restrictions:

1. shall not be reduced to lower assurance evidence where High Assurance is required;

2. shall apply additional safeguards where Protected-Person risks exist.

5. Very High Assurance Identification Profile

IDEHA-IDV-VH

Purpose:

Identity Verification where the highest level of confidence is required and where incorrect identification may create significant adverse consequences.

Minimum conditions:

Condition	Requirement
Evidence Strength	Level 4
Evidence Validity	Level 4
Identity Existence	Required
Fraud assessment	Required
Source Basis	Required where Source information is used
Biometric evidence	Required where applicable
Human review	Required where automated evaluation is insufficient

Evidence requirements:

The Identification Service shall use:

1. Very Strong Evidence Artefacts;

2. authoritative Source information where applicable;

3. cryptographically protected evidence where available;

4. biometric or equivalent Subject binding where required.

The Identification Service shall verify:

1. Evidence Artefact authenticity;

2. Evidence Artefact integrity;

3. issuer or Source authenticity;

4. Subject association;

5. lifecycle validity;

6. fraud risk indicators.

Very High Assurance shall require enhanced controls for:

1. evidence collection;

2. evidence evaluation;

3. human review;

4. auditability;

5. record preservation.

Restrictions:

1. shall only be used where justified by the intended purpose;

2. shall not become the default requirement for all Identification Services;

3. shall apply Protected-Person Safeguards and Accessible Alternatives where required.

Annex IV: Evidence Artefact Catalogue

1. General requirements

1. The Evidence Artefact Catalogue identifies categories of Evidence Artefacts that may be evaluated during Identity Verification.

2. The Catalogue does not establish that an Evidence Artefact satisfies a particular Assurance Level.

3. The applicable Identification Assurance Profile shall determine whether an Evidence Artefact category may be used and the required Evidence Strength and Evidence Validity.

2. Identification Document Evidence

Identification Document Evidence includes documents issued by recognised Actors for the purpose of identifying a Subject.

Examples include:

Category	Examples
National identification documents	National identity documents issued by recognised authorities
Travel identification documents	Machine-readable travel documents where applicable
Functional identification documents	Documents issued for specific recognised functions
Humanitarian identification documents	Documents issued within recognised humanitarian identification processes

Assessment shall consider:

1. issuing Actor;

2. issuance process;

3. security features;

4. validity period;

5. Subject association;

6. lifecycle Status.

3. Civil Registration Evidence

Civil Registration Evidence includes records maintained by recognised civil registration Sources.

Examples include:

Category	Examples
Birth registration evidence	Evidence establishing birth-related information
Death registration evidence	Evidence establishing death-related information
Family relationship evidence	Evidence establishing recognised relationships

Assessment shall consider:

1. Source Status;

2. Source Scope;

3. provenance;

4. correction processes;

5. freshness.

4. Electronic Attestation Evidence

Electronic Attestation Evidence includes Electronic Attestations issued by recognised Attestation Issuers.

Assessment shall consider:

1. Attestation Issuer;

2. Electronic Attestation Status;

3. protection mechanism;

4. Validation Result;

5. Source Basis;

6. Validity Period.

5. Biometric Evidence

Biometric Evidence includes biometric information used to support Identity Verification.

Categories include:

1. biometric sample;

2. biometric reference;

3. biometric template;

4. biometric comparison result.

Assessment shall consider:

1. biometric quality;

2. biometric protection;

3. presentation attack controls;

4. applicable Biometric Profile.

6. Demographic Evidence

Demographic Evidence includes information describing characteristics associated with a Subject.

Examples include:

1. name;

2. date of birth;

3. place of birth;

4. nationality or citizenship information where applicable;

5. address information where applicable.

Demographic Evidence shall not be considered sufficient alone for High Assurance or Very High Assurance unless the applicable Profile expressly permits it.

7. Relationship Evidence

Relationship Evidence supports verification of a relationship between Subjects, Actors or entities.

Examples include:

1. family relationships;

2. guardianship;

3. representation;

4. organisational relationships.

Assessment shall consider:

1. Source Basis;

2. relationship validity;

3. effective period;

4. lifecycle Status.

8. Institutional Evidence

Institutional Evidence includes information issued or maintained by recognised organisations.

Examples include:

1. employment records;

2. education records;

3. membership records;

4. service participation records.

Assessment shall consider:

1. organisation recognition;

2. issuance controls;

3. identity verification performed by the organisation;

4. record lifecycle.

9. Historical Evidence

Historical Evidence includes information demonstrating continuity of identity-related information over time.

Examples include:

1. historical records;

2. previous Identification Results;

3. historical Source information;

4. verified interactions.

Historical Evidence shall not replace current Evidence Validity requirements where current verification is required.

Annex V: Applicable Standards

Reference	Application
ISO/IEC 24760-1	Identity concepts, terminology and identity information relationships
ISO/IEC 24760-2	Identity-management architecture considerations applicable to Identification Services
ISO/IEC 24760-3	Identity-management operational processes
ETSI TS 119 461	Identity proofing requirements applicable to trust-service-related identity verification
ISO/IEC TS 29003	Identity proofing assurance considerations
ISO/IEC 11179 series	Metadata and semantic registration for identity-related information
ISO/IEC 25012	Data quality model applicable to identity information
ISO/IEC 25024	Data quality measurement applicable to identity information
ISO/IEC 19795 series	Biometric performance testing where biometric comparison is used
ISO/IEC 30107 series	Presentation attack detection where biometric presentation is used
ISO/IEC 24745	Biometric information protection
ICAO Doc 9303	Machine-readable travel document requirements where applicable
ISO 15489-1	Records management principles
ISO/IEC 27001	Information security management controls
ISO/IEC 27701	Privacy information management controls

Untitled

UC-01: Cross-Source Identity Resolution and Deduplication Use-Case Implementation Guideline

Version: 0.1 Latest update UTC: 2026-07-25T07:19:54Z

One governance model. Federated data and services. Clearly allocated responsibility.

This Guideline coordinates existing Framework Instruments for a specific cross-source matching use case. It does not create a separate Deduplication Trust Service.

Section 1: General Provisions

Article 1: Subject matter and scope

1.1. This Guideline establishes use-case-specific requirements for Identity Resolution and duplicate detection involving two or more separately governed Sources.

1.2. This Guideline shall apply where the proposed processing concerns:

1. identity-record duplicate detection;

2. determination that records concern the same Subject or different Subjects;

3. household, case or referral duplicate detection;

4. detection of potentially repeated assistance, payments, benefits, services or interventions;

5. one-to-one, one-to-many, many-to-many, transactional, periodic or bulk matching;

6. biometric or non-biometric matching;

7. matching within or across Federation Domains.

1.3. This Guideline shall coordinate the use of existing Trust Services, Sources, Profiles, agreement routes, Technical Specifications and Framework Decisions.

1.4. This Guideline shall not:

1. create a new Trust Service Category;

2. create a universal identity register;

3. require centralisation of Source records;

4. assign Authoritative Source Status;

5. establish access, disclosure or reuse permission;

6. assign Service Permission or Technical Exchange Permission;

7. assign Qualified Status;

8. establish eligibility, entitlement, fraud, misconduct or exclusion;

9. approve operational activation.

Article 2: Controlling Framework Instruments

2.1. This Guideline shall apply together with the current approved versions of:

1. , Trust Service Provider and Trust Service Common IDEHA-IG-SVC-TSP-001 Implementation;

2. , Identification Service Implementation; IDEHA-IG-SVC-IDN-001

3. , Authentication Service Implementation; IDEHA-IG-SVC-AUT-001

4. , Authorisation Service Implementation; IDEHA-IG-SVC-AUZ-001

5. , Federated Data Exchange Service Implementation; IDEHA-IG-SVC-FDX-001

6. , Source and Authoritative Source Implementation; IDEHA-IG-SRC-ASO-001

7. , Controlled Data Elements, Semantics and Data Quality IDEHA-IG-DAT-SEM-001 Implementation;

8. , Biometric Implementation Controls, where biometric IDEHA-IG-BIO-GEN-001 information is processed;

9. , Assurance, Conformity Assessment and Qualification IDEHA-IG-ASR-GEN-001 Implementation;

10. the applicable participation, Federation Domain, security, Confidentiality, incident, Continuity, Correction, Review and Remedy instruments.

2.2. A service-specific Implementation Guideline shall govern the internal operation, evidence, assurance and lifecycle of the Trust Service to which it applies.

2.3. This Guideline shall govern only the use-case-specific assembly, purpose, Source participation, matching scope, output treatment, reuse conditions and activation sequence.

2.4. Where this Guideline and a service-specific Implementation Guideline address the same matter, the more specific service requirement shall govern the internal operation of that service.

2.5. A Scheme, Profile, Technical Specification or use-case decision shall not reduce a mandatory requirement established by the Main Framework or a controlling Implementation Guideline.

Article 3: Trust Service classification

3.1. Identity Resolution and duplicate detection shall remain functions of the Identification Service.

3.2. The native matching output shall be an Identity Resolution Result or another Identification Result permitted by the applicable Identification Service Profile.

3.3. The Federated Data Exchange Service shall support the controlled exchange of authorised requests, matching representations, responses, Trust Service Outputs and Exchange Evidence.

3.4. The Authentication Service shall authenticate participating Subjects, Actors, systems or Endpoints within its approved Service Scope.

3.5. The Authorisation Service or an assigned Policy Enforcement Function shall determine or enforce the permission applicable to matching, Source access, exchange and disclosure.

3.6. The Electronic Attestation Service shall apply only where an Identity Resolution Result or related statement is issued as an Electronic Attestation.

3.7. The Validation and Verification Service shall apply where a Source, Status, Trust Service, Trust Service Output, Trust Object or dependency requires Validation or Verification.

3.8. Digital Signing, Electronic Signature, Electronic Seal and Electronic Timestamp Services shall apply only where required by the applicable Profile, Technical Specification or evidence conditions.

3.9. The use of several Trust Services within one implementation shall not merge their Service Scopes, outputs, Status, evidence or responsibility.

Source governance

Separate local Authentication Service record decision Identification Service Identity Resolution Result Identity Resolution Authorisation Service Separate programme Policy decision or assistance decision

Federated Data Exchange Service

Article 4: Separation from infrastructure migration

4.1. Cross-source deduplication, data-quality improvement and migration from BRaVE 2 to BRaVE 3 shall remain separately governed workstreams.

4.2. A migration or hosting decision shall not determine:

1. the deduplication object;

2. the matching purpose;

3. the Source model;

4. Authoritative Source Status;

5. the permitted matching data;

6. biometric processing;

7. disclosure, return or reuse rights;

8. the required Trust Services;

9. assurance or Qualified Status.

4.3. Placement within the same database, tenant, subscription, Resource Group or hosting environment shall not merge Source responsibility or decision competence.

4.4. Separation into different databases, tenants or Resource Groups shall not, by itself, establish federated governance or require a particular matching architecture.

4.5. Infrastructure cost and migration urgency shall not override the governance, Source, protection, agreement, assurance or activation requirements established by this Guideline.

Section 2: Use-Case Decision Gates

Article 5: Decision-gate sequence

5.1. The Responsible Actors shall complete the following gates in sequence:

1. Gate 1: use-case and deduplication object;

2. Gate 2: Actors, Sources and responsibility;

3. Gate 3: data, document and biometric model;

4. Gate 4: Trust Service, exchange and output configuration;

5. Gate 5: agreement, assurance and testing readiness;

6. Gate 6: operational activation.

5.2. A later gate shall not be completed where a mandatory decision from an earlier gate remains unresolved.

5.3. Detailed technical design shall not be approved before Gates 1 and 2 are complete.

5.4. Production data shall not be processed before the relevant agreement, permission, assurance and testing conditions are effective.

5.5. Operational matching shall not begin before Gate 6 is complete.

Gate 1 Gate 2 Gate 3 Gate 4 Gate 5 Gate 6 Use case Actors and Sources Data and biometrics Services and outputs Assurance and testing Activation

Article 6: Gate 1: use-case definition

6.1. The competent Framework Body shall approve a Use-Case Decision File.

6.2. The Use-Case Decision File shall identify:

1. the recognised purpose;

2. the object being deduplicated;

3. the participating population;

4. the participating Sources;

5. the matching pattern;

6. the intended outputs;

7. the intended operational consequence;

8. prohibited uses;

9. the Responsible Actors;

10. the applicable safeguards;

11. unresolved conditions.

6.3. The deduplication object shall be identified as one or more of:

1. a natural person;

2. an Identity Registration Record;

3. another identity-related record;

4. a household or relationship;

5. a case;

6. a referral;

7. an assistance event;

8. a payment or transfer;

9. a service or intervention;

10. another defined record or event category.

6.4. The same Subject appearing in more than one Source shall not, by itself, constitute duplicate assistance or duplicate service delivery.

6.5. Where the concern is repeated assistance, the use case shall distinguish:

1. determination that records concern the same Subject;

2. determination that the relevant assistance or service event has occurred;

3. the substantive programme decision.

6.6. An Identity Resolution Result shall not, by itself, establish:

1. eligibility;

2. entitlement;

3. fraud;

4. misconduct;

5. exclusion;

6. recovery of assistance;

7. denial of a service.

6.7. The matching pattern shall identify whether processing is:

1. one-to-one;

2. one-to-many;

3. many-to-many;

4. transactional;

5. periodic batch processing;

6. full-population bulk processing;

7. event-triggered processing.

6.8. Bulk or full-population matching shall require an express necessity, proportionality and protection assessment.

Article 7: Gate 2: Actors, Sources and responsibility

7.1. Each material function shall have an identifiable Responsible Actor.

7.2. The Actor and Responsibility Matrix shall identify responsibility for:

1. use-case governance;

2. Source operation;

3. Source stewardship;

4. semantic governance;

5. Identification Service provision;

6. matching operation;

7. Federated Data Exchange Service provision;

8. Authorisation Policy management;

9. Policy Enforcement;

10. candidate-match review;

11. same-Subject or different-Subject confirmation;

12. local record action;

13. programme or assistance decisions;

14. assurance and conformity assessment;

15. security and incident management;

16. Correction, Complaint, Review and Remedy;

17. cessation and transition.

7.3. Each database, dataset, tenant, register, repository or defined part thereof used for matching shall be identified as a Source.

7.4. Each Source shall be governed through an applicable Source Profile.

7.5. The Source Profile shall identify:

1. the Source and Source Identifier;

2. the Source Holder;

3. the Source Steward;

4. the recognised purpose;

5. the Source Scope;

6. the maintained information and record categories;

7. semantic and Data Quality requirements;

8. Provenance and Freshness Conditions;

9. permitted transformations and derivations;

10. Access Conditions;

11. Disclosure Conditions;

12. permitted Trust Service uses and outputs;

13. retention and lifecycle conditions;

14. Correction, Review and Remedy Routes;

15. applicable Assurance Conditions.

7.6. A Source shall have Authoritative Source Status only through Source Designation by a Framework Body acting within its decision competence.

7.7. A Source Designation shall identify the Attribute, event, record category, population, purpose and scope for which the Source is authoritative.

7.8. Neither an IOM Source nor a partner Source shall be treated as universally authoritative merely because it contains more records, hosts the matching service or operates within the primary BRaVE environment.

7.9. A copy, export, matching index, normalised representation, biometric template, comparison score or Identity Resolution Result shall not inherit Authoritative Source Status.

7.10. Authoritative Source Status shall not, by itself, create access, disclosure, exchange or Controlled Reliance.

Article 8: Gate 3: data, document and biometric model

8.1. The use case shall have an approved semantic and data-quality model before matching rules are implemented.

8.2. Each Attribute used for matching shall identify:

1. an Attribute Identifier;

2. meaning;

3. datatype;

4. value domain;

5. permitted value states;

6. permitted transformations;

7. Source Basis;

8. Data Quality requirements;

9. Provenance requirements;

10. Freshness Conditions;

11. permitted matching use;

12. disclosure status;

13. lifecycle and Correction conditions.

8.3. The semantic model shall distinguish, where applicable:

1. legal, recorded, preferred, former and alternative names;

2. nationality, citizenship, country of origin and habitual residence;

3. sex recorded by a Source and gender-related information;

4. exact, estimated, approximate, disputed and partially known values;

5. identity, household, case, referral and assistance relationships;

6. Source values and derived values.

8.4. The Source representation shall remain preserved.

8.5. A normalised, transliterated, tokenised or otherwise derived matching representation shall remain separately identifiable and shall retain its Provenance and transformation Version.

8.6. The applicable Technical Specification shall define:

1. character encoding and Unicode treatment;

2. original-script preservation;

3. transliteration and normalisation;

4. dates, times, time zones and partial dates;

5. country, language and script codes;

6. document categories and formats;

7. document-number syntax;

8. machine-readable travel-document treatment;

9. technical schemas and validation rules.

8.7. Where biometric information is processed, the Biometric Implementation Plan shall identify:

1. the biometric purpose;

2. biometric modalities;

3. affected population;

4. participating Sources;

5. whether raw samples, templates, protected references or a combination are processed;

6. where templates are generated;

7. biometric formats;

8. capture and quality requirements;

9. the matching algorithm and Version;

10. candidate and confirmation thresholds;

11. false-match and false-non-match treatment;

12. human-review conditions;

13. storage and processing locations;

14. return, retention and deletion conditions;

15. reuse and onward-disclosure restrictions;

16. compromise, Recovery and re-enrolment procedures.

8.8. Raw samples, templates, protected references, comparison scores and identity determinations shall remain separately identifiable.

8.9. A biometric comparison score or threshold crossing shall not, by itself, constitute a confirmed same-Subject determination.

8.10. Raw biometric material shall remain with the originating Source unless central processing or transfer is separately justified, authorised and protected.

Article 9: Gate 4: Trust Service and output configuration

9.1. The use case shall operate under an approved Identification Service Profile and Identity Resolution Profile.

9.2. The Profiles shall identify:

1. the Identity Provider;

2. the Service Scope;

3. participating Sources;

4. Subject and record categories;

5. population scope;

6. permitted Attributes and biometric modalities;

7. matching methods;

8. algorithm and Version;

9. candidate and outcome classes;

10. thresholds;

11. Assurance Conditions;

12. human-review requirements;

13. retention and deletion;

14. permitted outputs;

15. permitted result uses;

16. Complaint, Correction, Review and Remedy Routes.

9.3. The applicable Federated Data Exchange Service Profile shall identify:

1. participating Actors;

2. Federation Domains;

3. Endpoints;

4. Technical Exchange Routes;

5. exchange patterns;

6. payload classes;

7. Security Conditions;

8. Exchange Evidence;

9. Continuity and Recovery conditions.

9.4. The applicable Authorisation Policy shall identify:

1. permitted Requesting Actors;

2. permitted Responding Actors;

3. approved purposes;

4. participating Sources;

5. permitted matching functions;

6. permitted payload classes;

7. permitted recipients;

8. time and validity conditions;

9. disclosure restrictions;

10. reuse and onward-disclosure restrictions.

9.5. The Matching Output and Reuse Matrix shall identify what is returned to each participating Actor or Source.

9.6. The Matrix shall distinguish:

1. Source Attributes;

2. normalised or tokenised matching representations;

3. raw biometric samples;

4. biometric templates or protected references;

5. comparison scores;

6. candidate lists;

7. confirmed Identity Resolution Results;

8. unable-to-determine results;

9. technical failures;

10. assistance or service information;

11. Exchange Evidence.

9.7. For each output, the Matrix shall identify:

1. the producing Actor or Trust Service;

2. the permitted recipient;

3. the permitted purpose;

4. disclosure mode;

5. storage permission;

6. retention period;

7. reuse permission;

8. onward-disclosure permission;

9. permitted local action;

10. required protection;

11. Correction and Review Route.

9.8. The minimum-result principle shall apply.

9.9. A participating Source shall ordinarily receive only the result required for the approved purpose and shall not receive another Sourceʼs complete record.

9.10. Technical possession of an output shall not create a right to store, reuse, disclose or rely upon that output.

IOM local decision IOM Policy IOM Source Enforcement Federated Data Identification Service Candidate or confirmed Partner local decision Exchange Service Controlled matching Identity Resolution Result Partner Policy Partner Source Enforcement Separate programme decision

Article 10: Gate 5: agreement, assurance and testing readiness

10.1. The applicable Data Sharing Agreement or equivalent agreement route shall expressly cover the approved use case.

10.2. General data-sharing language shall not be presumed to authorise:

1. full-population matching;

2. one-to-many biometric matching;

3. shared matching indexes;

4. transfer of raw biometric samples;

5. exchange of biometric templates;

6. cross-border processing;

7. matching-provider access;

8. return of underlying Source data;

9. cross-programme reuse;

10. onward disclosure.

10.3. The use-case agreement schedule shall identify:

1. purpose;

2. participating Actors and Sources;

3. Roles and responsibilities;

4. permitted data elements;

5. biometric processing;

6. matching pattern;

7. processing and storage locations;

8. providers and subprocessors;

9. permitted outputs;

10. return and reuse rights;

11. retention and deletion;

12. security and incident obligations;

13. Correction, Complaint, Review and Remedy;

14. termination and cessation treatment.

10.4. The Responsible Actors shall determine the applicable Assurance Conditions.

10.5. The assurance assessment shall consider:

1. population size;

2. matching pattern;

3. biometric processing;

4. Source quality;

5. cross-border scope;

6. false-match and false-non-match consequences;

7. automation;

8. possible adverse effects;

9. reliance by another Actor;

10. provider-chain risk;

11. security and Continuity risk.

10.6. The competent Framework Body shall determine separately whether Qualified Status is required for:

1. the Trust Service Provider;

2. the Identification Service;

3. an Authoritative Source;

4. an Identity Resolution Result;

5. an Electronic Attestation;

6. another eligible controlled object.

10.7. Qualified Status assigned to one object shall not transfer to another object.

10.8. Qualified Status shall not, by itself, create access, disclosure, exchange or Controlled Reliance.

10.9. A controlled pilot shall be completed before operational rollout.

10.10. Testing shall cover:

1. Source mapping;

2. semantic interoperability;

3. multilingual and script handling;

4. document processing;

5. date and demographic treatment;

6. biometric format compatibility;

7. biometric quality;

8. algorithm performance;

9. false matches and false non-matches;

10. demographic-performance variation;

11. candidate review;

12. Authentication and Authorisation;

13. Policy Enforcement;

14. payload protection;

15. output minimisation;

16. retention and deletion;

17. Correction, Review and Remedy;

18. Continuity and Recovery.

10.11. A material security, protection, agreement, assurance or remedy non-conformity shall prevent activation of the affected scope.

Article 11: Gate 6: operational activation

11.1. Operational activation shall require a recorded Framework Decision.

11.2. Before activation, the competent Framework Body shall verify:

1. approval of the Use-Case Decision File;

2. approval of the Actor and Responsibility Matrix;

3. effective Source Profiles;

4. effective Source Designations where required;

5. approval of the Identification Service and Identity Resolution Profiles;

6. approval of the Federated Data Exchange Service Profile;

7. approval of the Authorisation Policy;

8. approval of the Matching Output and Reuse Matrix;

9. completion of the Biometric Implementation Plan where applicable;

10. effectiveness of the agreement and legal basis;

11. recognition of the required Trust Services;

12. effectiveness of Service Permission;

13. effectiveness of Technical Exchange Permission;

14. completion of testing and conformity assessment;

15. resolution of material non-conformities;

16. readiness of incident, Continuity and Recovery arrangements;

17. readiness of Correction, Complaint, Review and Remedy Routes.

11.3. The activation decision shall identify:

1. participating Actors and Sources;

2. the activated Service Scope;

3. matching patterns;

4. permitted Attributes and biometric objects;

5. permitted outputs;

6. restrictions;

7. Effective Date;

8. Validity Period;

9. review date;

10. Change Control conditions;

11. Suspension and cessation conditions.

11.4. Technical reachability, system configuration, onboarding, catalogue listing, testing or publication shall not constitute operational activation.

Operational matching begins only after the activation decision records the approved scope, permissions, evidence, restrictions and review conditions.

Section 3: Matching Outcomes and Subsequent Decisions

Article 12: Matching outcome classes

12.1. The Identity Resolution Profile shall distinguish:

1. no candidate identified;

2. candidate relationship;

3. confirmed same-Subject determination;

4. confirmed different-Subject determination;

5. unable-to-determine result;

6. data-quality failure;

7. biometric-quality failure;

8. technical failure.

12.2. A candidate match shall not constitute a confirmed Identity Resolution Result.

12.3. A technical or quality failure shall not be represented as a non-match.

12.4. An unable-to-determine result shall not be represented as a confirmed different-Subject determination.

12.5. A match, non-match or similarity score shall not constitute a finding of fraud, misconduct, entitlement or ineligibility.

12.6. An Identity Resolution Result shall identify or reference:

1. the producing Identification Service;

2. the matching purpose;

3. the evaluated Sources;

4. the matching method and Version;

5. the outcome class;

6. the applicable threshold class;

7. quality and Assurance information;

8. evaluation time;

9. Validity Period;

10. limitations and caveats;

11. human-review requirements.

A candidate match is an input to an authorised confirmation process. It shall not directly trigger record merging, exclusion, recovery action or denial of assistance.

Article 13: Local record actions

13.1. A decision to link, merge, separate, restrict, correct, retain or delete Source records shall remain separate from the Identity Resolution Result.

13.2. An Identity Resolution Result shall not directly alter a Source record.

13.3. A local record-action decision shall identify:

1. the affected Source and records;

2. the action;

3. the purpose;

4. the supporting Identity Resolution Result;

5. additional evidence;

6. the Responsible Actor;

7. the Effective Date and Status;

8. the effect on Identifiers and dependent records;

9. the Correction, Review and Remedy Routes.

13.4. A record merge shall preserve sufficient Provenance and Historical State to reconstruct the earlier records and decisions.

13.5. A record-separation action shall identify dependent records and corrective actions.

13.6. Correction of one Source shall not automatically correct another Source.

Article 14: Programme and assistance decisions

14.1. A programme, assistance, eligibility, entitlement, payment, referral or service decision shall remain separate from Identity Resolution.

14.2. The responsible programme Actor shall determine whether and how an Identity Resolution Result supports the substantive decision.

14.3. A confirmed same-Subject determination shall not establish that:

1. assistance has already been received;

2. two assistance events are equivalent;

3. assistance was unauthorised;

4. assistance is recoverable;

5. a Subject shall be excluded.

14.4. A final significant adverse decision based substantially on automated matching shall be reviewed by a natural person.

Candidate relationship

Authorised review

Confirmed Identity Resolution Result

Separate Source Separate programme or No further action record decision assistance decision

Source lifecycle Programme lifecycle and evidence and remedy

Section 4: Protection, Lifecycle and Change

Article 15: Return, reuse and onward disclosure

15.1. Matching outputs shall be used only for the purpose, Actor, programme, Source Scope, Federation Domain and period approved through the applicable instruments.

15.2. Cross-programme, cross-country, cross-Scheme or cross-domain reuse shall require a separately approved basis.

15.3. A result created for Source data-quality improvement shall not be reused for eligibility, fraud investigation, enforcement or exclusion unless a separately authorised basis applies.

15.4. Return or disclosure of an underlying Attribute, document image, raw biometric sample, template or comparison score shall require express authorisation.

15.5. Reuse shall preserve:

1. Provenance;

2. Source Basis;

3. algorithm and Profile Version;

4. limitations and caveats;

5. Historical State;

6. Validity Period.

15.6. A Trust Service Provider or technical provider shall not reuse Source information, biometric information, matching representations or results for product development, model training, benchmarking or another purpose unless a separately authorised basis applies.

Article 16: Protected-Person Safeguards

16.1. The use case shall be designed to prevent unjustified exclusion, misidentification, surveillance, retaliation, stigma or denial of assistance.

16.2. An Accessible Alternative shall be provided where biometric, document, device, connectivity, language, literacy or disability conditions create an unjustified barrier.

16.3. Failure to provide a biometric or satisfy one technical route shall not, by itself, determine identity, eligibility, entitlement, fraud, misconduct or exclusion.

16.4. A Protected Person shall receive information appropriate to the operational context concerning:

1. the matching purpose;

2. participating organisations;

3. information and biometric modalities used;

4. possible outcomes;

5. possible operational consequences;

6. retention and reuse;

7. Correction, Complaint, Review and Remedy Routes.

16.5. Consent shall not be treated as the sole governance basis where dependency, power imbalance or inability to refuse affects voluntariness.

16.6. The use case shall include controls against function creep and unauthorised population expansion.

Article 17: Correction, Complaint, Review and Remedy

17.1. Each participating Actor shall provide an accessible route for correction of information and decisions within its responsibility.

17.2. The use case shall provide a Complaint and Review Route for:

1. false matches;

2. false non-matches;

3. disputed candidate relationships;

4. incorrect record linking or merging;

5. biometric quality findings;

6. unauthorised disclosure or reuse;

7. adverse programme decisions based on the result.

17.3. A contested result shall be subject to human review before a final significant Adverse Protected-Person Effect.

17.4. Remedy shall address, where applicable:

1. correction of the Identity Resolution Result;

2. separation of records;

3. correction of dependent Source records;

4. reassessment of programme decisions;

5. notification to affected Actors;

6. restriction or deletion of unauthorised copies;

7. restoration of access or assistance;

8. preservation of evidence.

Article 18: Change Control

18.1. A material change shall be assessed before implementation.

18.2. Material changes shall include:

1. addition of a Source;

2. population expansion;

3. a new purpose;

4. a new matching pattern;

5. a new Attribute;

6. a semantic change;

7. a new biometric modality;

8. an algorithm or threshold change;

9. a provider or hosting change;

10. a cross-border processing change;

11. a new output or recipient;

12. expanded reuse;

13. changed retention;

14. a changed operational consequence.

18.3. Change assessment shall identify the affected:

1. Framework Decisions;

2. Profiles;

3. Technical Specifications;

4. agreement conditions;

5. permissions;

6. assurance and Qualified Status;

7. testing;

8. protection and remedy requirements.

18.4. A material change outside the activated scope shall require a new or amended activation decision.

Article 19: Incident, restriction, Suspension and cessation

19.1. The Responsible Actors shall maintain procedures for:

1. unauthorised access or disclosure;

2. biometric compromise;

3. algorithm failure;

4. excessive false matches or false non-matches;

5. semantic or Source-quality failure;

6. provider-chain incidents;

7. loss of evidence;

8. unauthorised reuse.

19.2. Restriction or Suspension shall identify:

1. the affected scope;

2. the reason;

3. the evidence;

4. the Effective Date;

5. temporary controls;

6. the review interval;

7. exit conditions.

19.3. Suspension of a Trust Service shall not automatically invalidate every historical output unless the applicable Framework Decision assigns that effect.

19.4. Cessation shall address:

1. termination of exchange;

2. provider transition;

3. return or deletion of Source and biometric information;

4. preservation of evidence;

5. continuing Validation, Review and Remedy;

6. notification to affected Actors;

7. Historical State.

Annex A: Mandatory Implementation Package

Instrument	Use-case-specific function
Use-Case Decision File	Defines the object, purpose, population, pattern, outputs and intended consequence
Scheme	Establishes the governed context and participating Actors
Actor and Responsibility Matrix	Allocates each material function and decision
Source Profiles	Define each Source, scope, semantics, quality, access, disclosure and lifecycle
Source Designation decisions	Assign Authoritative Source Status where required
Controlled data-element registry	Defines permitted Attributes, value domains and semantic Versions
Source mapping specification	Maps local Source data to the controlled semantic model
Identification Service Profile	Defines the Identification Service Scope
Identity Resolution Profile	Defines matching methods, thresholds, outcomes and human review
Biometric Implementation Plan	Defines modalities, raw samples, templates, algorithms, quality and protection
Federated Data Exchange Service Profile	Defines Actors, Endpoints, routes, payloads and Exchange Evidence
Authorisation Policy	Defines permitted matching, access, exchange and disclosure
Data Sharing Agreement use-case schedule	Defines the agreement and processing conditions
Matching Output and Reuse Matrix	Defines return, storage, retention, reuse and onward disclosure
Technical Specifications	Define schemas, formats, standards, interfaces and validation rules
Assurance and qualification record	Defines assurance, conformity and Qualified Status
Pilot and test report	Records testing, limitations, non-conformities and residual risk
Activation decision	Records the approved operational scope and restrictions
Correction, Review and Remedy procedure	Provides challenge and corrective routes
Incident and cessation plan	Defines incident, Suspension, transition, deletion and evidence preservation

Annex B: Initial Decision Workshop

The following questions shall be resolved before detailed solution design is approved:

What object is being deduplicated?

What is the recognised purpose?

Is the concern identity duplication, assistance duplication or both?

Which Sources participate?

Who is the Source Holder for each Source?

Who is the Source Steward for each Source?

Which Source is authoritative for each relevant Attribute, event or decision?

Is matching one-to-one, one-to-many, many-to-many, periodic or bulk?

Which Attributes are permitted?

Which semantic definitions, value domains and code lists apply?

Which document categories and recognition rules apply?

Are biometrics used?

Are raw samples, templates, protected references or a combination processed?

Where are templates generated and stored?

Which algorithms, Versions and thresholds apply?

Who reviews candidate matches?

Who confirms same-Subject or different-Subject results?

What result is returned to each Actor or Source?

Are underlying Attributes, samples, templates or scores returned?

What storage and retention rights apply?

What reuse and onward-disclosure rights apply?

Who can link, merge, correct, restrict or separate local records?

Who makes any programme or assistance decision?

Which cross-border and provider-chain conditions apply?

Which Trust Services and permissions are required?

What assurance and Qualified Status are required?

What testing and acceptance criteria apply?

Which unresolved conditions prevent progression?

Annex C: Matching Output and Reuse Matrix

Output or information	Producing Actor or Service	Permitted recipient	Purpose	Disclosure mode	Storage	Ret
Source Attribute
Normalised matching representation
Raw biometric sample
Biometric template
Comparison score
Candidate relationship
Confirmed same-Subject result
Confirmed different-Subject result
Unable-to-determine result
Assistance or service information
Exchange Evidence

Annex D: Biometric Configuration Decision Record

Purpose and scope

• Biometric purpose identified
• Population identified
• Participating Sources identified
• Biometric modality identified
• One-to-one, one-to-many or bulk comparison identified
• Necessity and proportionality recorded
• Accessible Alternative identified

Biometric objects

• Raw samples used
• Templates used
• Protected references used
• Local template generation defined
• Shared template generation defined
• Storage locations defined
• Processing locations defined
• Return conditions defined
• Retention and deletion defined

Algorithm and performance

• Algorithm identified
• Provider identified
• Algorithm Version identified
• Feature-extraction Version identified
• Template format identified
• Quality measure identified
• Candidate threshold identified
• Confirmation threshold identified
• False-match criterion identified
• False-non-match criterion identified
• Demographic-performance testing completed
• Human-review range identified

Protection and lifecycle

• Template protection defined
• Presentation-attack detection defined
• Cross-border processing defined
• Provider access defined
• Compromise procedure defined
• Re-enrolment procedure defined
• Algorithm migration procedure defined
• Historical-result treatment defined
• Incident notification defined
• Correction, Review and Remedy defined

Annex E: Decision-Gate Readiness Checklist

Gate 1: Use case

• Deduplication object defined
• Purpose defined
• Intended consequence defined
• Identity and assistance decisions separated
• Matching pattern defined
• Population scope defined
• Use-Case Decision File approved

Gate 2: Actors and Sources

• Participating Actors identified
• Responsibilities allocated
• Source Holders identified
• Source Stewards identified
• Source Profiles approved
• Authoritative Source Scopes designated where required
• Technical and governance boundaries separated

Gate 3: Data and biometrics

• Controlled data elements defined
• Source mappings completed
• Unicode and multilingual treatment defined
• Date and demographic treatment defined
• Document-recognition rules defined
• Data Quality and Freshness Conditions defined
• Raw sample and template model defined
• Algorithms, Versions and thresholds defined
• Human-review conditions defined

Gate 4: Services and outputs

• Identification Service Profile approved
• Identity Resolution Profile approved
• Federated Data Exchange Service Profile approved
• Authorisation Policy approved
• Endpoints and Technical Exchange Routes identified
• Matching Output and Reuse Matrix approved
• Local record-action procedure approved
• Programme-decision separation confirmed

Gate 5: Agreement, assurance and testing

• Agreement route covers the use case
• Cross-border assessment complete
• Provider chain recorded
• Protected-Person Safeguards complete
• Assurance assessment complete
• Qualification decision complete
• Conformity Assessment complete
• Pilot and testing complete
• Material non-conformities resolved

Gate 6: Activation

• Service Permission effective
• Technical Exchange Permission effective
• Incident and Continuity arrangements ready
• Correction, Review and Remedy Routes ready
• Activation decision recorded
• Review date established
• Change Control active

WarningImplementation condition

Operational implementation shall not proceed where the deduplication object, Sources, responsibilities, semantic model, biometric model, output rights, reuse conditions, agreement basis, assurance requirements or activation conditions remain unresolved.