Digital ID (Accreditation) Data Standards 2024

This instrument, the Digital ID (Accreditation) Data Standards 2024, prescribes technical and testing standards that accredited identity service providers (ISPs) must apply when operating under the Digital ID Act 2024. It is made under section 99 of the Act and commences at the same time as the Act (see s 1.3 and s 1.2). Mechanically, the instrument does the following.

Establishes a biometric testing regime and the minimum qualifications and independence required of entities that perform biometric testing (Part 1, especially ss 2.2-2.7). It mandates the use of ISO biometric testing standards and, for identity document verification technology (eIDVT), the FIDO document authenticity verification requirements plus defined additional tests (s 2.3; s 2.7).
Sets three discrete authentication levels (AL1, AL2, AL3) and prescribes which authenticator types may be used at each level, the reauthentication cadence for persistent sessions, and mandatory security properties for each level, such as man-in-the-middle resistance, replay resistance, phishing resistance, AE-compromise resistance, and authentication intent (s 3.1, the AL Table).
Specifies technical requirements for binding authenticators to a digital ID in both remote and in-person contexts; for example, temporary secrets for interrupted binding flows and rules for issuing long-term secrets only within a protected session (s 3.2).
Lays down concrete minimum standards for a wide range of authenticator types: memorised secrets, look-up secrets, single- and multi-factor OTPs, single- and multi-factor cryptographic software and devices, out-of-band devices. Requirements include minimum lengths, storage and hashing methods, cryptographic key strength and storage mechanisms, nonce properties, replay protection and zeroisation after use (Divisions 3 and 4, ss 3.3-3.12).

meta-content-style-type: text/css meta-content-type: application/xhtml+xml; charset=utf-8 meta-keywords: "[SEC=OFFICIAL]" title: Digital ID (Accreditation) Data Standards 2024

Commonwealth Coat of Arms of Australia

I, Katy Gallagher, Minister for Finance, acting as the Digital ID Data Standards Chair, make the following instrument.

Dated 7 November 2024

Katy Gallagher

Minister for Finance Digital ID Data Standards Chair

Contents

Chapter 1—Preliminary

1.1 Name

1.2 Commencement

1.3 Authority

1.4 Definitions

1.5 Incorporated instruments

1.6 Application—transitioned accredited entities

Chapter 2—Data standards for ISPs

Part 1—Biometric testing

2.1 Definitions

2.2 Biometric testing entity

2.3 Testing of presentation attack detection technology

2.4 ISP’s response to testing report

2.5 Testing of biometric matching algorithm

2.6 Testing of source biometric matching

2.7 Testing of eIDVT

Part 2—Authenticating to a digital ID

Division 1—Authentication levels

3.1 Authentication levels: AL Table

Division 2—Binding authenticators to a digital ID

3.2 Binding an authenticator when generating a digital ID

Division 3—Standards for kinds of authenticators

3.3 Memorised secrets

3.4 Look-up secrets

3.5 Single-factor one-time password devices

3.6 Multi-factor one-time password devices

3.7 Single-factor cryptographic software

3.8 Multi-factor cryptographic software

3.9 Multi-factor cryptographic devices

3.10 Single-factor cryptographic devices

3.11 Out-of-band devices

Division 4—Standards for security requirements

3.12 Standards for security requirements

Division 5—Authentication using biometric information

3.13 Standards for authentication using biometric information

Chapter 1—Preliminary

1.1 Name

This instrument is the Digital ID (Accreditation) Data Standards 2024.

1.2 Commencement

This instrument commences at the same time as the Digital ID Act 2024 commences.

1.3 Authority

This instrument is made under section 99 of the Digital ID Act 2024.

1.4 Definitions

Note 1: A number of expressions used in this instrument are defined in the Act, including the following:

accredited entity;
accredited identity service provider;
authenticator;
biometric information;
digital ID.

Note 2: A number of expressions used in this instrument are defined in the Accreditation Rules, including the following:

biometric matching;
cryptographic key;
eIDVT;
presentation attack instrument;
presentation attack detection;

(1) Expressions defined in the Accreditation Rules have the same meaning in this instrument.

(2) In this instrument:

AACA means an ASD-Approved Cryptographic Algorithm as referred to in the Guidelines for Cryptography published by the Australian Signals Directorate.

Note: At the time this instrument was made, the Guidelines for Cryptography are located at https://www.cyber.gov.au/resources-business-and-government/essential-cyber-security/ism/cyber-security-guidelines/guidelines-cryptography.

Accreditation Rules means the Digital ID (Accreditation) Rules 2024.

Act means the Digital ID Act 2024.

AE-compromise resistance means authentication protocols that do not require an accredited entity to persistently store secrets that could be used for authentication.

AL Table: see section 3.1.

APCER means an attack presentation classification error rate.

authentication level: see section 3.1.

authenticated protected channel means a communication channel that uses approved cryptography where the client connection has authenticated to the relevant server.

authentication protocol means a defined sequence of messages between an individual and an ISP where the messages authenticate the individual to their digital ID by demonstrating that the individual has possession and effective control of one or more valid authenticators that have previously been bound to their digital ID.

biometric sample means biometric information that is collected from an individual using a biometric capture device or sensor and is converted into an analogue or digital representation.

biometric testing entity: see subsection 2.2(2).

custom biometric capability means a biometric binding or authentication capability integrated with the entity’s accredited services that is distinct from an in-device biometric capability.

document liveness means the presence of the original physical photo ID credential.

false match rate has the same meaning as in ISO/IEC 2382-37: 2022.

false non-match rate has the same meaning as in ISO/IEC 2382-37: 2022.

identity document template means a model representation of a particular identity document that is used to verify an acquired image of an identity document of that type.

Example: The identity document template may include, but is not limited to, text locations, colours and other graphical elements, security features, and locations of facial biometric information for identity documents that are also photo IDs.

in-device biometric capability means the built-in biometric capability provided by original equipment manufacturers for smartphones, including the biometric sensor, the presentation attack detection subsystem, and the biometric matching algorithm.

Example: Capabilities provided by online equipment manufacturers for smartphones include FaceID or Fingerprint Unlock.

ISO/IEC 17025:2017 means the standard for general requirements for the competence of testing and calibration laboratories, published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/66912.html.

ISO/IEC 19795-2:2007 means Part 2 (concerning testing methodologies for technology and scenario evaluation) of the series of standards designated ISO/IEC 19795 (concerning biometric performance testing and reporting), published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/41448.html.

ISO/IEC TS 19795-9:2019 means Part 9 (concerning testing on mobile devices) of the series of standards designated ISO/IEC TS 19795 (concerning biometric performance testing and reporting), published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/78101.html.

ISO/IEC 2382-37:2022 means Part 37 (concerning biometrics) of the series of standards designated ISO/IEC 2382 (concerning vocabulary), published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/73514.html.

ISO/IEC 24745:2022 means the standard for biometric information protection, published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/75302.html.

ISO/IEC 30107-1:2023 means Part 1 (concerning framework) of the series of standards designated ISO/IEC 30107 (concerning biometric presentation attack detection), published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/83828.html.

ISO/IEC 30107-3:2023 means Part 3 (concerning testing and reporting) of the series of standards designated ISO/IEC 30107 (concerning biometric presentation attack detection), published by the International Organization for Standardization.

Note: At the time this instrument was made, located at https://www.iso.org/standard/79520.html.

ISP means an accredited identity service provider.

look-up secret means a physical or electronic record that stores a set of secrets shared between an individual and the accredited entity authorised to provide an authenticator service.

memorised secret means a secret value chosen and memorised by the individual, such as a password or PIN.

MF crypto device is short for multi-factor cryptographic device.

MF crypto software is short for multi-factor cryptographic software.

MF OTP device is short for multi-factor one-time password device.

MitM means a man-in-the-middle attack whereby an adversary intercepts communications between 2 parties and presents themselves to each party as if the adversary were the other party.

multi-factor cryptographic device means a hardware device that performs cryptographic operations using one or more protected cryptographic keys and requires activation through a second authentication factor.

Note: Although cryptographic devices contain software, they differ from cryptographic software authenticators in that all embedded software on the hardware device is under the effective control of the accredited entity providing authentication services.

multi-factor cryptographic software means a cryptographic key that is stored in some form of removable media or device that requires activation through a second authentication factor.

multi-factor one-time password device means a device that generates OTPs as part of an authentication activity.

Note: This includes hardware devices and software-based OTP generators installed on devices such as mobile phones. The OTP is displayed on the device and input or transmitted by an individual, proving possession and effective control of the device.

one-time password means a password that is only valid for a single authentication event.

OTP is short for one-time password.

out-of-band device means a physical device that uses an alternative channel for transmitting information.

phishing resistance means authentication methods implemented by an accredited entity for preventing and addressing impersonation attacks.

presentation attack instrument species means a class of presentation attack instrument created using a common production method and based on different biometric characteristics.

PSTN means public switched telephone network.

reauthentication means the process by which the accredited entity reconfirms that a session is still under the control of the individual.

replay resistance means protection against the capture of transmitted authentication or access control information and its subsequent retransmission with the intent of producing an unauthorised effect or gaining unauthorised access.

second-generation document image means a digital or printed image of a reproduced (for example, photocopied, scanned, or photographed) unedited genuine document.

SF crypto device is short for single-factor cryptographic device.

SF crypto software is short for single-factor cryptographic software.

SF OTP device is short for single-factor one-time password device.

single-factor cryptographic device means a hardware device that performs cryptographic operations using one or more protected cryptographic keys and authenticated by proving possession and effective control of the cryptographic key.

single-factor cryptographic software means a cryptographic key that is stored in some form of soft media.

single-factor one-time password device means a device that generates and displays OTPs, including hardware devices, SMS or software‑based OTP generators installed on devices such as mobile phones.

1.5 Incorporated instruments

If a provision of this instrument applies, adopts or incorporates, with or without modification, any matter contained in any other instrument or other writing (incorporated instrument), then the reference to the incorporated instrument is as in force at the commencement of this instrument.

1.6 Application—transitioned accredited entities

(1) Paragraph (b) in column 2 of item 3 of the table in section 3.13 applies to a transitioned accredited entity starting on the day that is 12 months after the day on which this instrument commences.

(2) Every provision of this instrument not specified in subsection (1) applies to a transitioned accredited entity in accordance with its terms and on and from the commencement of this instrument.

Chapter 2—Data standards for ISPs

Part 1—Biometric testing

2.1 Definitions

In this Part:

document false accept rate means the proportion of document verification transactions with credential fraud that are incorrectly confirmed as authentic.

document false reject rate means the proportion of genuine document verification transactions with truthful claims of a genuine document that are incorrectly denied.

document fraud attack means the techniques used to create fraudulent documents.

Note: Techniques can be digital or physical and can include document tampering or creation of a counterfeit document.

document fraud instrument means an object or image used in a credential fraud attack.

Example: A forged or counterfeit photo ID.

document fraud instrument species means a class of document fraud instruments created using a common production method and based on different persons.

FIDO document authenticity verification requirements means the requirements developed by the FIDO (Fast Identity Online) Alliance for testing eIDVT solutions.

Note: At the time this instrument was made, located at https://fidoalliance.org/specs/idv/docauth/document-authenticity-verification-requirements-v1.0-fd-20220815.html.

test set has the same meaning as in section 6.2 of the FIDO document authenticity verification requirements.

2.2 Biometric testing entity

(1) Biometric testing must be conducted by a person that:

(a) uses personnel experienced in conducting biometric testing;

(b) is, or uses, a laboratory accredited against ISO/IEC 17025:2017 that is certified for the assessment of biometric technology testing standards;

(d) has established test methods for:

(i) presentation attack detection testing informed by ISO/IEC 30107-3:2023, if conducting testing of presentation attack detection technology; and

(ii) testing of accuracy of the biometric matching algorithm informed by ISO/IEC 19795-2:2007, if conducting testing of a biometric matching algorithm; and

(e) is independent from the design, implementation, operation and management of the accredited entity’s accredited services and DI data environment and is:

(i) external to the entity; or

(ii) if the entity is part of a group, external to the group.

Note 1: An ISP that conducts authentication using biometric information using custom biometric capability must ensure its presentation attack detection technology is tested by a biometric testing entity—see item 4 in the table in section 3.13.

Note 2: For paragraph (d), a person accredited to conduct presentation attack detection testing according to ISO/IEC 30107-3:2023 and/or biometric performance testing according to ISO/IEC 19795-2:2007 under the National Voluntary Laboratory Accreditation Program coordinated by the National Institute of Standards and Technology ordinarily would meet the requirements in that paragraph.

Note 3: For testing of eIDVT, the biometric testing entity must also meet subsection 2.7(2).

(2) A person that meets all the requirements in subsection (1) is a biometric testing entity.

2.3 Testing of presentation attack detection technology

(1) In this section:

level A presentation attack instrument species means a category of presentation attack instruments which:

have an elapsed creation time equal to or less than one day;
can be created or undertaken by a layperson;
can be undertaken with standard equipment; and
involve a source of biometric information which is easy to obtain such as a photo from social media or a voice recording.

level B presentation attack instrument species means a category of presentation attack instruments which:

have an elapsed creation time equal to or less than 7 days;
can be created or undertaken by a person who has the required expertise to do so;
can be undertaken with standard or specialised equipment; and
involve a source of biometric information which is moderately difficult to obtain such as a stolen fingerprint image or a voice recording of a specific phrase.

General requirement

(2) Where an ISP conducts online biometric binding, its presentation attack detection technology and liveness detection must be tested by a biometric testing entity in accordance with the requirements specified in ISO/IEC 30107-3:2023 and this Part.

Additional requirements for testing of presentation attack detection technology

(3) Testing of presentation attack detection technology must be conducted in accordance with the standards in the following table.

Standards for testing of presentation attack detection technology
Item For: the standard is:
1 the testing: must comply with the following:

be conducted on a system that incorporates all hardware and software involved in the ISP’s biometric binding process;
be conducted using configurations and settings that align to the ISP’s DI data environment;
calculate and record the completed presentation attack detection evaluation and corresponding results for each presentation attack instrument species as those artefacts and process for testing are defined by ISO/IEC 30107-3:2023, and this section;
include presentation attack instrument species to address potential presentation attack threats to the presentation attack detection technology and mechanism for liveness detection, as informed by the ISP’s cyber security risk assessment and fraud risk assessment;
include at least 6 level A presentation attack instrument species and at least 6 level B presentation attack instrument species; and
include a minimum of 10 individuals.

2 each presentation attack instrument species: must create at least one presentation attack instrument covering a minimum of 3 individuals and must be included in the testing.
3 presentation attack instrument species used in testing: 1. must meet the requirement for an APCER of 0%;

however, if the reported APCER for any presentation attack instrument species does not meet the requirement in paragraph (a), the biometric testing entity must:(i) conduct supplementary testing of any presentation attack instrument species that failed to meet the requirement in paragraph (a); and(ii) subject to paragraph (c), confirm that the supplementary testing concluded that the presentation attack instrument species successfully met the requirement in paragraph (a);
if up to one level B presentation attack instrument species used in the testing has an APCER equal to or less to 5%, with all other level B and level A presentation attack instrument species having an APCER of 0%, the biometric testing entity must include in its report to the ISP a risk rating and recommended mitigation strategies.Note: For custom biometric capability, APCER must be no more than 10%—see paragraph (k) of item 4 in the table in section 3.13.

4 the testing report and ISP’s response: 1. the ISP must:(i) obtain a copy of the testing report from the biometric testing entity; and(ii) ensure the report confirms that the ISP’s presentation attack detection technology has been tested in accordance with ISO/IEC 30107-3:2023 and this Part; and

if paragraph (c) of item 3 applies, the ISP must respond in writing to the findings and recommendations in the report as required by section 2.4.

2.4 ISP’s response to testing report

For item 4 in the table in section 2.3, the ISP’s response to the testing report must include:

(a) for each finding and recommendation in the report:

(i) a risk matrix based on an established risk management framework;

(ii) a risk assessment;

(iii) a risk rating in accordance with its risk matrix;

(iv) a response to each risk identified in the report as requiring treatment; and

(v) a response to each recommendation in the report; and

(b) for each risk and recommendation accepted by the ISP:

(i) details of the action the ISP will take to implement the treatment or recommendation;

(ii) the timeframe in which the ISP will complete the action, having regard to the risk rating assigned for the risk or recommendation; and

(iii) the residual risk rating expected following completion of the action; and

(i) the reasons for the non-acceptance;

(ii) details of alternative actions, if any, to be taken by the entity and the timeframes to do so; and

(iii) the residual risk rating expected following implementation of any alternative action.

2.5 Testing of biometric matching algorithm

(1) For biometric testing of technical biometric matching and eIDVT, the biometric matching algorithm must be tested by a biometric testing entity in accordance with the testing and reporting specifications described in ISO/IEC 19795-2:2007 to determine the:

(a) failure to enrol rate;

(b) failure to acquire rate;

(d) false non-match rate.

(2) The biometric matching algorithm must:

(a) be tested using operational configurations and settings that are consistent with and align to the ISP’s operating environment;

(b) be tested having regard to the range of individuals who may be potential users of the ISP’s accredited services;

(i) individuals with disability; and

(ii) individuals with a diverse range of ability, including ability to use technology; and

(iii) individuals with a diverse range of age, gender and ethnicity; and

(d) establish, with a minimum 90% confidence interval, that the algorithm achieves a false match rate of not more than 0.01% and a false non-match rate of not more than 3%, as described in ISO/IEC TS 19795-9:2019.

2.6 Testing of source biometric matching

For biometric testing of source biometric matching, the ISP must conduct end‑to‑end testing to ensure:

the entity’s biometric capability, including the image quality profile requirements, meets the requirements of the:

(i) authoritative source; or

(ii) service that confirms the veracity of information with an authoritative source; and

(b) the source biometric matching works as a repeatable process.

2.7 Testing of eIDVT

(1) In this section:

level A, level B or level C, in relation to document fraud attacks, have the meanings for each of those levels in section 6.2.1.2 of the FIDO document authenticity verification requirements.

(2) Where biometric testing is of an ISP’s eIDVT, the biometric testing entity conducting the testing must:

(a) be a FIDO Accredited Laboratory as defined by the FIDO document authenticity verification requirements;

(b) use personnel experienced in eIDVT testing; and

(c) have, and implement, policy and procedures that demonstrate responsible management and storage by the biometric testing entity of physical document fraud instruments.

FIDO document authenticity verification requirements

(3) The eIDVT must be tested according to, and meet the requirements of:

(a) subject to paragraph (b)—rule 5.20 of the Accreditation Rules;

(b) in relation to paragraph 5.20(4)(b) of the Accreditation Rules—the standards in the table in subsection (4);

(d) the additional requirements to the FIDO document authenticity verification requirements in the following table.

Additional requirements to the FIDO document authenticity verification requirements
Item FIDO section: the additional requirement is:
1 Section 6.2 (test sets): must be reasonably balanced across document types and contain at least 30 of each listed document type supported by the eIDVT.
2 Section 7.2.2 (test crew and associated genuine documents): the test set for physical document testing:

are to be reasonably balanced across document types and must contain at least 10 of each listed document supported by the eIDVT; and
the eIDVT must meet the criteria described in 3.1 of the FIDO document authenticity verification requirements (performance levels), but must achieve a document false reject rate of 1% or below and the document false accept rate of 1%, for both digital testing and physical document testing.

Standards for eIDVT testing for document liveness

(4) When conducting eIDVT testing, the standards in the following table apply.

Standards for eIDVT testing for document liveness requirements
Item Requirement: the standard is:
1 Inputs for digital document testing—for digital document testing: the ISP must use:

300 images of documents for each test set (see section 6.2 of the FIDO document authenticity verification requirements); or
300 instances of the inputs the eIDVT uses to detect document liveness that include, but are not limited to, the following:(i) short video;(ii) two or more separate images either at different angles or of the reverse of the document; or(iii) another challenge or response as required by the technical specifications of the eIDVT testing.

2 The images referred to in item 1: must reasonably cover:

varying geographics for document types the entity accepts for eIDVT biometric matching; and
for demographics represented on the images of the documents, a diverse range of individuals, including individuals with disability and individuals with a diverse range of age, gender, ability and ethnicity.

3 Levels of document fraud attacks in scope for digital document testing: the following levels of document fraud attack for digital document testing of document fraud instruments are within scope:

level A attacks;
level B attacks; and
level C attacks.

4 Evaluations with document fraud instruments in digital testing—the test set of document fraud instruments used for digital document testing: must:

comply with the conditions imposed by section 6.3.2 of the FIDO document authenticity verification requirements; and
contain:(i) at least 10% of document fraud instruments at level A, B, and C that are genuine second-generation document images; and(ii) no documents that are considered to be out-of-scope for processing through the eIDVT.

5 Levels of document fraud attacks in scope for physical testing: the following levels of document fraud attack for physical testing of document fraud instruments are within scope:

level A attacks; and
level B attacks.

6 Test set conditions for physical evaluation using document fraud instruments: must include:

minimum of 100 document fraud instruments which reasonably include:(i) varying geographics for document types the entity accepts for eIDVT biometric matching; and(ii) for demographics represented on the images of the documents, a diverse range of individuals, including individuals with disability and individuals with a diverse range of age, gender, ability and ethnicity;
only document fraud instruments that are reproduced forms of genuine documents being printed versions of second-generation document images;
no physically tampered documents;
at least 30% document fraud instruments at level A representing at least 3 or more document fraud instrument species;
at least 30% document fraud instruments at level B representing at least 3 or more document fraud instrument species; and
no document types that are considered out-of-scope for processing through the eIDVT.

7 Document verification transactions with physical document fraud instruments: the biometric testing entity must conduct testing with physical document fraud instruments according to the rules for transactions for testing for genuine physical documents as set out in section 7.3.1 of FIDO document authenticity verification requirements.
8 Metrics to be calculated for physical document fraud instruments: the document false accept rate must be calculated in accordance with section 3.1.2 of FIDO document authenticity verification requirements.

(5) The ISP must ensure:

(a) the biometric testing entity provides it with a report; and

(b) the biometric testing entity’s report confirms that the ISP’s eIDVT has been tested in accordance with the requirements in this section.

(6) The ISP must maintain a list of the unique kinds of credentials accepted by the eIDVT for verification and the list must include:

(a) the kind of credential;

(b) the issuer of the credential; and

Note: See Schedules 1 to 4 in the Accreditation Rules for kinds of credentials.

(7) If new kinds of credentials are included in the ISP’s eIDVT for verification, the eIDVT must be retested in accordance with this section for those credentials.

Part 2—Authenticating to a digital ID

Division 1—Authentication levels

3.1 Authentication levels: AL Table

The following table (AL Table):

(a) specifies 3 authentication levels (AL1, AL2 and AL3);

(b) the kinds of authenticators that can be used for each authentication level (item 1);

(d) mandatory security requirements for each authentication level (items 3 to 7), where ‘must’ stated in the column for the authentication level means the requirement is mandatory for that authentication level; and

(e) the allowed combinations of authentication levels and identity proofing levels (item 8).

AL Table
Item Column 1 Column 2 Column 3 Column 4
Requirement AL1 AL2 AL3
1 Kinds of authenticators One of the following:
memorised secret;
look-up secret;
SF OTP device;
SF crypto software;
SF crypto device;
MF OTP device;
MF crypto software;
MF crypto device. One of the following:
MF OTP device;
MF crypto software;
MF crypto device; or
a memorised secret and one the following:
look-up secret;
out-of-band device;
SF OTP device;
SF crypto software;
SF crypto device. One of the following:
MF crypto device;
SF crypto device and memorised secret;
SF OTP device and MF crypto software;
SF OTP device and MF crypto device;
SF OTP device and SF crypto software and memorised secret.
2 Reauthentication Where the authenticated session is persistent, the individual must reauthenticate to their digital ID after 30 days. For reauthentication, the individual must use at least 1 authentication factor. Where the authenticated session is persistent, the individual must reauthenticate to their digital ID after 12 hours, regardless of user activity. Otherwise, the session must be terminated. After 30 minutes of inactivity, the individual must reauthenticate to their digital ID. Otherwise, the session must be terminated.For reauthentication, the individual must use at least 1 authentication factor.For reauthentication, the individual must use a memorised secret or authentication using biometric information. Where the authenticated session is persistent, the individual must reauthenticate to their digital ID after 12 hours, regardless of user activity. Otherwise, the session must be terminated.After 15 minutes of inactivity, the individual must reauthenticate to their digital ID. Otherwise, the session must be terminated.For reauthentication, the individual must use both authentication factors.
Security
3 MitM resistance Must Must Must
4 Phishing resistance — — Must
5 AE-compromise resistance — — Must
6 Replay resistance — Must Must
7 Authentication intent — — Must
8 AL level to be combined with an identity proofing level IP1 Identity proofing levels up to and including IP3. All identity proofing levels

Division 2—Binding authenticators to a digital ID

3.2 Binding an authenticator when generating a digital ID

(1) For remote transactions where generating the digital ID and binding of the authenticator to that digital ID cannot be completed in a single electronic transaction that is a single protected session:

(a) individuals must identify themselves in the binding transaction by presenting a temporary secret which was either established during a prior transaction or sent to the individual’s mobile phone number or email address (temporary secret); and

(b) long-term authentication secrets must be issued to an individual only within a protected session.

Note: Generating the digital ID and binding of the authenticator may not be completed in a single electronic transaction that is a single protected session where the identity proofing is conducted online and the individual is required to collect a physical item such as a lookup secret.

(2) For in-person transactions where the generation of the digital ID and binding of an authenticator to that digital ID cannot be completed in a single physical encounter within a single protected session:

(a) individuals must identify themselves in-person by either presenting a temporary secret, or by biometric authentication;

(b) temporary secrets must not be reused; and

(c) if the ISP issues long-term authentication secrets during an in‑person transaction, those secrets must be loaded locally on to a physical device that is issued in-person to the individual or delivered in a manner that confirms the individual’s email address or mobile phone number.

Division 3—Standards for kinds of authenticators

3.3 Memorised secrets

For memorised secrets, the standards in the following table apply.

Standards for memorised secrets
Item Requirements—If: the standard is:
1 a memorised secret is chosen by an individual: must be at least 8 characters long.
2 a memorised secret is chosen randomly by the accredited entity: must be at least 6 characters long and may be entirely numeric.
3 a request from an individual is being processed to establish or change a memorised secret: the ISP must compare the prospective secret against a list that contains secrets known to be commonly used, expected or compromised.Example: The list may include:
passwords obtained from previous breach corpuses;
dictionary words;
repetitive or sequential characters (e.g. “aaaaaa”, “1234abcd”); and
context-specific words, such as the name of the service, the username, and derivatives thereof.
4 the chosen secret is found in the list referred to in item 3: the ISP must:

notify the individual that they need to select a different secret;
provide the reason for rejection; and
require the individual to choose a different secret.

5 a memorised secret is being requested: the ISP’s information technology system must use an AACA and an authenticated protected channel.
6 a memorised secret is being stored: must be stored in a form that is resistant to offline attacks, including by ensuring:

memorised secrets are salted and hashed using a suitable one-way cryptographic key derivation function;
the salt value is at least 32 bits in length and be chosen arbitrarily so as to minimise salt value collisions among stored hashes; and
both the salt value and the resulting hash are stored for each individual who uses memorised secrets.

3.4 Look-up secrets

For look-up secrets, the standards in the following table apply.

Standards for look-up secrets
Item Requirements—If: the standard is:
1 a look-up secret is delivered to an individual: must be delivered in a secure manner.
2 a look-up secret is requested from the individual: the individual must be prompted for the next secret from the individual’s authenticator or for a specific secret.
3 a look-up secret is given to an individual: must only be used successfully once.
4 the lookup secret is derived from a grid card: each cell of the grid must be used only once.
5 a look-up secret is stored: must be stored in a form that is resistant to offline attacks, including by ensuring:

look-up secrets are hashed using an AACA; and
for look-up secrets that have less than 112 bits of entropy—the look up secret is salted before being hashed with a salt value that is at least 32 bits in length and arbitrarily chosen so as to minimise salt value collisions among stored hashes.

6 an individual uses look-up secrets: must store both the salt value and the resulting hash for each individual referred to in item 5.
7 the ISP requests a look-up secret to provide resistance to eavesdropping and MitM: must use an AACA and an authenticated protected channel.

3.5 Single-factor one-time password devices

For single-factor one-time password devices, the standards in the following table apply.

Standards for single-factor one-time password devices
Item Requirement the standard is:
1 For the secret cryptographic key and its algorithm: must provide the minimum-security strength specified in the ISM’s Guidelines for Cryptography relevant to the AACA in use.
2 For the nonce: must be of sufficient length to ensure that it is unique for each operation of the device over its lifetime.Note: The specific secret may be, for example, the next numbered secret.
3 If the nonce used to generate the authentication output is based on a real time clock: the nonce must be changed at least once every 2 minutes.
4 The OTP value associated with a given nonce: must not be accepted more than once.
5 If a single-factor OTP authenticator is being associated with a digital ID: must use an AACA to either generate and exchange, or to obtain, the secrets required to duplicate the authentication output.
6 If collecting the OTP to provide resistance to eavesdropping and MitM: must use AACAs and an authenticated protected channel.
7 If providing replay resistance, the entity’s information technology system: must not accept a given time-based OTP more than once during the validity period of the authenticator involved.
8 Time-based OTPs: must have a defined lifetime that is determined by the expected clock drift, in either direction, of the authenticator over its lifetime, plus allowance for network delay and individual entry of the OTP.

3.6 Multi-factor one-time password devices

For multi-factor one-time password devices, the standards in the following table apply.

Note: When using biometric information as a factor for multi-factor one-time password devices, section 3.13 applies.

Standards for multi-factor one-time password devices
Item Requirements: the standard is:
1 The secret cryptographic key and its algorithm: must provide at least the minimum-security strength specified in the ISM’s Guidelines for Cryptography relevant to the AACA in use.
2 The nonce: must be of sufficient length to ensure that it is unique for each operation of the device over its lifetime.
3 The OTP authentication: must:

not facilitate the cloning of the secret cryptographic key on to multiple devices; and
establish that the MF OTP authenticator is a MF OTP device.

4 If the nonce used to generate the authentication output is based on a real‑time clock: the nonce must be changed at least once every 2 minutes.
5 If a memorised secret is used for activation: must be a randomly chosen numeric secret at least 6 decimal digits in length.
6 The unencrypted key and activation secret: must be zeroised immediately after an OTP has been generated.
7 If the ISP collects biometric information using a custom biometric capability, the biometric sample, and any biometric information derived from the biometric sample: must be zeroised immediately after an OTP has been generated.
8 If an MF OTP authenticator is being associated with a digital ID: must use an AACA to either generate and exchange, or to obtain, the secrets required to duplicate the authentication output.
9 If collecting the OTP to provide resistance to eavesdropping and MitM: must use an AACA and an authenticated protected channel when collecting the OTP.
10 Time-based OTPs: must have a defined lifetime that is determined by the expected clock drift - in either direction - of the authenticator over its lifetime, plus allowance for network delay and individual entry of the OTP.
11 Replay resistance: the accredited entity’s information technology system must not accept a given time-based OTP more than once during the validity period of the authenticator.

3.7 Single-factor cryptographic software

For single-factor cryptographic software, the standards in the following table apply.

Standards for single-factor cryptographic software
Item Requirement: the standard is:
1 The secret cryptographic key and its algorithm: must:

provide at least the minimum-security strength specified in the latest edition of the ISM;
be stored in suitably secure storage available to the authenticator application. Applications must utilise one of the following mechanisms to be considered as secure storage:(i) keychain storage;(ii) Trusted Platform Module;(iii) Trusted Execution Environment;(iv) secure element; and
only be accessible to the authenticating software on the device that is authorised. All unauthorised software must not be able to access the secret key.

2 The single-factor cryptographic device: must encapsulate one or more secret cryptographic keys, unique to the device, that cannot be removed from the device.
3 The secret cryptographic key and its algorithm: must provide at least 112 bits of effective security strength.
4 The challenge nonce: must:

be at least 64 bits in length; and
either be unique over the authenticator’s lifetime, or be statistically unique.

5 Approved cryptography: must be used for authentication events.
6 Cryptographic keys: must be protected against modification and unauthorised disclosure.

3.8 Multi-factor cryptographic software

For multi-factor cryptographic software, the standards in the following table apply.

Note: When using biometric information as a factor for multi-factor cryptographic software, section 3.13 applies.

Standards for multi-factor cryptographic software
Item Requirement: the standard is:
1 The secret cryptographic key and its algorithm: 1. must only be accessible by a device’s software components that require access; and

the ISP must implement access controls to prevent unauthorised access to the secret cryptographic key.

2 Authentication events: must require the input of 2 or more authentication factors to execute that authentication event.
3 Any memorised secret used for activation: must be a randomly chosen numeric value at least 6 decimal digits in length.
4 The unencrypted key and activation secret: must be zeroised immediately after an authentication has taken place.
5 If the ISP collects biometric information using a custom biometric capability, the biometric sample, and any biometric information derived from the biometric sample: must be zeroised immediately after an authentication has taken place.
6 Cryptographic keys: must:

be stored in suitably secure storage available to the authenticator application. Applications must utilise one of following mechanism to be considered as secure storage:(i) keychain storage;(ii) Trusted Platform Module;(iii) Trusted Execution Environment;(iv) secure element; and
must be protected against modification; and unauthorised disclosure.

7 The challenge nonce: must:

be at least 64 bits in length; and
either be unique over the authenticator’s lifetime or be statistically unique.

8 The authentication event: must use approved cryptography.

3.9 Multi-factor cryptographic devices

For multi-factor cryptographic devices, the standards in the following table apply.

Note: When using biometric information as a factor for multi-factor cryptographic device, section 3.13 applies.

Standards for multi-factor cryptographic devices
Item Requirement: the standard is:
1 The secret cryptographic key and its algorithm: must:

provide at least the minimum-security strength specified in the ISM’s Guidelines for Cryptography relevant to the AACA in use; and
be accessible only through the presentation and verification of an activation factor, using either biometric information for authentication or an activation secret.

2 The challenge nonce: must:

be at least 64 bits in length; and
either be unique over the authenticator’s lifetime, or be statistically unique.

3 Approved cryptography: must be used for authentication events.
4 Cryptographic keys: must be protected against modification and unauthorised disclosure.

3.10 Single-factor cryptographic devices

For single-factor cryptographic devices, the standards in the following table apply.

Standards for single-factor cryptographic devices
Item Requirement: the standard is:
1 The secret cryptographic key and its algorithm: must:

provide at least the minimum-security strength specified in the ISM’s Guidelines for Cryptography relevant to the AACA in use; and
be designed so as to prohibit the export of the authentication secret.

2 The challenge nonce: must:

be at least 64 bits in length; and
either be unique over the authenticator’s lifetime, or be statistically unique.

3 Approved cryptography: must be used for authentication events.
4 Cryptographic keys: must be protected against modification and unauthorised disclosure.
5 Cryptography device: must be a separate piece of hardware or an embedded processor or execution environment.

3.11 Out-of-band devices

For out-of-band devices, the standards in the following table apply.

Standards for out-of-band devices
Item Requirement: the standard is:
1 The out-of-band device: must establish a separate channel with the ISP’s information technology system to retrieve the out-of-band secret or authentication request.Note: This separate channel is out-of-band with respect to the primary communication channel (even if it terminates on the same device), provided the device does not leak information from one channel to the other without the consent of the individual.
2 The out-of-band device: must uniquely authenticate itself in one of the following ways when communicating with the entity’s information technology system:

establish an authenticated protected channel to the entity’s information technology system that:(i) uses approved cryptography; and(ii) stores relevant cryptographic keys in suitably secure storage available to the authenticator application; or
only where a secret is being sent from the entity’s information technology system to the out-of-band device via the PSTN, authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device.

3 If the out-of-band device sends an approval message over the secondary communication channel, rather than by the individual transferring a received secret to the primary communication channel, the device: 1. must accept transfer of the secret from the primary channel, which secret must be sent to the entity’s information technology system over the secondary channel to associate the approval with the authentication transaction; or

must:(i) present a secret received via the secondary channel from the entity’s information technology system;Example: The individual may perform the transfer manually or use a technology such as a barcode or QR code to affect the transfer.(ii) prompt the individual to verify the consistency of that secret with the primary channel, before accepting a yes/no response from the individual; and(iii) send that response to the entity’s information technology system.

4 If out-of-band verification is conducted using a secure application on a device and the entity’s information technology system sends a push notification to that device: 1. the entity’s information technology system must wait for the establishment of an authenticated protected channel and must verify the device’s identifying cryptographic key; and

the identifying cryptographic key received must not be stored.

5 The entity’s information technology system: must:

use a verification method to uniquely identify the device; and
authenticate the device before transmitting the authentication secret to the device.

6 The entity’s information technology system; must, depending on the type of out-of-band device:

transfer the secret to the primary channel as follows:(i) signal the device containing the individual’s authenticator to indicate readiness to authenticate;(ii) after transmitting such signal, transmit a random authentication secret to the out-of-band device; and(iii) wait for the random authentication secret to be returned on the primary communication channel; or
transfer the secret to the secondary channel as follows:(i) display a random authentication secret to the individual via the primary channel; and(ii) wait for the random authentication secret to be returned on the secondary channel from the individual’s out-of-band device; or
obtain verification of secrets from the individual as follows:(i) displays a random authentication secret to the individual via the primary channel; (ii) sends the same random authentication secret to the out-of-band device via the secondary channel for presentation to the individual; and(iii) after transmitting the random authentication secret referred to in subparagraphs (c)(i) and (ii), wait for an approval (or disapproval) message via the secondary channel; and
for each option in this item, the authentication must be considered invalid if each of the required activities are not completed within 10 minutes.

7 To provide replay resistance: the entity’s information technology system must not accept a given authentication secret more than once during the validity period.
8 Random authentication secrets: must have with at least 20 bits of entropy.
9 If the random authentication secret has less than 64 bits of entropy: the entity’s information technology system must incorporate a rate-limiting mechanism that limits the number of failed attempts to authenticate to a digital ID.
10 If out-of-band verification is to be made using the PSTN: the ISP must:

verify that the pre-registered telephone number being used is associated with a specific physical device; and
conduct the verification in accordance with the risk-management strategies required to be detailed in the entity’s system security plan (see Subdivision 1 of Division 3 of Part 4.1 of Chapter 4 of the Accreditation Rules);
inform individuals in clear and simple terms of the security risks of using out-of-band verification via the PSTN; and
offer individuals at least one alternative authenticator that can be used to authenticate to the required authentication level.

11 Out-of-band verification: must not use email or voice-over-IP (VOIP) telephone numbers.
12 If an individual requests to change their pre-registered telephone number: the individual must first authenticate to their digital ID using their existing authenticator.

Division 4—Standards for security requirements

3.12 Standards for security requirements

When authenticating an individual to their digital ID, the standards in the following table apply.

Standards for security requirements
Item Requirements: the standard is:
1 Phishing resistance (when authenticating to AL3): 1. an authenticator is not phishing resistant if it involves the manual entry of an authentication output, such as out-of-band and OTP authenticators;

the phishing resistant authentication protocol must:(i) establish an authenticated protected channel with the entity’s information technology system; and(ii) strongly and irreversibly bind a channel identifier that was negotiated in establishing the authenticated protected channel to the authentication output;Note: The binding may occur by signing the 2 values together using a private key (the cryptographic key in an asymmetric cryptographic key pair that must be kept secret) controlled by the individual for which the public key is known to the entity.
the ISP’s information technology system must validate the signature or other information used to prove phishing resistance;
an AACA must be used to establish phishing resistance; and
cryptographic keys for the purpose of establishing phishing resistance must provide at least 112 bits of effective security strength.

2 AE-compromise resistance when authenticating to AL3: 1. public keys stored by the ISP must be associated with the use of an AACA; and

cryptographic keys must provide at least 112 bits of effective security strength.

3 Authentication intent: when authenticating to AL3, and AL2 if authentication intent is used for that level, the authentication intent must be established by the authenticator itself.
4 Rate limiting (throttling): 1. rate limiting must be implemented and maintained for each of:(i) memorised secrets;(ii) look-up secrets;(iii) single-factor OTPs; and(iv) multi-factor OTPs;

controls must be implemented and maintained within the entity’s information technology system to protect authenticators against online guessing attacks; and
consecutive failed authentication attempts on the digital ID of an individual must be limited to no more than 100.

5 Authenticator attestation where the authenticator attestation is signed: the attestation must be signed using a digital signature that provides at least 112 bits of effective security strength.

Division 5—Authentication using biometric information

3.13 Standards for authentication using biometric information

When authenticating an individual to their digital ID using biometric information of the individual, the standards in the following table apply.

Standards for authentication using biometric information
Item Column 1 Column 2
Requirement: Requirement:
1 Use of biometric information for authentication: must be conducted only using:

in-device biometric capability (see item 3 in this table); or
custom biometric capability (see item 4 in this table).

2 When biometric information can be used for authentication as a factor to unlock a multi-factor authenticator: 1. only where the relevant authenticator is a:(i) multi-factor one-time password device;(ii) multi-factor cryptographic software; or(iii) multi-factor cryptographic device; and

only where the relevant authenticator:(i) requires 2 or more factors to execute a single authentication event; and(ii) is possession-based, where the device is authenticated as a part of the single authentication event.

3 In-device biometric capability: must:

only be used as a factor for authentication events to meet AL1 or AL2; and
not allow the use of in-device biometric capability that operates on devices that cannot receive operating system security updates.

4 Custom biometric capability: 1. an authenticated protected channel between the sensor and the accredited entity’s information technology system must be set up before capturing the biometric information from the individual;

must use a biometric matching algorithm to conduct one‑to‑one biometric matching between the acquired image and the biometric template;
biometric matching must be conducted using the biometric matching algorithm:(i) locally on the individual’s device; or(ii) centrally, being where the biometric information is transferred to the entity’s information technology system and the biometric matching is conducted remotely by the entity from the individual’s device;
if biometric matching is conducted centrally:(i) use of the biometric as an authentication factor must be limited to one or more specific devices that are identified using approved cryptography;(ii) a separate cryptographic key must be used for identifying the device, as distinct from the biometric factor;(iii) all transmission of biometrics must occur over the authenticated protected channel; and(iv) biometric template protection specified in ISO/IEC 24745:2022 must be implemented;
presentation attack detection must:(i) be based on data captured by both the data capture subsystem and through system level monitoring, as described by ISO/IEC 30107-1:2023; and(ii) include liveness detection;
the capture of the acquired image and presentation attack detection processes must be completed as part of the same process before submission of the acquired biometric for biometric matching;
the presentation attack detection determination (as to whether the biometric presentation passes as being genuine according to the PAD system) must be made either:(i) locally on the individual’s device; or(ii) centrally (where the biometric information is transferred to the ISP’s information technology system and the biometric matching is conducted remotely by the entity from the individual’s device);
presentation attack detection must allow no more than 5 consecutive failed authentication attempts;
once the limit of consecutive failed attempts has been reached, the custom biometric capability must either:(i) impose a delay of at least 30 seconds before the individual’s next attempt to authenticate using the custom biometric capability, increasing exponentially with each successive attempt (e.g., one minute before the following attempt, 2 minutes before the second following attempt); or(ii) disable the custom biometric capability for authentication and offer another authentication factor that is a different biometric modality or a PIN/passcode if not already a required factor;
subject to paragraph (k)—the presentation attack detection technology must be tested in accordance with section 2.3;
despite item 3 in the table in section 2.3 all presentation attack instrument species used in testing of the biometric algorithm must have an APCER of no more than 10%; and
the biometric matching algorithm must be tested in accordance with section 2.5.

meta-content-style-type: text/css meta-content-type: application/xhtml+xml; charset=utf-8 meta-keywords: "[SEC=OFFICIAL]" title: Digital ID (Accreditation) Data Standards 2024

Digital ID (Accreditation) Data Standards 2024

I, Katy Gallagher, Minister for Finance, acting as the Digital ID Data Standards Chair, make the following instrument.

Dated 7 November 2024

Katy Gallagher

Minister for Finance Digital ID Data Standards Chair

Contents

Chapter 1—Preliminary

1.1 Name

1.2 Commencement

1.3 Authority

1.4 Definitions

1.5 Incorporated instruments

1.6 Application—transitioned accredited entities

Chapter 2—Data standards for ISPs

Part 1—Biometric testing

2.1 Definitions

2.2 Biometric testing entity

2.3 Testing of presentation attack detection technology

2.4 ISP’s response to testing report

2.5 Testing of biometric matching algorithm

2.6 Testing of source biometric matching

2.7 Testing of eIDVT

Part 2—Authenticating to a digital ID

Division 1—Authentication levels

3.1 Authentication levels: AL Table

Division 2—Binding authenticators to a digital ID

3.2 Binding an authenticator when generating a digital ID

Division 3—Standards for kinds of authenticators

3.3 Memorised secrets

3.4 Look-up secrets

3.5 Single-factor one-time password devices

3.6 Multi-factor one-time password devices

3.7 Single-factor cryptographic software

3.8 Multi-factor cryptographic software

3.9 Multi-factor cryptographic devices

3.10 Single-factor cryptographic devices

3.11 Out-of-band devices

Division 4—Standards for security requirements

3.12 Standards for security requirements

Division 5—Authentication using biometric information

3.13 Standards for authentication using biometric information

Chapter 1—Preliminary

1.1 Name

The instrument builds around a small set of recurring technical and regulatory concepts; understanding them is central to compliance and operational design.

Authentication levels (AL1, AL2, AL3). The AL Table in s 3.1 identifies the authenticators permitted at each level, the required reauthentication cadence for persistent sessions, and mandatory security properties. For example, AL3 requires phishing resistance, AE-compromise resistance and authentication intent, while AL1 permits a broad set of authenticators including memorised secrets and single-factor devices (s 3.1).
Authenticator types and binding. The instrument differentiates many authenticator types: memorised secrets, look-up secrets, single/multi-factor OTPs, single/multi-factor cryptographic software and devices, out-of-band devices, and biometric authenticators (s 1.4 definitions; ss 3.3-3.11). Binding rules require temporary secrets for interrupted remote or in-person flows and insist that long-term secrets be issued only within a protected session (s 3.2).
Biometric capability split: in-device versus custom. In-device biometric capability is the manufacturer-built biometric sensor, PAD subsystem and local matcher (examples include FaceID or Fingerprint Unlock) (definition at s 1.4). Custom biometric capability is an ISP-integrated biometric facility distinct from in-device capabilities. The instrument treats these differently in testing and allowed authentication uses (s 3.13).
Biometric testing and PAD. Part 1 details biometric testing requirements. Biometric testing must be carried out by an independent biometric testing entity meeting ISO/IEC 17025 accreditation and having suitable policies for human test subjects and test methods informed by ISO/IEC 30107-3:2023 and ISO/IEC 19795-2:2007 (s 2.2). Presentation attack detection testing must include specific species and minimum sample counts and meet APCER thresholds; in many instances APCER must be 0% for species used in testing (s 2.3).
eIDVT and FIDO. eIDVT testing must be done by a FIDO Accredited Laboratory, meet the FIDO document authenticity verification requirements and specified additional standards, including minimum test set sizes and document false accept/reject thresholds (s 2.7).
Cryptography and AACA. The instrument repeatedly references ASD-Approved Cryptographic Algorithm (AACA) and the ISM Guidelines; it requires appropriate cryptographic strength (commonly at least 112 bits effective security strength) and use of approved cryptography in communication channels (s 1.4 and multiple provisions in ss 3.5-3.12).
Security primitives: APCER, FMR and FNMR. The instrument adopts biometric testing metrics such as attack presentation classification error rate (APCER), false match rate (FMR) and false non-match rate (FNMR), and sets minimum performance metrics for algorithms (e.g., FMR ≤ 0.01% and FNMR ≤ 3% under specified confidence intervals) (s 2.1 definitions; s 2.5).
Operational security behaviours: zeroisation, authenticated protected channels and rate-limiting. The instrument requires zeroisation of unencrypted keys and certain biometric samples after use, mandates the use of authenticated protected channels for many flows, and imposes throttling and failure limits (ss 3.6, 3.7, 3.8, 3.11, 3.12).

These concepts are implemented through prescriptive technical tests, minimum numeric thresholds, and procedural requirements (for reports and responses). The instrument ties ISO and FIDO testing methodologies into the accreditation framework by reference and requires ISPs to obtain testing reports and to react in structured ways (ss 2.3-2.5; s 2.7).

Primary regulated parties and stakeholders under this instrument are identified in the text and by its cross-references to the Digital ID Act and the Accreditation Rules.

Accredited identity service providers (ISPs). The instrument repeatedly places obligations on ISPs to ensure testing, implement specific authenticator behaviours, maintain credential lists and respond to testing reports; see, for example, ss 2.3(4), 2.7(5)-(7), 3.2, and Divisions 3-5 of Part 2 (s 3.1-3.13). ISPs are the principal entity required to operationalise the standards.
Biometric testing entities and laboratories. The instrument defines the biometric testing entity as a person meeting detailed competence, accreditation and independence conditions (s 2.2). For eIDVT, the testing entity must be a FIDO Accredited Laboratory with procedures for physical document handling (s 2.7(2)).
Individuals (users of digital ID). Individuals are affected indirectly by mandatory reauthentication cadences (s 3.1), the use of temporary secrets in binding transactions (s 3.2), and requirements that ISPs inform individuals of PSTN risks and offer alternatives if PSTN is used as an out-of-band channel (s 3.11(10)). Biometric testing requires participation of human test subjects under approved policies (s 2.2(1)(c)).
Device manufacturers and original equipment manufacturers (OEMs). The distinction between in-device and custom biometric capability imposes constraints on what device capabilities ISPs can leverage (s 3.13 and s 1.4 note). For example, in-device biometrics cannot be used for AL3 and must not operate on devices that cannot receive OS security updates (s 3.13(3)), and that specific restriction has a transitional application (s 1.6).
Testing and accreditation ecosystem. National and international standards bodies, the ASD/ISM (through AACA and ISM Guidelines), ISO standard-holding labs and the FIDO Alliance ecosystem will be engaged because the instrument requires particular ISO parts and FIDO testing (ss 1.4 notes; ss 2.2, 2.3, 2.5, 2.7).
Entities providing identity documents and authorative sources. ISPs must maintain lists of accepted credential kinds, issuers and series and retest eIDVTs when new credential kinds are added (s 2.7(6)-(7)). That creates a compliance obligation touching issuers and the credential ecosystem.

A small but important subgroup is “transitioned accredited entities” which receive a limited delay in the application of the device-update prohibition in s 3.13(3)(b) for 12 months (s 1.6). The instrument itself does not create criminal penalties but sits within the Digital ID Act / Accreditation Rules enforcement framework; therefore regulatory or accreditation sanctions would be applied through those instruments rather than within the instrument itself (see s 1.3 and the incorporation of Accreditation Rules in s 1.4).

The instrument imposes multiple affirmative duties on ISPs and sets procedural duties for biometric testing entities. Rights per se are not established as standalone entitlements in the instrument; rather, the instrument prescribes technical duties ISPs must discharge if they are to remain accredited under the overarching Act and Accreditation Rules.

Key duties for ISPs

Ensure biometric testing is conducted by a qualified, independent biometric testing entity. The testing entity must employ personnel experienced in biometric testing, be accredited to ISO/IEC 17025:2017 for biometric testing, have an approved human subjects policy, have established test methods informed by relevant ISO standards, and be independent from the ISP and its group (s 2.2(1)(a)-(e)). For eIDVT testing, the testing entity must also be a FIDO Accredited Laboratory and meet additional handling requirements (s 2.7(2)).
Obtain and act on testing reports. ISPs must obtain a testing report that confirms testing compliance and, where specified, respond in writing with a structured risk matrix, risk assessments, risk ratings, actions, timeframes and residual risk ratings or reasons and alternatives for non-acceptance (s 2.3(3)-(4); s 2.4).
Meet specific biometric performance thresholds. For biometric matching algorithms, ISPs must demonstrate, with at least a 90% confidence interval, a false match rate of not more than 0.01% and a false non-match rate of not more than 3%, using ISO/IEC TS 19795-9:2019 procedures (s 2.5(2)(d) and (1)).
Retest when adding credential kinds and maintain a credential list. ISPs must maintain a list of credential kinds accepted by their eIDVT, including issuer and series/version, and retest eIDVTs when new credential kinds are added (s 2.7(6)-(7)).
Implement storage, zeroisation and cryptographic protections. The instrument requires memorised secrets to be salted and hashed with specified salt lengths and one-way functions (s 3.3 item 6); look-up secrets to be hashed with AACA and salted where entropy is below specified thresholds (s 3.4 item 5); immediate zeroisation of unencrypted keys and biometric samples in some authenticator types (s 3.6(6); s 3.8(4); s 3.7 and s 3.8 contain requirements about secure storage mechanisms).
Apply session and reauthentication rules. ISPs must enforce the reauthentication cadences in the AL Table and terminate sessions that exceed inactivity thresholds or persistent session time windows (s 3.1 item 2).
Implement rate limiting and throttling. ISPs must implement rate limiting for memorised secrets, look-up secrets and OTPs, protect against online guessing attacks and limit consecutive failed authentication attempts on a digital ID to no more than 100 (s 3.12 item 4).
Meet cryptographic strength and attestation standards. Attestation signatures must provide at least 112 bits of effective security strength, and cryptographic keys used for phishing resistance and AE-compromise resistance must meet minimum effective security strength levels and use AACA (s 3.12 items 1, 2 and 5).
Comply with out-of-band rules. If using out-of-band devices, ISPs must establish separate channels, uniquely authenticate devices, follow specific transfer and timing rules, and not use email or VoIP numbers for out-of-band verification (s 3.11 items 1-11). For PSTN use, there are additional verification, disclosure and alternative-offer duties (s 3.11(10)).

Duties on biometric testing entities

Meet accreditation and process requirements: ISO/IEC 17025 accreditation, personnel competence, approved human test-subject policies and adherence to specified ISO testing methods (s 2.2(1)(a)-(d)).
For eIDVT: be FIDO Accredited Laboratory and safeguard physical document fraud instruments (s 2.7(2)).

Rights and decision points

ISPs decide which permitted authenticator types to deploy at each AL subject to instrument constraints (s 3.1), and they select biometric testing entities provided those entities meet independence and competence criteria (s 2.2).
ISPs have a right to receive testing reports and to accept or reject testing findings, but if they reject findings they must give reasons and alternative mitigations with residual risk ratings (s 2.4).
Individuals have procedural protections embedded in certain provisions: ISPs must inform individuals of PSTN risks and offer at least one alternative authenticator (s 3.11(10)). The instrument also mandates certain protections for human test subjects used in biometric testing (s 2.2(1)(c)).

What decides compliance or non-compliance

The signposting of requirements and tests, and the obligation to obtain testing reports and produce responses (ss 2.3-2.4; 2.7(5)) make the production of correct reports and timely remediation a primary compliance mechanism. The instrument itself does not specify sanctions; compliance consequences will be governed by the Act and the Accreditation Rules under which accreditation is granted or withdrawn (s 1.3; s 1.4 referential notes).

The instrument sets detailed technical and procedural obligations but does not itself prescribe criminal penalties, civil pecuniary penalties, or an enforcement regime within its text. It is made under section 99 of the Digital ID Act 2024 (s 1.3), and it cross-references the Accreditation Rules for many definitions and interactions (s 1.4). Therefore enforcement and sanctioning mechanisms lie outside the instrument, in the Act and the Accreditation Rules, rather than in this instrument.

What is explicit in the instrument about enforcement mechanics

Testing and documentation as evidence. The instrument requires ISPs to obtain testing reports from a biometric testing entity and to maintain records such as lists of accepted credential kinds (s 2.3(4), s 2.7(5)-(6)). These reports and records are natural compliance evidence that an accreditor or regulator would examine in an audit or accreditation assessment under the Act or Accreditation Rules.
Independence and accreditation conditions. The instrument requires biometric testing entities to be independent of the ISP and, where relevant, accredited or FIDO-accredited (s 2.2(1)(b), s 2.2(1)(e), s 2.7(2)(a)). Failure to use appropriately accredited and independent test labs would leave an ISP without the documentary basis to demonstrate compliance with the data standards.
Obligations to respond to findings. ISPs must craft detailed written responses to testing findings with risk matrices, actions, timeframes and residual risk ratings (s 2.4). The presence or absence of such responses will be central to enforcement inquiries.

What is not present

No penalty clauses in the instrument text. The instrument does not prescribe fines, offences, or direct enforcement powers. It does not specify review or appeal paths, nor does it set time-limited cure periods or mandatory remediation deadlines beyond the requirement that ISPs state timeframes in their responses (s 2.4(b)(ii)).
No express administrative enforcement mechanism. Because the instrument is an instrument under the Act, the Act and the Accreditation Rules will be the legal texts that determine enforcement tools, sanctions, revocation of accreditation or other administrative measures. The instrument does not substitute those measures; it prescribes standards to be enforced via the accreditation regime.

Practical implication for compliance and enforcement

The instrument makes compliance demonstrable through testing reports, documented remediation plans and records. Enforcement under the Act/Accreditation Rules is likely to rely on those documentary artefacts. The instrument itself signals the evidentiary and procedural paths by which a regulator or accreditor can assess compliance but leaves the mechanics of sanctioning to the Act and Accreditation Rules (s 1.3; s 1.4).

The instrument expressly integrates other normative instruments and standards into its regime and preserves the definitional and enforcement architecture of the Digital ID Act and the Accreditation Rules.

Direct incorporations and cross-references

The instrument is made under the Digital ID Act 2024 and expressly uses terms defined in the Act and the Accreditation Rules; it states that expressions defined in the Accreditation Rules have the same meaning in this instrument (s 1.3; s 1.4(1)). This ties the data standards to the broader regulatory structure for accreditation, credential lists and other operational rules in the Accreditation Rules (see, for example, s 2.7(3)(a) which references rule 5.20 of the Accreditation Rules).
Incorporated instruments and standards. The instrument incorporates, by reference, international standards (ISO/IEC 17025:2017; ISO/IEC 19795-2:2007; ISO/IEC TS 19795-9:2019; ISO/IEC 30107-1:2023; ISO/IEC 30107-3:2023; ISO/IEC 24745:2022; ISO/IEC 2382-37:2022) and the FIDO document authenticity verification requirements (s 1.4 notes; ss 2.2, 2.3, 2.5, 2.7). Section 1.5 states that incorporated instruments are taken as in force at the commencement date.
Cryptographic guidance and national cyber guidance. The instrument references ASD-Approved Cryptographic Algorithms and the ISM Guidelines for Cryptography, anchoring cryptographic requirements to Australian Government cyber guidance (s 1.4 definitions for AACA and notes throughout Divisions 3 and 4 that require use of AACAs and ISM minimum strengths).

Overlap and operational interaction with privacy and other obligations

Privacy and data protection regimes. The instrument mandates handling, zeroisation and template protection standards (for example, ISO/IEC 24745:2022 template protection referred to in s 3.13(4)(c)(iv), and zeroisation requirements in ss 3.6(6), 3.7 and 3.8). These technical protections interact procedurally and substantively with any applicable privacy laws, but the instrument does not alter privacy law. ISPs will need to satisfy both these data standards and any statutory privacy obligations (for example under the Privacy Act 1988 if applicable). The instrument does not purport to supplant privacy obligations.
Accreditation Rules (and the Act). Several instrument provisions explicitly link to specific Accreditation Rules provisions (for example s 2.7(3)(a) references rule 5.20). The instrument must be read with the Accreditation Rules for the full operational picture of accreditation, reporting, and any enforcement processes.
International standard compliance. By mandating ISO and FIDO tests, the instrument channels ISPs towards internationally recognised testing regimes. Where international norms or supplier ecosystem agreements are relevant, ISPs will need to align both to this instrument and to those external standards.
Telecommunications and PSTN. The instrument places explicit constraints on out-of-band verification via PSTN, including verification that the pre-registered phone number is associated with a physical device and requirements to inform individuals of PSTN risks (s 3.11(10)). This intersects with consumer protection and communications regulation in practice, although the instrument does not reference particular communications statutes.

Constraints on incorporated instrument drift

Section 1.5 fixes the versioning: references to incorporated instruments are to their state at commencement. That makes the data standards stable against subsequent amendments to the incorporated external documents unless this instrument is itself amended.

In summary, the instrument is a technical overlay that must be read alongside the Digital ID Act and the Accreditation Rules and will operate in the factual environment of national cryptographic guidance, international ISO standards, FIDO testing regimes, and general privacy and telecommunications law. The instrument neither amends those regimes nor removes their application; it prescribes particular technical and testing standards that will sit alongside them.

This instrument was made and dated 7 November 2024 and is titled the Digital ID (Accreditation) Data Standards 2024, signed by the Minister for Finance acting as the Digital ID Data Standards Chair (front matter). The instrument states it commences at the same time as the Digital ID Act 2024 (s 1.2) and is made under s 99 of that Act (s 1.3). Beyond this initial instrument text, there are no recorded amendments within the document.

Key procedural mechanics relevant to amendments and incorporated content

Incorporation lock. Section 1.5 provides that if this instrument applies, adopts or incorporates any matter from another instrument or writing, the reference to the incorporated instrument is to its form as in force at the commencement of this instrument. That locks the incorporated external standards to their state at commencement, which is operationally important: subsequent updates to ISO standards, ISM guidance or the FIDO requirements are not automatically incorporated into the data standards without amendment to this instrument.
Transition for certain provisions. Section 1.6 identifies a limited transitional application: paragraph (b) in column 2 of item 3 of the table in section 3.13 (that is, the prohibition on using in-device biometric capability on devices that cannot receive OS security updates) applies to a "transitioned accredited entity" only from the day that is 12 months after commencement; all other provisions apply on commencement (s 1.6(1)-(2)). That is a deliberate phased application to give incumbents or previously accredited entities time to adapt to a specific device-update restriction.
No recorded prior versions or amendments. The instrument as provided includes no history of prior amendments, variations or revocations. If amendments are later made, those would be recorded in subsequent instruments or in the legislative or regulatory database where the instrument is published.

Practical effect for legal research and compliance

When checking compliance at any future date, practitioners must confirm whether any amending instrument or replacement data standards have been made since 7 November 2024. Because incorporated standards are fixed to commencement versions (s 1.5), compliance assessments must account for the versions specified in the instrument rather than later iterations of those external standards unless the instrument is amended.
The single transitional carve-out (s 1.6) is the only explicit temporising device; every other obligation is effective on commencement and should be treated as immediately applicable to ISPs and testing entities unless and until the instrument is amended.

The instrument itself does not reference any case law, and no litigation history is contained within the instrument text. It is an administrative instrument specifying technical standards and testing regimes; the text does not cite judicial decisions or administrative rulings, nor does it annex any decisions.

What the absence of litigation references means in practice

No cases named or relied upon. The instrument uses international standards and technical documents as its normative anchors rather than domestic judicial authority. All normative weight derives from the Act, Accreditation Rules and the referenced ISO/FIDO/ISM documents.
Prospective litigation pathways. Any legal challenges relating to the instrument’s application,such as disputes over accreditation decisions, the sufficiency of testing, or whether an ISP met the prescribed standards,would be litigated under the Digital ID Act and the Accreditation Rules or judicial review principles in administrative law. The instrument itself does not specify remedies or precedent.
Evidence in disputes. The instrument's prescriptive testing and reporting requirements mean that testing reports, laboratory accreditation credentials and the ISP’s written responses (required by s 2.4) will be central documents in any legal or administrative review. Disputes are more likely to be factual (whether a biometric testing entity performed testing in accordance with ISO/IEC 30107-3:2023, for example) than doctrinal in relation to the instrument’s legal basis.

Current status

As provided, no litigation history is recorded in the instrument; practitioners should check the Digital ID Act and the Accreditation Rules, and any administrative decisions made under them, for any disputes or case law that arise after commencement. Litigation, if it occurs, will likely engage the technical standards mandated here (ISO, FIDO, ISM guidance) as questions of fact and expert evidence.

The instrument is detailed and prescriptive; several provisions create traps for the unprepared ISP, and compliance requires coordinated legal, product and testing workflows. The following are concrete operational and legal pitfalls directly traceable to the text.

Independence and lab accreditation requirements (s 2.2). Biometric testing must be done by a person who uses an ISO/IEC 17025:2017 accredited laboratory and is independent from the ISP’s design, implementation, operation and management. If the ISP uses a lab that is part of its corporate group or that lacks the required ISO accreditation, the testing will not meet the instrument’s requirements (s 2.2(1)(b), (e)). For eIDVT, the testing entity must additionally be a FIDO Accredited Laboratory (s 2.7(2)(a)). This may require outsourcing to external labs and paying lab fees and logistics costs.
Stringent PAD APCER thresholds and sample structures (s 2.3). Presentation attack instrument species used in testing must meet an APCER of 0% for many species, and tests must include at least 6 level A and 6 level B species with a minimum of 10 individuals (s 2.3(3)(a)-(b)). For some scenarios, the instrument permits supplementary testing and sets a limited tolerance (one level B species up to 5% APCER) but requires risk ratings and mitigations if that tolerance is used (s 2.3(3)(3)). ISPs relying on custom biometric capability face a different ceiling (APCER no more than 10% for custom capabilities per s 3.13 cross-reference and the note in s 2.3). Meeting 0% APCER across species may be operationally difficult and expensive.
Biometric matching algorithm performance mandated with a 90% confidence interval (s 2.5). The algorithm must demonstrate FMR ≤ 0.01% and FNMR ≤ 3%, with a 90% confidence interval, tested per ISO/IEC TS 19795-9:2019. ISPs using off‑the‑shelf matchers must ensure their operational configuration achieves these metrics; otherwise, retuning or replacement, plus retesting, will be necessary.
Retesting obligations when adding new credential kinds to eIDVT (s 2.7(7)). ISPs must retest their eIDVT when adding new kinds of credentials to the set of accepted credentials. That creates a recurring cost and process requirement where credential support is expanded or varies by geography or issuer.
Zeroisation and secure storage obligations (ss 3.6(6), 3.7-3.8). The instrument requires immediate zeroisation of unencrypted keys and, in several cases, biometric samples after OTP generation or authentication (s 3.6 item 6; s 3.8 item 4). Secure storage mechanisms must use keychain storage, TPM, TEE or secure element for cryptographic keys (ss 3.7 and 3.8). Implementing secure storage across application variants and platforms will be resource-intensive; platform heterogeneity creates operational complexity.
Strong cryptographic strength and AACA requirement (multiple provisions). Several provisions require use of AACA and an effective security strength of at least 112 bits for keys used in phishing resistance, AE-compromise resistance and attestation signatures (s 3.12 items 1, 2 and 5). ISPs must ensure their cryptographic stacks meet ASD recommendations and the ISM Guidelines for Cryptography; otherwise, they must upgrade or reconfigure cryptographic libraries.
Out-of-band limitations and PSTN warnings (s 3.11). The instrument prohibits use of email and VoIP numbers for out-of-band verification and imposes explicit verification, disclosure and alternative-offer obligations if PSTN is used (s 3.11(10)-(11)). ISPs that currently rely on SMS or voice over IP must reconsider those flows and ensure compliance with the device-association and user-notification obligations.
Session timing and reauthentication strictness (s 3.1 item 2). AL2 requires reauthentication of persistent sessions after 12 hours regardless of activity, and AL3 requires reauthentication after 12 hours and inactivity thresholds of 15 minutes (s 3.1). These short windows may disrupt customer UX and require reengineering session-management infrastructure.
Rate-limiting numeric cap. The instrument caps consecutive failed authentication attempts at no more than 100 (s 3.12 item 4(2)). While this is a permissive ceiling relative to some tighter schemes, the requirement to implement rate limiting across specific authenticator types and to document the controls means ISPs must maintain consistent throttling behaviour and logging.
Transitional carve-out nuance (s 1.6). The prohibition on using in-device biometric capability on devices that cannot receive OS security updates does not apply to a transitioned accredited entity for 12 months, but the rest of the instrument applies immediately. ISPs that are transitioned entities must track that specific delayed deadline and update device eligibility after 12 months.

Operationally, these provisions translate into concentration of costs on testing, cryptographic and platform upgrades, retesting cycles when credential sets change, and reengineering session and authentication flows. The instrument converts performance thresholds and test reports into documentary evidence that accreditation operations will rely upon. ISPs must plan for lab scheduling, test data preparation (including diverse demographic representation and physical fraud instrument handling), and documentation of responses to testing findings (s 2.4).

This section is a practical checklist mapped to the main provisions. It assumes the reader is advising or operating an ISP subject to the instrument. Each step references the relevant sections.

Governance and planning

Identify whether your entity is a “transitioned accredited entity” and, if so, track the 12‑month delay for the device OS-update prohibition in s 3.13(3)(b) (see s 1.6).
Appoint a compliance lead responsible for coordinating testing, cryptography, privacy and platform engineers and a legal contact to integrate obligations with Accreditation Rules and the Digital ID Act (s 1.3-1.4).

Biometric testing entity selection and independence (s 2.2)

Select a biometric testing entity that meets s 2.2(1): personnel experienced in biometric testing; ISO/IEC 17025:2017‑accredited lab certified for biometric testing; an approved human test-subject policy; established test methods informed by ISO/IEC 30107-3:2023 and ISO/IEC 19795-2:2007 where applicable; and independence from your organisation (s 2.2(1)(a)-(e)).
For eIDVT, ensure the lab is a FIDO Accredited Laboratory and can demonstrate secure management of physical document fraud instruments (s 2.7(2)).

Prepare test plans and datasets (ss 2.3, 2.5, 2.7)

For PAD testing, ensure test sets include at least 6 level A and 6 level B presentation attack instrument species, a minimum of 10 individuals and per-species instruments covering at least 3 individuals as required by s 2.3(3)(a)-(b).
For biometric matcher testing, prepare operationally representative samples with demographic diversity including disability, age, gender and ethnicity, and ensure testing will produce FMR ≤ 0.01% and FNMR ≤ 3% with a minimum 90% confidence interval per s 2.5(2)(c)-(d).
For eIDVT, assemble digital and physical test sets per s 2.7(4): at least 300 images for each digital test set input; minimum counts per supported document type; at least 100 physical document fraud instruments in physical testing with specified composition; ensure document false reject rate ≤1% and false accept rate ≤1% for both digital and physical testing.

Legal and contractual steps

Contract with the biometric testing entity to deliver reports that explicitly confirm testing was conducted per ISO/FIDO and the instrument requirements. The ISP must obtain and keep the report (s 2.3(4)(a)(i); s 2.7(5)(a)).
Include confidentiality and secure handling clauses covering physical document fraud instruments and test data, as eIDVT requires responsible management of physical fraud instruments by the testing entity (s 2.7(2)(c)).

Implement cryptography and storage protections

Adopt ASD-approved cryptographic algorithms (AACA) and ISM Guidelines for Cryptography where required (s 1.4; multiple references in Divisions 3-4).
For memorised secrets, implement salting and hashing using a suitable one-way key derivation function; salt length must be at least 32 bits and stored alongside the hash (s 3.3 item 6).
For look-up secrets with less than 112 bits of entropy, apply salt of at least 32 bits and hash with an AACA (s 3.4 item 5).
Ensure cryptographic keys used for phishing resistance, AE-compromise resistance and attestation provide at least 112 bits of effective security strength as required (s 3.12 items 1, 2, 5).

Build authenticator workflows to meet AL Table requirements (s 3.1)

Map which authenticators will be used at AL1, AL2 and AL3 and implement the corresponding mandatory security properties: MitM resistance at all levels; replay resistance at AL2/AL3; phishing resistance, AE-compromise resistance and authentication intent at AL3; and manage reauthentication windows per item 2 of the AL Table (s 3.1).
For AL3, implement phishing-resistant protocols that establish an authenticated protected channel and cryptographically bind a channel identifier to the authentication output (s 3.12(1)).

Implement session management and reauthentication

Ensure session lifetimes and inactivity thresholds match s 3.1 item 2: AL1 30-day reauthentication for persistent sessions using at least one factor; AL2 persistent sessions reauthenticate after 12 hours and 30-minute inactivity threshold; AL3 persistent sessions reauthenticate after 12 hours and 15-minute inactivity threshold, with specified factor requirements for reauthentication.

OTP, cryptographic device and out-of-band implementation specifics

For single- and multi-factor OTP devices, implement nonces, uniqueness, time-based lifetimes and nonce-change cadence per ss 3.5 and 3.6. Ensure one-time use enforcement and zeroisation of unencrypted keys and activation secrets (s 3.6 items 4-7).
For cryptographic software and hardware authenticators, use secure storage mechanisms listed in ss 3.7 and 3.8 (keychain, TPM, TEE or secure element), protect keys against modification and disclosure, and ensure challenge nonces meet length and uniqueness requirements.
For out-of-band devices, implement the separate-channel and device-authentication rules, 10-minute transaction timeouts, at least 20 bits of entropy for random authentication secrets and the PSTN-specific checks, user notifications and alternative-offer obligations (s 3.11 items 1-10).

Biometric-specific implementation (s 3.13 and Part 1)

Decide whether to use in-device biometric capability or custom biometric capability. In-device biometrics may only be used for AL1 or AL2 and must not operate on devices that cannot receive OS security updates (s 3.13(3)). Note the transitional delayed application to transitioned accredited entities for the OS-update prohibition (s 1.6).
If using custom biometric capability, set up an authenticated protected channel between sensor and ISP IT system before capture, run PAD that includes liveness detection, ensure biometric matching is one-to-one and either local or centrally performed under specified conditions (s 3.13(4)).
Submit the presentation attack detection mechanism to PAD testing per s 2.3 and ensure APCER thresholds are complied with. For custom biometric capability specific APCER rules apply (s 3.13(4)(k)).

Testing, reporting and remediation

Arrange testing with the chosen biometric testing entity and obtain reports confirming compliance with ISO/FIDO and the instrument (ss 2.3(4); 2.7(5)).
Prepare written responses to testing reports conforming to s 2.4: risk matrix, risk assessments, risk ratings, specific actions to treat risks with timeframes and residual risk calculations; for non-accepted risks provide reasons, alternative actions and residual risk expectations.
Maintain records of accepted credentials (kind, issuer, series/version) and retest whenever new credential kinds are included in eIDVT verification (s 2.7(6)-(7)).

Monitoring, audits and updates

Ensure ongoing audit readiness: keep test reports, response documents, cryptographic configuration records, attestation records and credential lists available for review by accreditors or regulators under the Act and Accreditation Rules.
Monitor for shifts in the referenced external standards and plan for formal instrument amendments if you wish to adopt newer versions; the instrument fixes incorporated standards to their commencement state (s 1.5).

Platform and UX considerations

Plan user journeys around reauthentication cadences and device constraints (for example, AL3 constraints on biometric usage) and provide alternatives where PSTN is used, per s 3.11(10).
Implement telemetry to detect repeated PAD failures and to apply the mandated progressive delays or disable custom biometric capability and offer alternate factors after five consecutive failed biometric attempts (s 3.13(4)(g)).

In summary, compliance requires a structured project to align technical architecture, cryptography, biometric testing, legal contracting with labs, documentation and user experience. The instrument sets precise technical markers and testing outputs that will form the evidence base in accreditation and any subsequent regulatory assessments, so the practical compliance focus should be on demonstrable testing, secure storage and documented remediation plans as specified in ss 2.3-2.5 and s 2.4.

Digital ID (Accreditation) Data Standards 2024

Plain English Summary

Deep Dive

What it does

Current sections