identification standards consolidated

---
layout: raw-data.njk
title: "identification standards consolidated"
---

# Identification Management Standards

## Section 1: Understanding Conformance with Identification Standards
### This section helps you determine whether your organization needs to conform with the Identification Standards and explains how the conformance process works.

### Why Conform?

The Identification Standards provide a comprehensive framework for establishing and verifying the identity of individuals and entities in New Zealand's digital economy. Conformance demonstrates that your identification processes meet nationally recognized requirements for security, privacy, and reliability.

You benefit from conformance through:

* **Risk reduction** — Apply tested controls that mitigate identification risks
* **Trust establishment** — Show other parties they can rely on your identity assertions
* **Regulatory alignment** — Meet obligations under the Digital Identity Services Trust Framework (DISTF)
* **Operational efficiency** — Use proven processes rather than developing your own
* **Interoperability** — Connect with other conformant services through standardized approaches

### Is This Relevant to You?

#### Mandatory Conformance

You **must** conform with the Identification Standards if you:

* Provide identification services under the **Digital Identity Services Trust Framework (DISTF)** ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part1))
* Act as a **Relying Party** accepting DISTF credentials
* Operate as a **Credential Provider** issuing reusable identity credentials
* Function as a **Facilitation Provider** enabling credential presentation

The DISTF establishes New Zealand's primary framework for digital identity services. These standards form the technical backbone of DISTF conformance — you cannot achieve DISTF accreditation without meeting the relevant Identification Standards.

#### Voluntary Conformance

You **should consider** conforming if you:

* Handle sensitive personal information requiring identity verification
* Need to establish trust with government agencies or regulated entities
* Want to reduce identification-related fraud and errors
* Plan to integrate with DISTF services in the future
* Seek best practice guidance for identification processes

Even without DISTF obligations, conformance provides valuable structure and assurance for any identification system.

### Your Role in the Identification Ecosystem

Understanding your role determines which standards apply to you. Organizations typically operate in one or more of these roles:

#### Relying Party (RP)
You rely on identity information provided by others to make decisions or provide services. Examples include:
* Banks verifying customer identity for account opening
* Government agencies confirming eligibility for services
* Employers validating employee credentials

**Applicable standards**: Information Assurance, Binding Assurance, Authentication Assurance

#### Credential Provider (CP)
You create and issue reusable credentials that others rely upon. Examples include:
* Digital identity providers issuing verified identity credentials
* Professional bodies issuing membership credentials
* Educational institutions issuing qualification credentials

**Applicable standards**: All four standards, with emphasis on Federation Assurance

#### Facilitation Provider (FP)
You provide mechanisms for presenting or verifying credentials without issuing them. Examples include:
* Digital wallet providers
* Identity exchange platforms
* Verification service providers

**Applicable standards**: Federation Assurance (Part 2), plus standards relevant to verification activities

### Overview of the Conformance Process

The conformance process follows three stages, each building on the previous:

#### Stage 1: Understand Your Requirements
Determine which role you play and which standards apply to your service ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart1-para1)). This involves:
* Identifying your role(s) in the identification ecosystem
* Reviewing applicable standards and controls
* Assessing your current capabilities against requirements
* Planning implementation of missing controls

#### Stage 2: Gather and Document Evidence
Compile documentation showing how you meet each relevant control ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)). You will:
* Complete conformance checklists for your applicable standards
* Cross-reference existing documentation to controls
* Develop new documentation where needed
* Organize evidence for efficient assessment

#### Stage 3: Undergo Assessment
Choose your assessment path and work with assessors to verify conformance ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart3)). Options include:
* **Self-assessment** — Internal review for understanding readiness
* **Qualified assessment** — External opinion on conformance gaps
* **Audited assessment** — Full verification resulting in conformance statement

### How to Navigate This Document

This consolidated guide brings together all Identification Standards and supporting guidance into a single resource. The nine sections follow a logical progression from understanding requirements through achieving conformance:

#### Foundation Sections (Start Here)
* **Section 1** (this section) — Understanding conformance requirements and relevance
* **Section 2** — [Assessing your identification risk](#section-2-assessing-your-identification-risk) to determine appropriate controls
* **Section 3** — [Selecting your assurance levels](#section-3-selecting-your-assurance-levels) based on risk assessment

#### Core Standards (Apply Based on Your Role)
* **Section 4** — [Federation Assurance Standard](#section-4-federation-assurance-standard) for credential and facilitation providers
* **Section 5** — [Information Assurance Standard](#section-5-information-assurance-standard) for establishing information quality
* **Section 6** — [Authentication Assurance Standard](#section-6-authentication-assurance-standard) for maintaining authenticator control
* **Section 7** — [Binding Assurance Standard](#section-7-binding-assurance-standard) for linking entities to information

#### Implementation Support
* **Section 8** — [Demonstrating conformance](#section-8-demonstrating-conformance) through assessment and evidence
* **Section 9** — [Reference materials](#section-9-reference-materials) including terminology, templates, and tools

### Entry Points by User Type

Different users should start at different points based on their objectives:

#### For Implementers
Start with **Section 2** to assess your identification risks, then proceed to **Section 3** to select appropriate assurance levels. Review the relevant standards in **Sections 4-7** based on your role, focusing on the implementation guidance for each control.

#### For Assessors and Auditors
Begin with **Section 8** to understand the conformance assessment process and evidence requirements. Reference the core standards in **Sections 4-7** for control details, and use the checklists in **Section 8.3** to structure your assessment.

#### For Policy Makers and Executives
Read this section first for context, then review **Section 2** to understand risk considerations. Focus on the rationale sections within each standard (**Sections 4-7**) to understand the policy intent behind controls.

#### For Technical Architects
Start with **Section 3** to understand the assurance level framework, then dive into the technical controls in **Sections 4-7**. Pay particular attention to the implementation guidance and examples within each standard.

### Conformance Is a Journey

Achieving conformance with the Identification Standards requires planning, implementation, and ongoing maintenance. Organizations typically progress through several phases:

1. **Discovery** — Understanding requirements and assessing current state
2. **Gap Analysis** — Identifying controls that need implementation or improvement
3. **Implementation** — Building or enhancing processes to meet controls
4. **Documentation** — Creating evidence of control implementation
5. **Assessment** — Verifying conformance through chosen assessment type
6. **Maintenance** — Keeping conformance current as standards and services evolve

Most organizations find that they already meet many controls through existing practices. The standards provide structure and consistency rather than requiring wholesale process replacement.

### Getting Started

Take these first steps to begin your conformance journey:

1. **Identify your role** — Determine whether you act as a Relying Party, Credential Provider, or Facilitation Provider
2. **Assess your risk** — Work through [Section 2](#section-2-assessing-your-identification-risk) to understand your identification risks
3. **Select assurance levels** — Use [Section 3](#section-3-selecting-your-assurance-levels) to map risks to appropriate controls
4. **Review applicable standards** — Study the controls in Sections 4-7 relevant to your role
5. **Plan your approach** — Decide on self-assessment, qualified assessment, or audited assessment
6. **Contact the Identification Team** — Email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/) for guidance and support

Remember that conformance is not just about meeting requirements — it's about building trustworthy identification services that protect both your organization and the individuals who rely on your services.

### Support and Resources

The Identification Team at Te Tari Taiwhenua (Department of Internal Affairs) provides ongoing support for organizations seeking conformance:

* **Email**: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)
* **Guidance**: Access all standards and guidance at [digital.govt.nz](https://www.digital.govt.nz/standards-and-guidance/identification-management/)
* **Tools**: Download conformance checklists and templates from [Section 9](#section-9-reference-materials)
* **Updates**: Subscribe to notifications about standard changes and new guidance

Take advantage of these resources early in your conformance journey to avoid common pitfalls and accelerate your progress toward achieving conformance.

### Next Steps

Now that you understand the conformance framework and its relevance to your organization, proceed to:

* **[Section 2: Assessing Your Identification Risk](#section-2-assessing-your-identification-risk)** — Learn how to evaluate the two types of identification risk and determine appropriate mitigation strategies
* **[Section 8: Demonstrating Conformance](#section-8-demonstrating-conformance)** — Understand the detailed conformance process if you're ready to begin assessment
* **[Section 9: Reference Materials](#section-9-reference-materials)** — Access terminology definitions if you encounter unfamiliar terms

Your path through this document will depend on your specific needs and role, but these sections provide the essential foundation for any conformance effort.


## Section 2: Assessing Your Identification Risk

#### Learn how to conduct an identification risk assessment for your service. Use this assessment to select the right strength of identification processes to protect against information fabrication and identity theft.

### 2.1 Introduction to Identification Risk

Every digital service that collects, stores, or relies on identity information faces identification risk. Understanding these risks allows you to implement proportionate controls that protect both your organization and the individuals who use your services ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-para1)).

Before implementing any identification controls, assess the specific risks your service faces. This assessment forms the foundation for selecting appropriate assurance levels (covered in [Section 3](#section-3-selecting-your-assurance-levels)) and implementing relevant standards (covered in [Sections 4-7](#section-4-federation-assurance-standard)).

#### Why Assess Identification Risk?

Identification risk assessment serves multiple purposes:

* **Right-size your controls** — Avoid over-engineering low-risk services or under-protecting high-risk ones
* **Allocate resources effectively** — Focus effort where risk is highest
* **Meet compliance requirements** — Document your risk-based approach for conformance assessment
* **Build stakeholder confidence** — Demonstrate that you understand and manage identification threats
* **Enable informed decisions** — Base control selection on evidence rather than assumptions

An identification risk assessment complements your wider risk management program. While you may already have security and privacy assessments, identification risk requires specific analysis of how entities might misrepresent themselves or their information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-para2)).

#### When to Assess Risk

Conduct an identification risk assessment:

* **Before launching a new service** — Build appropriate controls from the start
* **When modifying existing services** — Ensure changes don't introduce new risks
* **Following an incident** — Learn from actual events to strengthen controls
* **During regular reviews** — Keep pace with evolving threats and techniques
* **When regulations change** — Ensure continued compliance with new requirements

### 2.2 The Two Types of Identification Risk

Identification encompasses two distinct risks that require different mitigation approaches ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part1-para1)):

#### Risk 1: Incorrect Information About Entities

This risk occurs when someone provides false, fabricated, or inaccurate information during enrollment or service use. The incorrect information leads to inappropriate service delivery — either granting access to those who shouldn't have it or denying it to legitimate users ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part1-para2)).

**Examples of Risk 1 scenarios**:
* Someone claims a false qualification to access professional services
* An individual provides incorrect address information to avoid location-based restrictions
* A person misrepresents their age to access age-restricted content or benefits
* An entity fabricates business information to qualify for grants or contracts

**Mitigation approach**: Verify information accuracy through the [Information Assurance Standard](#section-5-information-assurance-standard). Implement controls that check information against authoritative sources and detect inconsistencies.

#### Risk 2: Incorrect Binding and Authentication

This risk occurs when someone successfully impersonates another person by using their information or authenticator. The impersonator gains advantages they're not entitled to, avoids obligations, or causes harm to the legitimate identity holder ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part1-para4)).

**Examples of Risk 2 scenarios**:
* Someone uses stolen credentials to access another person's bank account
* An individual presents someone else's identity document to avoid criminal charges
* A person uses compromised login details to access confidential records
* An entity takes over another's online account to damage their reputation

**Mitigation approach**: Strengthen binding and authentication through the [Binding Assurance Standard](#section-7-binding-assurance-standard) and [Authentication Assurance Standard](#section-6-authentication-assurance-standard). Implement multi-factor authentication, biometric verification, and account recovery controls.

#### Understanding Threat Actors

Consider who might attack your service and why. This understanding helps you design targeted defenses ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part1-subpart1-para1)).

**Table 1:** Main motives for identity theft and information fabrication ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part1-subpart1-para3))

| Motive | Description | Typical Actors |
|---|---|---|
| **Gain** | Access money, goods, services or information illegitimately | Customers who understand service value, professional scammers, organized crime groups |
| **Misrepresentation** | Use another's identity, qualifications or reputation to perform restricted activities or avoid obligations | Competitors, criminals avoiding detection, terrorists, individuals seeking unearned advantages |
| **Personal Attack** | Cause financial loss, reputational damage, physical or emotional harm to a specific target | Ex-partners, disgruntled employees, business competitors, stalkers |
| **Nuisance** | Disrupt services for entertainment or out of boredom, typically without specific targets | Hackers, trolls, individuals with no particular agenda |

### 2.3 Risk Assessment Methodology

Follow this structured approach to assess identification risk for your service ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-para3)):

#### Step 1: Determine If Risk Exists

First, establish whether your service faces identification risk. Answer these five questions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part2-para1)):

1. Can anyone receive money or incur a cost through using the service?
2. Can anyone receive other benefits through using the service?
3. Does the service collect and store information about entities?
4. Can the service result in release of personal or sensitive information?
5. Can the service issue documents or data that could later serve as identity evidence?

If you answer "Yes" to any question, conduct a full identification risk assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part2-para2)).

**Services without identification risk** include ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part2-det2-para1)):
* Providing non-sensitive information or advice
* Distributing public forms or documents
* Collecting payments without creating accounts
* Publishing general guidance or news

#### Step 2: Map Information Collection

Document what information your service collects and uses ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-para3-1)):

* **Identity attributes** — Name, date of birth, address, contact details
* **Credentials** — Government IDs, professional licenses, qualifications
* **Verification data** — Biometrics, photographs, signatures
* **Relationship information** — Family connections, employer details, references
* **Transaction history** — Previous interactions, account activity, behavioral patterns

Understanding your information landscape helps identify what attackers might target and what needs protection.

#### Step 3: Identify Consequences

For each risk type, identify potential consequences if an attack succeeds. Consequences typically fall into these categories ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-det3-para1)):

##### Financial Loss or Liability
* Direct monetary loss from fraudulent transactions
* Costs of investigation and remediation
* Regulatory fines for compliance failures
* Legal liability from harm to affected parties

##### Unauthorized Information Release
* Exposure of personal or sensitive data
* Breach of confidentiality agreements
* Violation of privacy legislation
* Intelligence or commercial advantage to competitors

##### Reputation and Qualification Damage
* Loss of public trust in your service
* Damage to professional standing
* Fraudulent use of qualifications or certifications
* Undermining of credentialing systems

##### Other Impacts
* Breach of legislation or policy requirements
* Denial of critical services (medical treatment, emergency assistance)
* Circumvention of legal obligations (fines, sanctions)
* Enablement of further criminal activity

#### Step 4: Assess Impact Severity

For each identified consequence, assess its severity using this scale ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-det4-para2)):

* **Minimal** — Negligible effect on operations or individuals
* **Minor** — Limited impact that can be quickly resolved
* **Moderate** — Noticeable disruption requiring significant response
* **Significant** — Serious harm requiring major remediation efforts
* **Severe** — Catastrophic damage threatening service viability

Consider impacts on all affected parties ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-det4-para1)):
* Your organization (financial, operational, reputational)
* Individual users (privacy, financial, safety)
* Third parties relying on your assertions
* Broader systems and infrastructure

**Important**: Only assess direct consequences of identification failure. Avoid including indirect or downstream effects that might inflate your risk assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section1-para1)).

#### Step 5: Evaluate Existing Controls

Identify controls already in place and assess their effectiveness ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-det5-para1)). Four types of controls contribute to risk reduction ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section2-para1)):

* **Preventative** — Stop attacks before they succeed (e.g., identity verification, access controls)
* **Corrective/Reductive** — Limit damage when attacks occur (e.g., transaction limits, isolation mechanisms)
* **Detective** — Identify attacks for response and future prevention (e.g., monitoring, auditing)
* **Directive/Disincentive** — Reduce attack likelihood through policies, training, or low value targets

**Note**: Don't count identification processes themselves as controls at this stage — you'll determine their required strength based on the risk assessment outcome ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section2-para6)).

#### Step 6: Determine Likelihood

Assess how likely each consequence is to occur given your current controls ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-det6-para1)):

* **Rare** — Robust controls prevent all but exceptional circumstances
* **Unlikely** — Many controls with minor gaps allowing limited exploitation
* **Possible** — Several controls with gaps enabling occasional success
* **Likely** — Minimal controls making successful attacks probable
* **Almost certain** — No effective controls to prevent attacks

Base likelihood assessments on ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section3-para1)):
* Evidence from similar services in your organization
* Industry data on identification fraud rates
* Published threat intelligence and attack trends
* Expert security and fraud prevention advice

Never assume attacks won't happen simply because they haven't occurred yet ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section3-ex1)).

#### Step 7: Calculate Risk Level

Plot impact and likelihood for each risk using the risk matrix below. This produces one of 25 possible risk levels ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section3-det1)):

**Figure 1: Risk Matrix**
![Risk matrix for plotting impact and likelihood](../../files/risk-matrix.png/)

Use the highest risk level for each risk type as your overall risk rating.

#### Step 8: Map to Assurance Levels

Convert your risk levels to required identification process strength ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section4-para1)):

**Table 2:** Risk level to identification process strength ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section4-para3))

| Risk 1 Level | Risk 2 Level | Required Strength |
|---|---|---|
| 1–3 | 1–3 | **Negligible** — Level 1 |
| 4-6 | 4-10 | **Low** — Level 2 |
| 7-19 | 11-19 | **Moderate** — Level 3 |
| 20-25 | 20-25 | **High** — Level 4 |

These levels correspond to three identification processes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part3-section4-para4)):
* **Information verification** (addresses Risk 1) — [Information Assurance Standard](#section-5-information-assurance-standard)
* **Entity binding** (addresses Risk 2) — [Binding Assurance Standard](#section-7-binding-assurance-standard)
* **Authenticator control** (addresses Risk 2) — [Authentication Assurance Standard](#section-6-authentication-assurance-standard)

Proceed to [Section 3: Selecting Your Assurance Levels](#section-3-selecting-your-assurance-levels) to understand how to express and implement these requirements.

### 2.4 Threat Modeling

Develop a comprehensive understanding of threats to your identification system. This analysis helps you anticipate attack methods and design appropriate defenses.

#### Common Attack Vectors

Understand how attackers typically compromise identification systems:

##### Information Fabrication Attacks
* **Synthetic identity creation** — Combine real and fake information to create new identities
* **Document forgery** — Create or modify physical or digital credentials
* **Social engineering** — Manipulate staff to accept false information
* **Data manipulation** — Alter information in transit or storage
* **Insider threats** — Exploit privileged access to insert false records

##### Identity Takeover Attacks
* **Credential theft** — Steal passwords, tokens, or other authenticators
* **Phishing** — Trick users into revealing authentication details
* **Account recovery exploitation** — Abuse password reset or recovery processes
* **Session hijacking** — Take over authenticated sessions
* **Man-in-the-middle** — Intercept and relay authentication exchanges

#### Identifying System Vulnerabilities

Examine your system for weaknesses attackers might exploit:

* **Weak evidence requirements** — Accepting easily forged or obtained documents
* **Single factor authentication** — Relying solely on passwords or other single factors
* **Inconsistent verification** — Applying different standards across channels
* **Poor session management** — Allowing concurrent sessions or weak timeout policies
* **Inadequate monitoring** — Failing to detect unusual patterns or repeated attempts

#### Threat Prioritization

Focus defenses on the most significant threats by considering:

* **Likelihood** — How probable is this attack given current trends?
* **Impact** — What damage would a successful attack cause?
* **Capability required** — What skills and resources does the attack need?
* **Detection difficulty** — How hard is it to identify this attack?
* **Mitigation complexity** — How difficult is defense implementation?

Document your threat model and update it regularly as new attack techniques emerge and your service evolves.

### 2.5 Counter-Fraud Techniques

Apply these specialized techniques to strengthen your identification processes, especially where standard controls prove insufficient ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part1-para2)).

#### Managing Coercion and Collusion

##### Preventing Coercion

Coercion occurs when someone forces an entity to act against their will. Protect against coercion through ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part3-para1)):

* **In-person verification** — Conduct enrollment face-to-face when possible
* **Video verification** — Train staff to recognize coercion signs during video calls
* **Duress signals** — Implement hidden alerts users can trigger when forced
* **Transaction limits** — Restrict high-risk actions when coercion indicators appear
* **Cooling-off periods** — Require time delays for significant changes

Consider potential harm to coerced individuals when designing these controls ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part3-para6)).

##### Detecting Collusion

Collusion involves multiple parties working together to undermine your processes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part3-subpart1)):

* **Segregate duties** — Require multiple independent approvals for sensitive actions
* **Rotate responsibilities** — Change staff assignments to disrupt collusion networks
* **Implement biometrics** — Use biometric factors to ensure willing participation
* **Cross-check information** — Verify details across multiple independent sources
* **Monitor relationships** — Detect connections between supposedly unrelated parties

#### Handling Limited Evidence

Some legitimate users lack standard identity evidence. Accommodate them without compromising security ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part4-para1)):

##### Alternative Evidence Sources
* **Trusted referees** — Accept attestations from recognized professionals or community leaders
* **Progressive establishment** — Build identity confidence through repeated interactions over time
* **Derived credentials** — Accept credentials issued by other verified services
* **Biometric enrollment** — Use biometrics when documentary evidence is unavailable
* **Exception processes** — Provide supervised alternative pathways for edge cases

##### Special Populations
Design specific processes for groups with limited evidence access:
* **Children** — Use parent/guardian attestation with age-appropriate verification
* **Recent arrivals** — Accept foreign documents with appropriate verification
* **Vulnerable populations** — Partner with social services for verification support
* **Remote communities** — Provide mobile enrollment or remote verification options

#### Weak Evidence Quality

Strengthen processes when available evidence is unreliable ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part5)):

* **Multiple sources** — Require evidence from independent sources
* **Liveness detection** — Verify documents are current, not copies
* **Cryptographic verification** — Check digital signatures and security features
* **Database verification** — Validate against authoritative registers
* **Pattern analysis** — Detect reuse of evidence across multiple identities

#### De-duplication Strategies

Prevent individuals from creating multiple identities ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part6)):

* **Biometric matching** — Compare biometrics against existing enrollments
* **Fuzzy matching** — Detect similar but not identical information patterns
* **Device fingerprinting** — Identify reuse of devices across accounts
* **Behavioral analysis** — Recognize patterns indicating the same user
* **Cross-system checking** — Share fraud indicators with other services (with appropriate privacy controls)

#### Binding Techniques

Strengthen the connection between entities and their information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part7)):

##### Death Register Checking
Verify individuals are alive when claiming identity:
* Check against official death registers where authorized
* Require recent interactions for high-risk transactions
* Implement periodic re-verification for long-term relationships

##### Trusted Referee Processes
Use community verification for binding:
* Define eligible referee categories (professionals, community leaders)
* Verify referee identity independently
* Limit number of attestations per referee
* Monitor for referee compromise or collusion

##### Use Over Time
Build confidence through repeated interactions:
* Start with low-risk transactions
* Gradually increase access as history builds
* Monitor for behavior changes indicating compromise
* Combine with other verification methods for high-risk actions

#### Authentication Analytics

Detect fraudulent authentication attempts through analysis ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part8)):

##### Location Analysis
* **Impossible travel** — Detect logins from distant locations in unrealistic timeframes
* **Unusual locations** — Flag access from new or suspicious geographic areas
* **Location consistency** — Verify location matches claimed address or usual patterns
* **VPN detection** — Identify use of location-masking technologies

##### Temporal Analysis
* **Unusual times** — Detect access outside normal patterns
* **Velocity checking** — Identify abnormally frequent authentication attempts
* **Session patterns** — Recognize suspicious session durations or frequencies
* **Time zone mismatches** — Detect inconsistencies between claimed and actual locations

##### Behavioral Analysis
* **Typing patterns** — Recognize changes in keyboard dynamics
* **Navigation patterns** — Detect unfamiliar ways of using the service
* **Transaction patterns** — Identify unusual transaction types or amounts
* **Device patterns** — Recognize new or modified devices

#### Risk Profiling

Develop profiles to identify high-risk entities or transactions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part9)):

* **Entity risk scores** — Calculate risk based on identity attributes and history
* **Transaction risk scores** — Assess risk for each transaction type and context
* **Peer comparison** — Compare behavior against similar user cohorts
* **Machine learning models** — Use AI to detect subtle fraud patterns
* **Dynamic adjustment** — Update profiles based on new information and trends

Apply proportionate controls based on risk profiles while avoiding discriminatory profiling.

#### Discrepancy Handling

Respond appropriately when information doesn't match expectations ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part10)):

* **Graduated responses** — Apply increasing scrutiny for repeated discrepancies
* **Alternative verification** — Offer different verification methods when primary fails
* **Manual review** — Escalate complex cases to trained staff
* **Clear communication** — Explain issues and resolution paths to legitimate users
* **Pattern tracking** — Identify systematic discrepancies indicating fraud campaigns

#### Internal Fraud Reduction

Protect against insider threats ([DocRef](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/#part11)):

* **Access controls** — Limit staff access to minimum necessary
* **Audit logging** — Record all staff actions for review
* **Segregation of duties** — Prevent single individuals from completing entire processes
* **Regular audits** — Review staff activities for anomalies
* **Background checks** — Verify staff trustworthiness for sensitive roles
* **Fraud awareness training** — Educate staff about fraud risks and indicators
* **Whistleblower protections** — Provide safe reporting channels for suspected fraud

### 2.6 Risk Treatment Options

After assessing risk levels, select appropriate treatment strategies ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-para1)):

#### Treatment Strategies

Choose from these risk treatment approaches ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-det7)):

##### Avoid the Risk
* **Discontinue the service** — Cease operations that create unacceptable risk
* **Modify service design** — Remove high-risk features or transactions
* **Restrict access** — Limit service to lower-risk user groups
* **Require alternative channels** — Direct high-risk transactions to supervised channels

##### Modify Controls
* **Strengthen existing controls** — Enhance current measures for better effectiveness
* **Add new controls** — Implement additional defensive layers
* **Change control types** — Replace ineffective controls with better alternatives
* **Automate controls** — Reduce human error through automation

**Note**: Modifying controls changes your risk level. Reassess risk after control changes to ensure identification processes remain appropriate ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-det7)).

##### Adjust Assurance Levels
* **Increase assurance** — Implement stronger identification processes
* **Apply selective elevation** — Require higher assurance for specific transactions
* **Progressive assurance** — Start low and increase based on behavior
* **Context-aware assurance** — Adjust requirements based on risk indicators

##### Transfer Risk
* **Insurance** — Purchase coverage for identification-related losses
* **Contractual transfer** — Shift liability to service providers or partners
* **Shared responsibility** — Distribute risk across multiple parties

**Warning**: Risk transfer rarely eliminates accountability. You typically remain responsible for identification failures affecting your users ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-det7)).

##### Accept Risk
* **Formal acceptance** — Document decision to accept specific risks
* **Risk appetite alignment** — Ensure acceptance fits organizational risk tolerance
* **Compensating measures** — Implement detection and response capabilities
* **Regular review** — Reassess accepted risks as circumstances change

#### Choosing Treatment Options

Balance costs and benefits when selecting treatments ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-det8)):

* **Cost-effectiveness** — Compare implementation costs to risk reduction benefits
* **User impact** — Consider effects on legitimate user experience
* **Technical feasibility** — Ensure you can implement and maintain controls
* **Regulatory requirements** — Meet mandatory standards regardless of cost
* **Risk appetite** — Align treatments with organizational risk tolerance

Combine multiple treatment options for comprehensive risk management. For example, strengthen controls while purchasing insurance and accepting residual risk.

#### Accountability and Ownership

Assign clear ownership for risk treatment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part4-det9)):

Identify responsible parties with authority to:
* **Allocate resources** for control implementation
* **Modify service design** to reduce risk
* **Make assurance level decisions** for identification processes
* **Accept untreated risk** on behalf of the organization

Document risk ownership and treatment decisions for conformance assessment and ongoing accountability.

### 2.7 Monitoring and Review

Identification risks evolve constantly. Establish processes to keep your risk assessment current ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part5-para1)).

#### Continuous Monitoring

Track indicators that might signal changing risk levels:

##### Internal Indicators
* **Fraud attempts** — Frequency and sophistication of attacks
* **Control effectiveness** — Success rates of existing controls
* **Service changes** — New features or user populations
* **Incident patterns** — Trends in security events
* **User complaints** — Reports of identity-related issues

##### External Indicators
* **Threat intelligence** — New attack techniques and tools
* **Industry trends** — Fraud patterns in similar services
* **Regulatory changes** — New requirements or standards
* **Technology advances** — Emerging verification and attack capabilities
* **Economic factors** — Conditions that might increase fraud motivation

#### Trigger Events for Reassessment

Reassess risk when these events occur:

* **Service modifications** — Adding features, changing processes, or expanding access
* **Security incidents** — Successful attacks or near misses
* **Control failures** — Discovery that controls aren't working as expected
* **Regulatory updates** — New or changed compliance requirements
* **Organizational changes** — Mergers, acquisitions, or restructuring
* **Time-based reviews** — Annual or biannual scheduled assessments

#### Review Process

Structure your reviews for consistency and completeness:

1. **Gather current data** — Collect monitoring indicators and incident reports
2. **Reassess threats** — Update threat model with new attack vectors
3. **Evaluate controls** — Test current control effectiveness
4. **Recalculate risk** — Apply methodology to current situation
5. **Compare to baseline** — Identify changes from previous assessment
6. **Adjust treatments** — Modify controls or assurance levels as needed
7. **Document changes** — Record decisions and rationale
8. **Communicate updates** — Inform stakeholders of significant changes

#### Maintaining Assessment Currency

Keep your risk assessment relevant ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part5-para1-2)):

* **Version control** — Track assessment versions and changes
* **Regular updates** — Schedule periodic comprehensive reviews
* **Incremental adjustments** — Make small updates as conditions change
* **Stakeholder engagement** — Involve business and technical teams
* **External validation** — Seek independent review of assessments
* **Lessons learned** — Incorporate insights from incidents and exercises

### Tools and Resources

The Department of Internal Affairs provides tools to support your risk assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part6-para1)):

#### Assessment Workbooks

Download these workbooks to structure your assessment:

* **Service Assessment Workbook** — Assess overarching service risk focusing on Risk 1 (incorrect information) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part6-para2))
* **Transaction Assessment Workbook** — Evaluate individual transactions focusing on Risk 2 (incorrect binding) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part6-para3))
* **Bulk Transaction Workbook** — Streamlined assessment for high-volume transactions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part6-para3))

Access these tools through [Section 9: Reference Materials](#section-9-reference-materials).

#### Additional Support

* **Training and workshops** — Learn assessment techniques through hands-on sessions
* **Expert consultation** — Access specialist advice for complex assessments
* **Peer review** — Connect with other organizations for assessment validation
* **Case studies** — Learn from real-world assessment examples

Contact the Identification Team at [identity@dia.govt.nz](mailto:identity@dia.govt.nz/) for guidance and support ([DocRef](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/#part7-para1)).

### Key Takeaways

Successful identification risk assessment requires:

* **Understanding both risk types** — Information accuracy (Risk 1) and binding/authentication (Risk 2)
* **Following structured methodology** — Systematic assessment of impact, likelihood, and controls
* **Applying proportionate treatments** — Right-sizing controls to actual risk levels
* **Implementing counter-fraud techniques** — Specialized controls for challenging scenarios
* **Maintaining currency** — Regular monitoring and reassessment as conditions change

Your risk assessment forms the foundation for selecting appropriate assurance levels. Proceed to [Section 3: Selecting Your Assurance Levels](#section-3-selecting-your-assurance-levels) to translate your risk assessment into specific control requirements.

For detailed control implementation, refer to the relevant standards:
* [Section 5: Information Assurance Standard](#section-5-information-assurance-standard) for Risk 1 controls
* [Section 7: Binding Assurance Standard](#section-7-binding-assurance-standard) for Risk 2 binding controls
* [Section 6: Authentication Assurance Standard](#section-6-authentication-assurance-standard) for Risk 2 authentication controls

Remember that effective identification risk management protects both your organization and the individuals who depend on your services. Invest the time to thoroughly understand and assess your risks — this investment pays dividends through reduced fraud, improved compliance, and enhanced trust.


## Section 3: Selecting Your Assurance Levels

### 3.1 Introduction to Levels of Assurance

#### What are Levels of Assurance?

Levels of Assurance (LoA) indicate how robust your identification processes are to assure the right Entity Information, Authenticators, and the connections between these and an Entity ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#para1)). When you implement identification management, you need to decide how strong each process should be—this decision directly impacts both security and user experience.

Think of Levels of Assurance as a structured way to match your identification controls to your actual risks. After you assess your identification risks (Section 2), you use those findings to select appropriate assurance levels. These levels then guide which specific controls you must implement from the Identification Standards (Sections 4-7).

#### Why Levels of Assurance Matter

Every identification process faces different risks. A low-value, low-risk service needs different controls than a high-value, high-risk service. Levels of Assurance help you:

* Balance security requirements with user convenience
* Apply controls proportionate to your identified risks
* Communicate your security posture clearly to stakeholders
* Enable interoperability with other organizations at similar assurance levels
* Meet regulatory and policy requirements efficiently

Without a systematic approach to assurance levels, you might over-engineer simple processes (frustrating users unnecessarily) or under-protect critical processes (leaving dangerous vulnerabilities). The LoA framework prevents both problems by providing clear, risk-based guidance.

#### How Levels of Assurance Connect Your Risk Assessment to Standards

Your journey through identification management follows this path:

1. **Assess your risks** (Section 2) to understand what threats you face
2. **Select your assurance levels** (this section) based on those risks
3. **Implement the standards** (Sections 4-7) at your selected levels
4. **Demonstrate conformance** (Section 8) with your chosen levels

This section bridges the gap between understanding your risks and implementing controls. It translates your risk assessment outputs into specific assurance level requirements that determine which controls you must implement.

### 3.2 The Three-Part Expression

#### Understanding the Expression Format

Declare Levels of Assurance as a three-part expression ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart1-para1)):

`{IAn, BAn, AAn}` or more simply as `{n,n,n}`

Where *n* represents the assurance level (1 to 4) achieved by each identification process. The order of the values always remains the same ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart1-para2)).

For example:
* `{IA2, BA2, AA3}` or `{2,2,3}` indicates Information Assurance level 2, Binding Assurance level 2, and Authentication Assurance level 3
* `{IA3, BA3, AA4}` or `{3,3,4}` indicates higher assurance across all three aspects

#### Information Assurance (IA) Levels

Information Assurance measures the robustness of processes to establish the quality and accuracy of Entity Information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-para3-1)).

* **IA1**: Basic information collection with minimal verification
* **IA2**: Enhanced information quality with some verification
* **IA3**: Strong information verification from authoritative sources
* **IA4**: Very strong information assurance with multiple authoritative sources

Higher IA levels require more rigorous processes to verify that information about an entity is accurate, complete, and current. You achieve a particular IA level when you apply all controls in the Information Assurance Standard (Section 5) at that level or above.

#### Binding Assurance (BA) Levels

Binding Assurance measures the robustness of Entity Binding—the process to bind the Entity to Entity Information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-para3-2)).

* **BA1**: Light binding, possibly aligned to self-asserted information
* **BA2**: Distinct link established between the Entity and their information
* **BA3**: Strong binding with in-person or equivalent verification
* **BA4**: Very strong binding with multiple verification methods

Higher BA levels require stronger evidence that the person presenting information is actually the person that information describes. You achieve a particular BA level when you apply all controls in the Binding Assurance Standard (Section 7) at that level or above.

#### Authentication Assurance (AA) Levels

Authentication Assurance measures the robustness of the Authenticator and processes to ensure an Authenticator remains solely in control of its holder and is properly registered ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-para3-3)).

* **AA1**: Single-factor authentication with basic controls
* **AA2**: Single-factor authentication with enhanced controls
* **AA3**: Two-factor authentication or strong biometric
* **AA4**: Two-factor authentication including biometric

Higher AA levels require stronger authenticators and more rigorous processes to prevent unauthorized access. You achieve a particular AA level when you apply all controls in the Authentication Assurance Standard (Section 6) at that level or above.

#### How the Three Levels Combine

Apply the Levels of Assurance expression to individual pieces of information in a context, not to whole Credentials, Entities, or events like enrolment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart1-para3)). This granular approach recognizes that not all information receives the same treatment—some information within a Credential may have robust processes applied while other information may not.

You can also set one or more values in an expression to 0 if that process doesn't exist in your instance ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart1-para4)). For example:
* `{IA2, BA0, AA2}` might apply when you verify information and authenticate users but don't perform binding
* `{IA0, BA0, AA3}` might apply to anonymous authentication scenarios

### 3.3 The Triangle Model

#### Visualizing the Identification Framework

In identification, when an Entity enrols in a particular context (usually related to a Relying Party), three elements form a triangle ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-para1)):

* The Entity (the person or organization)
* The Entity's information (data about them)
* The Authenticators they use within that context

**Diagram 1:** Relationship between identification elements
![A person, a key and folders of information arranged in a triangle connected by lines](../../files/levels-of-assurance.png/)
([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-fig1))

#### Understanding the Triangle Elements

**Entity**: Any person or organization with distinct existence who enrols with your organization for services ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para1)). In your context, entities are those who carry out transactions with your systems.

**Entity Information**: Information you collect and store about an Entity to provide your service ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para2)). This includes identity attributes, contact details, permissions, and any other data needed for your business processes.

**Authenticators**: Things known and/or possessed and controlled by an Entity that they use to be recognized when they return to your service ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para3)). Authenticators act as shortcuts to avoid repeating all identification steps from the enrolment process.

#### The Three Relationships in the Triangle

The triangle model shows three critical relationships, each corresponding to an assurance aspect:

**Entity Binding** (addressed by Binding Assurance): The process of ensuring the Entity Information belongs to the Entity using it ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para4)). This confirms "you are who you claim to be."

**Authenticator Registration** (addressed by Authentication Assurance): The process of creating and/or linking an Authenticator to information about an Entity ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para5)). This establishes the connection between credentials and identity information.

**Authenticator Control** (addressed by Authentication Assurance): The process of ensuring the user of the Authenticator is the same Entity to which the Entity Information relates ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-det1-para6)). This maintains ongoing authentication integrity.

#### Why All Three Aspects Matter

When you apply all three assurance aspects together, they ensure the integrity of the triangle is maintained and reduce the risk of identity theft ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part1-subpart1-para4)). Weakness in any one aspect can compromise the entire identification system:

* **Weak Information Assurance**: You might authenticate the right person but have wrong information about them
* **Weak Binding Assurance**: You might have correct information but link it to the wrong person
* **Weak Authentication Assurance**: You might have the right person's correct information but fail to recognize them when they return

The triangle model helps you visualize these interdependencies and understand why you need appropriate levels across all three aspects.

### 3.4 Mapping Risk to Assurance Levels

#### From Risk Assessment to Level Selection

Each assurance aspect has four levels representing the degree of robustness in associated processes, where 1 represents the weakest process and 4 represents the strongest ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part2-para1)). Determine the level to use based on the amount of risk you need to mitigate ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part2-para2)).

Your risk assessment (Section 2) produces two types of risk ratings:
* **Risk Type 1**: Accepting incorrect information about an entity
* **Risk Type 2**: Incorrectly recognizing a returning entity

These risks map to assurance levels as follows:

#### Risk Level to Strength Level Mapping

Use this general mapping to translate your risk ratings into required assurance levels:

**Low Risk → Level 1 Assurance**
* Minimal harm if compromise occurs
* Public or low-sensitivity information
* No financial or reputational impact
* Example: Newsletter subscriptions, public information requests

**Moderate Risk → Level 2 Assurance**
* Limited harm potential
* Some sensitivity or value involved
* Minor financial or reputational impact
* Example: Online forums, basic service accounts

**High Risk → Level 3 Assurance**
* Significant harm potential
* Sensitive information or valuable transactions
* Notable financial or reputational impact
* Example: Financial services, health records access

**Very High Risk → Level 4 Assurance**
* Severe harm potential
* Highly sensitive or critical operations
* Major financial or reputational impact
* Example: High-value financial transactions, critical infrastructure access

#### When to Select Higher or Lower Levels

Consider selecting **higher** assurance levels when:
* Regulatory requirements mandate specific levels
* Your risk assessment identifies elevated threats
* You process particularly sensitive information
* You need to establish trust with other organizations
* The cost of compromise exceeds the cost of stronger controls

Consider selecting **lower** assurance levels when:
* User convenience is paramount for low-risk services
* The cost of stronger controls exceeds potential losses
* You have compensating controls outside the identification process
* Your user base has limited technical capability
* You operate in a low-threat environment

#### Balancing Different Assurance Aspects

You don't need to set all three aspects to the same level. Match each aspect to its specific risks:

* **Higher IA, Lower BA/AA**: When information accuracy matters more than strong authentication (e.g., demographic surveys)
* **Lower IA, Higher BA/AA**: When authentication security matters more than detailed information (e.g., age verification)
* **Balanced levels**: When all aspects face similar risk levels (most common scenario)

### 3.5 Standard Combination Requirements

#### Which Standards Apply at Which Levels

To achieve your selected Levels of Assurance, implement controls from the relevant standards at the required levels ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part2-para4)):

**For Information Assurance (IA)**:
* Implement all controls from the Information Assurance Standard (Section 5)
* Apply controls at your selected IA level or above
* Higher levels include all lower-level requirements

**For Binding Assurance (BA)**:
* Implement all controls from the Binding Assurance Standard (Section 7)
* Apply controls at your selected BA level or above
* Consider counter-fraud techniques for higher levels

**For Authentication Assurance (AA)**:
* Implement all controls from the Authentication Assurance Standard (Section 6)
* Apply controls at your selected AA level or above
* Select appropriate authenticator types for your level

**For Federation scenarios**:
* Also implement the Federation Assurance Standard (Section 4)
* Federation controls apply when you provide or rely on credentials used in multiple contexts
* Federation doesn't have separate levels—controls apply based on your IA, BA, and AA levels

#### Minimum Requirements by Level

Each level builds upon previous levels. Here are the minimum requirements:

**Level 1 - Basic Assurance**:
* Self-asserted information acceptable
* Single-factor authentication sufficient
* Light binding processes allowed
* Minimal evidence requirements

**Level 2 - Enhanced Assurance**:
* Some information verification required
* Enhanced authentication controls
* Distinct binding processes needed
* Evidence from reliable sources

**Level 3 - High Assurance**:
* Strong information verification from authoritative sources
* Two-factor authentication or strong biometrics
* Strong binding with substantial evidence
* In-person or equivalent verification methods

**Level 4 - Very High Assurance**:
* Multiple authoritative source verification
* Two-factor including biometric authentication
* Very strong binding with multiple methods
* Enhanced counter-fraud measures throughout

#### Common LOA Combinations

Organizations typically implement these combinations:

**Public Services - Low Risk**: `{IA1, BA1, AA1}` or `{1,1,1}`
* Information kiosks
* Anonymous feedback systems
* Public consultation platforms

**Standard Online Services**: `{IA2, BA2, AA2}` or `{2,2,2}`
* Email accounts
* Social media platforms
* Online shopping sites

**Government Services - Moderate Risk**: `{IA2, BA2, AA3}` or `{2,2,3}`
* Tax filing systems
* License renewals
* Benefit applications

**Financial Services**: `{IA3, BA3, AA3}` or `{3,3,3}`
* Online banking
* Investment platforms
* Insurance claims

**High-Security Applications**: `{IA3, BA3, AA4}` or `{3,3,4}`
* Healthcare records
* Legal document signing
* Critical infrastructure access

### 3.6 Implementation Planning Considerations

#### Phased Implementation Approaches

You don't need to implement your target assurance levels immediately. Consider these phased approaches:

**Progressive Enhancement**:
1. Start with minimum viable levels for initial deployment
2. Gather user feedback and threat intelligence
3. Incrementally increase levels based on actual risks observed
4. Allow users time to adapt to stronger controls

**Risk-Based Prioritization**:
1. Identify your highest-risk processes first
2. Implement stronger assurance for critical functions
3. Apply appropriate levels to moderate-risk processes
4. Address low-risk processes last

**User Segmentation**:
1. Offer different assurance levels for different user groups
2. Require higher levels for privileged users
3. Allow standard levels for regular users
4. Provide basic levels for public access

#### Cost-Benefit Analysis

Consider these factors when planning your implementation:

**Implementation Costs**:
* Technology acquisition (hardware tokens, biometric readers)
* System integration and development
* Staff training and process changes
* User support and education
* Ongoing maintenance and operations

**Benefits to Quantify**:
* Reduced fraud losses
* Fewer security incidents
* Improved regulatory compliance
* Enhanced customer trust
* Operational efficiency gains

**Key Decision Points**:
* Does the cost of stronger controls justify the risk reduction?
* Will users accept the friction of higher assurance levels?
* Can you phase implementation to spread costs over time?
* Are there alternative controls that achieve similar outcomes?

#### Balancing Security and Usability

Higher assurance levels typically introduce more user friction. Manage this balance by:

**Making Security Convenient**:
* Choose user-friendly authenticator types
* Implement single sign-on where appropriate
* Provide clear instructions and support
* Offer multiple authentication options
* Remember user devices to reduce repeat authentication

**Applying Risk-Appropriate Friction**:
* Reserve highest friction for highest-risk operations
* Use adaptive authentication based on context
* Allow lower assurance for read-only access
* Require stepping up only when necessary
* Provide clear explanations for security requirements

**Supporting Your Users**:
* Offer multiple channels for identity verification
* Provide fallback options for technical issues
* Create clear documentation and tutorials
* Train support staff on identification processes
* Monitor and respond to user feedback

### 3.7 Moving to the Standards

#### What Comes Next

Now that you understand how to select your assurance levels, you're ready to implement the Identification Standards:

1. **Federation Assurance Standard** (Section 4): If you provide or rely on credentials used across multiple contexts
2. **Information Assurance Standard** (Section 5): To implement your selected IA level
3. **Authentication Assurance Standard** (Section 6): To implement your selected AA level
4. **Binding Assurance Standard** (Section 7): To implement your selected BA level

Each standard section includes:
* The complete standard requirements (which cannot be modified)
* Implementation guidance to help you apply controls
* Practical examples and explanations
* Links to relevant checklists and tools

#### How to Use the Integrated Standards and Guidance

The following sections present standards and guidance together for easier implementation:

**Standard Requirements** appear as formal controls:
* Identified by control numbers (e.g., IA1.01, BA2.02)
* Use prescriptive language (MUST, SHOULD, MAY)
* Specify what you need to achieve
* Cannot be modified or negotiated

**Implementation Guidance** provides practical help:
* Explains why controls matter
* Offers implementation approaches
* Provides examples and scenarios
* Suggests tools and techniques

Read both the standards and guidance for your selected levels. The standards tell you what to do; the guidance helps you understand how to do it effectively.

#### Declaring Your Levels of Assurance

Once you implement the standards, declare your Levels of Assurance to communicate your security posture ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-para1)). You might declare levels when you:

* Need to meet specific risk profiles following risk assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-para1-1))
* Want to change identification processes after reviewing current capability ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-para1-2))
* Need to demonstrate trust in identification processes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-para1-3))

Declare your levels through ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart2-para1)):
* General information about credentials and purpose (e.g., on your website)
* Functional requirements when procuring identification services
* Metadata in presentation or information sharing arrangements
* Public registers after independent assessment and certification

Include a statement about the nature of your declaration—whether self-attested or independently verified ([DocRef](https://docref.digital.govt.nz/nz/identification-management/levels-of-assurance/2025/en/#part3-subpart2-para2)). For information about certification, see Section 8: Demonstrating Conformance.

#### Key Takeaways

* Select assurance levels based on your risk assessment results
* Use the three-part expression {IAn, BAn, AAn} to declare levels
* Understand the triangle model connecting entities, information, and authenticators
* Implement all relevant standards at your selected levels
* Balance security requirements with user experience
* Consider phased implementation for complex deployments
* Declare your levels to build trust and enable interoperability

You're now ready to implement the Identification Standards at your selected assurance levels. Continue to Section 4 if you're implementing federation, or jump to the standard matching your highest-priority assurance aspect.


## Section 4: Federation Assurance Standard & Implementation

### 4.1 Introduction and Overview

Federation Assurance addresses the additional controls required when credentials are designed to be used across multiple contexts and services. This standard ensures that credentials maintain their integrity, security, and privacy when used beyond their original issuing context ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/)).

#### What this standard covers

The Federation Assurance Standard provides controls for:
* **Credential Providers (CP)** who establish credentials that can be reused by entities in identification processes with multiple relying parties
* **Facilitation Providers (FP)** who create mechanisms that facilitate the presentation of one or more credentials
* **Presentation processes** that ensure credential information reaches relying parties securely and with appropriate privacy protections

This standard applies to any Credential Provider (CP) and any Facilitation Provider (FP) that facilitates the presentation of 1 or more Credentials. The CPs and FPs are accountable for controls stated in this standard, even if they have employed or contracted aspects to other parties ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part1-para1)).

#### Why federation matters

Federation enables entities to use a single credential across multiple services, reducing the need for separate enrollment and identity verification processes. This approach:
* Reduces identity verification fatigue for entities
* Improves service delivery efficiency
* Enables consistent assurance levels across services
* Supports privacy-preserving credential presentation

Application of the controls in this standard will contribute to the reduction of identity theft, entitlement fraud, misrepresentation of abilities and the impacts that result ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part1-para2)).

#### How federation relates to other standards

Federation Assurance works in conjunction with the other three identification standards:

**Table 1:** Assurance components

| Assurance component | Description |
|---|---|
| **IA**: Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information |
| **BA**: Binding Assurance | Robustness of the process to bind the Entity to Entity Information |
| **AA**: Authentication Assurance | Robustness of the process to ensure an Authenticator remains solely in control of its holder |
| **FA**: Federation Assurance | Additional steps undertaken to maintain the integrity, security and privacy of 1 or more credentials, and their use in many contexts |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part2-subpart1))

#### Structure of this standard

This standard divides requirements into 3 parts:
* Part 1 — Requirements for Credential Providers establishing Credentials
* Part 2 — Requirements for Facilitation Providers establishing facilitation mechanisms
* Part 3 — Requirements for the presentation of Credentials by Facilitation Providers

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part3-subpart3))

#### Key concepts

##### Credentials
In this standard Credentials contain and make use of 3 aspects of information:
* **Credential subject information** — The attributes about the Entity contained in the Credential
* **Presentation information** — Information about the Credential's integrity mechanisms
* **Facilitation information** — Information about the facilitation mechanism used

At a minimum, a Credential consists of an Authenticator and Integrity mechanisms. Most Credentials have additional Presentation information that determines its use for specific purposes. For example, to travel or to drive ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part3-para2)).

##### Credential presentation
To maintain the privacy of the holder, not all the Credential subject information in a Credential needs to be made available to a Relying Party. There are 2 forms of limitation:
* **Partial presentation** — a subset of the Credential subject information is made available to the Relying Party
* **Derived value presentation** — 1 or more of the values in the presentation are deduced or inferred from the value in the Credential. For example, age can be inferred from a date of birth

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part3-subpart1))

##### Facilitation
Facilitation involves the establishment and use of a mechanism that can facilitate the presentation of 1 or more Credentials (fully or partially) in response to a request from a Relying Party. These mechanisms include exchanges, hubs (for example, RealMe®) and digital wallets ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part3-subpart2)).

---

### 4.2 Part 1 — Requirements for Credential Providers establishing Credentials

The requirements in this section apply to the relationship between an Entity, a Credential Provider and the Credential that they establish ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-para1)).

The Credential Provider will apply the Information Assurance, Binding Assurance and Authentication Assurance Standards, as would a Relying Party during the Credential Enrolment process ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-para2)).

#### Objective 1 — Credential risk is understood

##### Rationale

For holders to trust their Credential is being adequately protected from unauthorised access and use, the risk the Credential poses when used in multiple contexts needs to be understood by the Credential Provider and mitigated. Obtaining and using a Credential has the potential to expose holders to additional risks arising from increased collection of information. As Credentials move from narrow purposes with minimal attributes to ones that can fulfil several identification requirements, care needs to be taken with the accumulation of information. This includes the attributes that are contained in the Credential regardless of any limitation made during presentation. Credential Providers may also need to achieve specific levels of assurance determined by contracts and/or legislation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart1))

##### FA1.01 Control

The CP MUST carry out an assessment of the risk posed by the existence of the Credential before offering it.

**Additional information** — While any risk assessment process can be used, specific guidance is available on [assessing identification risk](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart1))

#### Implementing FA1.01 — Guidance

Use any robust risk assessment process to identify the risk of the Credential. Consider the purpose the Credential serves and the environment in which it exists, including whether it's a physical or digital Credential ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart1)).

Apply the guidance in [Assessing identification risk](#section-2) to improve the quality of your assessment. A workbook is available to help undertake an identification risk assessment and provide the optimum level of assurance as an output. For a copy, email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).

While you don't need to predict the risk of services offered by Relying Parties who may accept the Credential, understand the levels of assurance required by the Relying Parties and Entities for whom you're designing the Credential.

> **Example**: A digital driver licence designed for multiple uses would assess risks including:
> * Information exposure if the credential is compromised
> * Correlation risks across different service contexts
> * Privacy implications of attribute disclosure
> * Authentication requirements for different use cases

##### FA1.02 Control

The CP MUST evaluate the risk of all information available to a holder viewing or managing their Credential and apply the corresponding level of authentication.

**Additional information** — Where credentials can be presented in privacy-preserving ways using partial presentation and derived values, the authentication level for presentation may be lower than that needed for Credential management.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart1))

#### Implementing FA1.02 — Guidance

Recognize that digital Credentials can limit information shown by displaying only a subset of attributes based on the Relying Party's needs. However, when a Holder accesses their Credential for management purposes, they view all information contained in the Credential ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart1)).

As Credentials potentially contain larger amounts of information in the future, understand the risks this information could expose the Holder to and implement appropriate additional authentication requirements.

> **Example**: A credential management interface might require:
> * Level 3 authentication for viewing full credential details
> * Level 2 authentication for partial credential presentation
> * Additional authentication for sensitive attribute updates

#### Objective 2 — Credentials have recognised levels of assurance

##### Rationale

Consistent approaches to Credential establishment and an ability for Relying Parties to know the Credential and the Credential Provider are genuine, reduce the likelihood Credentials will be able to be used as avenues for identity theft and fraud. As more Credentials become able to be used for multiple purposes, Entities can also use assurance levels to select Credentials best suited to the identification needs of the services they most commonly use.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart2))

##### FA2.01 Control

The CP MUST establish the Credential using identification processes that comply with the latest versions of the following standards:
* [Information Assurance Standard](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/)
* [Binding Assurance Standard](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/)
* [Authentication Assurance Standard](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/).

**Additional information** — When a Credential Provider is enrolling an Entity and applying these standards, they do so in the role of a Relying Party. They become a Credential Provider at the point they establish the Credential for that Entity. The level to which assurance has been gained against the above standards will determine the levels to be declared in FA10.01.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart2))

#### Implementing FA2.01 — Guidance

During the Credential establishment process, act in the role of Relying Party and apply the controls contained within the following Identification Standards:
* [Information Assurance Standard](#section-5)
* [Binding Assurance Standard](#section-7)
* [Authentication Assurance Standard](#section-6)

The levels of assurance you gain against these standards contribute to the levels you'll declare in FA2.02 and FA10.01 ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart2)).

##### FA2.02 Control

The CP MUST make level/s of assurance for the Credential subject information available to Holders, Relying Parties and Facilitation Providers.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart2))

#### Implementing FA2.02 — Guidance

Declare levels of assurance for Credential subject information to enable evaluation of the strength and reliability of this information. Use various methods to make this declaration including:
* Posting information on a website with other material about the Credential
* Including levels in metadata for digital Credentials
* Publishing in credential documentation

Note that when you declare levels of information assurance (LoIA) for your Credential, the levels will be a step below that achieved for levels 3 and 4, unless you maintain a synchronised link with the evidence used ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart2)).

> **Examples of reduced levels of assurance**:
> * An endorsement verified against a driver licence document achieves LoIA 3 — when the Credential is created as a reference to a copy of the attribute value, it becomes LoIA 2
> * An endorsement verified against the driver licence database achieves LoIA 4 — the new Credential value as a copy at a point in time becomes LoIA 3
> * An endorsement verified against the database with synchronous access for current values maintains LoIA 4

##### FA2.03 Control

The CP MUST provide mechanisms, consistent with the intended assurance levels, that enable the Credential to be recognised as bona fide.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart2))

#### Implementing FA2.03 — Guidance

Ensure recognition of Credentials relates to recognising Credential Providers — both are integral to trusting the information and processes they represent. They're also needed for querying issues with either a Credential or transaction ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart2)).

> **Examples of Credential recognition mechanisms**:
>
> **For physical Credentials**:
> * Features requiring proprietary knowledge to reproduce
> * Branding characteristics, fonts, watermarks
> * References allowing independent contact with the Credential Provider
>
> **For digital Credentials**:
> * Digital certificates and cryptography
> * Tamper protections systematically identified
> * Access through pre-established trusted communication channels

##### FA2.04 Control

The CP MUST provide mechanisms, consistent with the intended assurance levels, that enable the Credential Provider to be recognised as bona fide.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart2))

#### Implementing FA2.04 — Guidance

Use public branding to support recognition of your organisation as a Credential Provider. Where reputation is concerned, take measures outside identification management to protect your brand from misuse by unauthorised parties ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart2)).

In the digital world, use independently verifiable Credential Provider identifiers and digital certificates or asynchronous keys to aid with recognising and confirming Credential Providers.

#### Objective 3 — Credential is privacy-preserving

##### Rationale

Using a Credential in multiple contexts offers numerous benefits to Entities. However, obtaining and using a Credential this way also has the potential to expose Entities to privacy risks arising from the capability to track and profile. The availability of correlated volumes of data makes it vulnerable to uses that may not be anticipated or desired by the holder. These unexpected uses could inhibit adoption of federated services.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart3))

##### FA3.01 Control

The CP MUST reduce the ability for Relying Parties to correlate holders by not including the holder's unique Entity Information identifier as part of a Credential.

**Additional information** — A unique Entity Information identifier is an identifier assigned by a context that uniquely identifies the set of Entity Information before a Credential has been established.

There are a few large organisations within New Zealand where their Entity Information identifier is also a public identifier for use in a specified purpose. Where these organisations become Credential Providers, they are unlikely to be able to comply with this control. Therefore, consideration needs to be given to ensuring use of those Credentials are limited to the specified purpose for which the Entity Information identifier created.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart3))

#### Implementing FA3.01 — Guidance

Avoid sharing Entity Information identifiers that can uniquely identify a set of Entity Information in a given context. Sharing these across multiple contexts potentially allows correlation of Entity information from multiple sources without the subject's permission or knowledge ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart3)).

This control doesn't limit sharing an identifier with a specific purpose (usually provided for in legislation), as long as the sharing is for that purpose. Make information on the limitation of use of these identifiers and who they can be shared with available to Holders and Facilitation Providers.

> **Examples of identifiers with prescribed purposes**:
> * Tax file number
> * National Student Index (NSI) number
> * National Health Index (NHI) number

Where an identifier is essential for administration and maintenance of a Credential, consider using a Credential identifier that's only valid for the life of the Credential. Digital implementations can also support Credential presentation identifiers unique to each presentation.

##### FA3.02 Control

The CP MUST support minimisation of information by enabling the use of partial sets of Credential subject information, when possible.

**Additional information** — Credentials offered digitally can be more flexible. It is possible that when a Credential is connected to a facilitation mechanism, the Credential Provider could supply only some of the attributes contained in the Credential subject Information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart3))

#### Implementing FA3.02 — Guidance

Apply information minimisation as a key principle for preserving privacy. For physical Credentials, limit the number of attributes to those essential for the Credential purpose. Digital Credentials have much more scope for supporting use of partial sets of information contained in the Credential ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart3)).

> **Example**: A digital identity credential might enable:
> * Age verification without revealing date of birth
> * Address confirmation without full address details
> * Qualification status without detailed transcript information

#### Objective 4 — Participation is inclusive

##### Rationale

Each Credential will have a purpose and corresponding holders who need them. Credential Providers have obligations including responsibilities under the Treaty of Waitangi and digital inclusion to ensure that Entities can participate on an equal footing. Therefore, consideration of the population of Entities who will depend on the Credential is essential so as not to contribute to the exclusion of participation by any group.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart4))

##### FA4.01 Control

The CP MUST identify the population of Entities who will require the Credential.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart4))

#### Implementing FA4.01 — Guidance

Identify the Entities who will require the Credential by understanding the nature of the group and what may impact the application process. Consider ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart4)):
* Where are they located?
* Will they have access to the application process?
* Will they be able to understand any communication or messaging?
* Is there anything preventing them from undertaking the process, such as physical and mental ability?

##### FA4.02 Control

The CP MUST support any Entity within the identified population to become a Credential holder.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart4))

#### Implementing FA4.02 — Guidance

Using the information gathered in FA4.01, design the application process and any exception processes to enable the target group to become a Credential Holder ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart4)).

> **Examples of process considerations**:
> * Provide communications and messaging in multiple languages
> * Support in-person and remote application processes
> * Support cultural and religious aspects that may impact the application process
> * Have exception-handling processes for those unable to meet published requirements

#### Objective 5 — Credential is maintained

##### Rationale

Once a Credential is established there are several activities that maintain its relevance and integrity. Some of these activities relate to managing the life cycle of the Credential such as updating, suspending and revoking the Credential. Other activities enable fraud detection, for example, if interactions with Credentials are not logged and monitored, Credential Providers will not be able to appropriately prevent or investigate any misuse or compromise.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

##### FA5.01 Control

The CP MUST provide the means for the Credential subject information contained in the Credential to be updated, by either:
* enabling Credential subject information in the Credential to be changed, or
* replacing the Credential, or
* establishing synchronous links to maintained sources of Credential subject information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.01 — Guidance

Update Credential information through several methods. Trigger updates through ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)):
* A request from the Holder
* A specified timeframe or expiry date
* An external notification, usually from the authoritative source

Physical Credentials need reissuing to be updated. Include an expiry date reflective of the Credential's purpose to reduce the risk of it becoming outdated.

Digital Credentials provide more flexibility, potentially allowing you to:
* Replace values in the Credential with newer values
* Reissue the Credential with updated information
* Link to maintained sources of information for latest values

##### FA5.02 Control

The CP MUST provide the means for the holder to cancel a Credential.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.02 — Guidance

Provide Holders with either an automated self-service application or a contact point to request cancellation. Include options to cancel permanently or temporarily ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

Note that physical destruction of a Credential doesn't ensure the Credential Provider knows about the cancellation — for example, a Holder cutting up a membership card doesn't notify the Provider.

##### FA5.03 Control

The CP MUST provide the means for the holder to report the loss or compromise of a Credential and receive support.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.03 — Guidance

Encourage good Holder behaviour and reduce impact by providing easy and effective means to report loss or compromise. Provide a dedicated email or phone number for this service. Ensure processes following loss or compromise are appropriate for the Credential's assurance level ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

##### FA5.04 Control

The CP MUST provide the means for addressing holder complaints or problems arising from Credential establishment and maintenance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.04 — Guidance

Enable Holders to make complaints or raise issues about Credential establishment and maintenance. Provide a dedicated email or phone number for this service ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

Implement a case management approach to:
* Track complaints from diagnosis to solution
* Reduce the need for Holders to provide information multiple times
* Provide consistency if multiple staff are involved

##### FA5.05 Control

The CP MUST provide the means for addressing holder and Relying Party complaints or problems arising from non-facilitated Credential presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.05 — Guidance

Recognize that complaints about presentations likely result from identity theft or credential compromise. These may be detected by either the Holder or a Relying Party ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

Make complaint mechanisms easy to find and use. Provide dedicated access points and use case management. Assess mechanisms for their effectiveness in achieving resolution.

When receiving complaints about facilitated presentations where you're not the Facilitation Provider, communicate strongly with the Facilitation Provider to avoid shifting responsibility between providers.

##### FA5.06 Control

The CP MUST be able to update the Credential status to prevent its use, even if the responses to authentication challenges are successful, and can either:
* suspend the Credential, allowing for recovery in the future, or
* revoke, permanently disable or delete the Credential.

**Additional information** — If the holder has requested deletion of a Credential, consider suspending it for a period of 1 month before revoking to allow for recovery if needed.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.06 — Guidance

Initiate status changes either by Holder request or as a result of other processes like fraud investigation. Make status changes temporary or permanent depending on the case ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

> **Examples of Credential status changes**:
> * Notify Provider of fraudulent use → immediately set status to 'suspended' → after investigation change to 'revoked'
> * Holder reports Credential mislaid during house move → 'suspend' temporarily → 'reactivate' when found

Make status available to Facilitation Providers and Relying Parties wherever possible. For digital Credentials, the Facilitation Provider accesses status during presentation and either prevents presentation or provides status to the Relying Party.

For physical document Credentials not requiring facilitation, publish status in a register or source that Relying Parties can independently check.

##### FA5.07 Control

The CP MUST set an expiry on a Credential where the usage and risk indicates this to be appropriate.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.07 — Guidance

Set expiry dates on Credentials to provide opportunities to:
* Check information remains up to date
* Verify the Credential remains in the Holder's possession and control
* Include or ensure compatibility with new technology
* Make changes to address new threats

([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5))

##### FA5.08 Control

The CP MUST log all activity within the system, including but not limited to:
* who did the action
* when the action occurred
* what the action was — create, read, update or delete
* what was changed by the action — before and after.

**Additional information** — For physical Credentials this activity is more likely to apply to any database that supports it than the Credential itself.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.08 — Guidance

Log activity within your system as a key enabler for investigations and fraud detection. While the control lists minimum items, record additional information relative to your system's purpose and outcomes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

For physical documents, focus recording on Credential reissuing activities.

##### FA5.09 Control

The CP MUST support additional confidence in the integrity of the Credential by taking preventative measures including but not limited to:
* auditing logs
* monitoring activities for adverse behaviours
* undertaking counter fraud measures.

**Additional information** — Refer to guidance on counter fraud measures. [Counter fraud techniques](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/)

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.09 — Guidance

Think of preventative measures as risk controls, grouped into ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)):
* **Preventative** — steps that stop a threat altogether
* **Corrective or Reductive** — steps that minimize impact when threats occur
* **Detective** — steps to identify threat events for corrective or preventative measures
* **Directive or Disincentive** — education and perception-based measures

Refer to [Counter fraud techniques](#section-2) for more detailed guidance.

##### FA5.10 Control

The CP MUST provide notifications to the holder that allow them to self-detect potential compromise, these can include but are not limited to:
* the last time the holder accessed their Credential (where applicable)
* any change made to the holder's Credential.

**Additional information** — If the change is to contact information, notification needs to be sent to the contact information prior to the change or to an alternative contact.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part4-subpart5))

#### Implementing FA5.10 — Guidance

Provide notifications to Holders, though this is impacted by whether the Credential is facilitated during presentation. You usually cannot notify a Holder of unfacilitated Credential use. However, if you perform subsequent checks against a source or register, record these and make them available to the Holder on request ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part2-subpart5)).

> **Example of Holder notification**:
> When changing a Credential, send the Holder a text to their pre-registered mobile phone. The message invites them to contact the Credential Provider immediately if they didn't make the change.

When changing contact information, send notifications to previous contact points. Otherwise, unauthorised changes won't be seen by the subject.

---

### 4.3 Part 2 — Requirements for Facilitation Providers establishing facilitation mechanisms

The requirements in this section apply to the establishment of facilitation mechanisms ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-para1)).

Establishment of a mechanism includes confirming the relationship between the Entity and their Credentials and any new Authenticators associated with the mechanism ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-para2)).

#### Objective 6 — Facilitation mechanism risk is understood

##### Rationale

For holders to trust facilitation mechanisms, they need to be sure that when they use a facilitation mechanism to present their Credentials, it is being adequately protected from unauthorised access and use. This is especially so when multiple Credentials can be linked through a single facilitation mechanism. As increasing numbers of Credentials can be linked, care needs to be taken with the accumulation of information. This includes the attributes that are accessible by the facilitation mechanism regardless of any limitation made during presentation. Facilitation Providers may also need to achieve specific levels of assurance determined by contracts and/or legislation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart1))

##### FA6.01 Control

The FP MUST carry out an assessment of the risk posed by the facilitation mechanism, before offering it.

**Additional information** — While any risk assessment process can be used, specific guidance is available on [assessing identification risk](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart1))

#### Implementing FA6.01 — Guidance

Assess the risk of your facilitation mechanism before offering it. Use the guidance in [Assessing identification risk](#section-2) or any robust risk assessment process. Consider the accumulation of information risk when multiple Credentials link through a single mechanism.

##### FA6.02 Control

The FP MUST evaluate the risk of all information available to a holder, viewing or managing their facilitation mechanism, and apply a corresponding level of assurance for authentication that complies with the latest version of the [Authentication Assurance Standard](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart1))

#### Implementing FA6.02 — Guidance

Evaluate the risk of all information available when Holders view or manage their facilitation mechanism. Apply authentication levels that comply with the [Authentication Assurance Standard](#section-6) based on this risk evaluation.

#### Objective 7 — Binding assurance is maintained

##### Rationale

For Relying Parties and holders to trust a Facilitation Provider and their mechanisms, there needs to be certainty that there has not been a reduction in the binding assurance levels of the individual Credentials when they are connected. Certain conditions need to be met when Credential(s) are connected by a facilitation mechanism.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart2))

##### FA7.01 Control

The FP MUST provide 1 or more Authenticators for the facilitation mechanism.

**Additional information** — If a Credential Provider is facilitating presentation of their own Credential, this can be the same Authenticator as is used for that Credential.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart2))

#### Implementing FA7.01 — Guidance

Provide at least one Authenticator for your facilitation mechanism. If you're a Credential Provider facilitating presentation of your own Credential, you can use the same Authenticator as the Credential.

##### FA7.02 Control

The FP MUST ensure the Authenticator has an equivalent level of assurance to the Authenticators of the Credentials being connected to it, using identification processes that comply with the latest versions of the following standard:

[Authentication Assurance Standard](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/)

**Additional information** — If a Credential Provider is facilitating presentation of their own Credential, this can be the same Authenticator as is used for that Credential.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart2))

#### Implementing FA7.02 — Guidance

Ensure your Authenticator matches or exceeds the assurance levels of Credentials being connected. Apply the [Authentication Assurance Standard](#section-6) to achieve appropriate levels.

##### FA7.03 Control

The FP MUST ensure that the Entity proves control of the Authenticator for any given Credential before it is connected to a facilitation mechanism.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart2))

#### Implementing FA7.03 — Guidance

Before connecting any Credential to your facilitation mechanism, verify that the Entity controls the Authenticator for that Credential. This prevents unauthorized Credential connections.

#### Objective 8 — Facilitation mechanism is privacy-preserving

##### Rationale

A holder using a facilitation mechanism potentially enables the building of profiles and tracking of the holder's transactions. The availability of such data makes it vulnerable to uses that may not be anticipated or desired by the holder and could inhibit adoption of federated services. Where a facilitation mechanism is used to connect multiple Credentials there is an increased potential to expose Entities to privacy risks arising from the expanded volume of available attributes.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart3))

##### FA8.01 Control

The FP MUST ensure the holder has given permission to make each Credential available to the facilitation mechanism.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart3))

#### Implementing FA8.01 — Guidance

Obtain explicit permission from the Holder before making each Credential available to your facilitation mechanism. Document this permission for audit purposes.

##### FA8.02 Control

The FP MUST enable the holder to select which Credential subject information is added to the facilitation mechanism, where the Credential Provider allows for partial Credentials.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart3))

#### Implementing FA8.02 — Guidance

Where Credential Providers support partial Credentials, enable Holders to select which specific Credential subject information they add to your facilitation mechanism. Provide clear interfaces for this selection.

##### FA8.03 Control

The FP MUST inform the holder of any correlation or analysis of the use of their facilitation mechanism or the Credentials connected to it, undertaken for the purposes of detecting fraud or misuse.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart3))

#### Implementing FA8.03 — Guidance

Inform Holders when you correlate or analyze their facilitation mechanism use for fraud detection or misuse prevention. Be transparent about what analysis you perform and why.

##### FA8.04 Control

The FP MUST, except for the purpose given in FA8.03, only correlate or analyse a holder's use of their facilitation mechanism or the Credentials connected to it, with the permission of the holder.

**Additional information** — It is expected that Facilitation Providers will at a minimum correlate or analyse this information for the purposes of detecting fraud or misuse. However, any other services offered to Entities or Relying Parties that also involve the use of this information, require the knowledge and choice of the holder.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart3))

#### Implementing FA8.04 — Guidance

Beyond fraud detection (FA8.03), obtain Holder permission before correlating or analyzing their facilitation mechanism use. Any services you offer to Entities or Relying Parties involving this information require the Holder's knowledge and choice.

#### Objective 9 — Facilitation mechanism is maintained

##### Rationale

Once a facilitation mechanism is established there are several activities that maintain its relevance and integrity.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4))

##### FA9.01 Control

The FP MUST provide the means for the holder to add or remove any partial or full Credentials from a facilitation mechanism.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section39))

#### Implementing FA9.01 — Guidance

Provide Holders with self-service capabilities to add or remove Credentials from their facilitation mechanism. Support both partial and full Credential management.

##### FA9.02 Control

The FP MUST provide the means for the holder to cancel a facilitation mechanism.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section40))

#### Implementing FA9.02 — Guidance

Enable Holders to cancel their facilitation mechanism through automated self-service or support channels. Provide options for permanent or temporary cancellation.

##### FA9.03 Control

The FP MUST provide the means for the holder to report the loss or compromise of a facilitation mechanism and receive support.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section41))

#### Implementing FA9.03 — Guidance

Provide dedicated channels (email or phone) for Holders to report loss or compromise of their facilitation mechanism. Ensure support processes match the mechanism's assurance level.

##### FA9.04 Control

The FP MUST provide the means for addressing holder complaints or problems arising from facilitation mechanism establishment and maintenance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section42))

#### Implementing FA9.04 — Guidance

Establish complaint handling processes with case management to track issues from receipt to resolution. Provide consistency across multiple support staff interactions.

##### FA9.05 Control

The FP MUST log all activity within the system, including but not limited to:
* who did the action
* when the action occurred
* what the action was — gave permission, created, read, updated or deleted
* what was changed by the action — before and after.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section43))

#### Implementing FA9.05 — Guidance

Maintain comprehensive activity logs for fraud detection and investigation. Include permission grants alongside standard CRUD operations.

##### FA9.06 Control

The FP MUST support additional confidence in the integrity of the facilitation mechanism by taking preventative measures including but not limited to:
* auditing logs
* monitoring activities for adverse behaviours
* undertaking counter fraud measures.

**Additional information** — Refer to guidance on counter fraud measures. [Counter fraud techniques](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/)

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section44))

#### Implementing FA9.06 — Guidance

Apply preventative, corrective, detective, and directive measures to protect facilitation mechanism integrity. See [Counter fraud techniques](#section-2) for detailed guidance.

##### FA9.07 Control

The FP MUST provide notifications to the holder that allow them to self-detect potential compromise, including but not limited to:
* the last time the holder accessed their facilitation mechanism (where applicable)
* any change made to the holder's facilitation mechanism.

**Additional information** — If the change is to contact information, notification needs to be sent to the contact information prior to the change or to an alternative contact.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part5-subpart4-section45))

#### Implementing FA9.07 — Guidance

Send notifications to Holders about access and changes to their facilitation mechanism. When contact information changes, notify both old and new contact points to detect unauthorized modifications.

---

### 4.4 Part 3 — Requirements for the presentation of Credentials by Facilitation Providers

#### Objective 10 — Presentations are consistent and recognised

##### Rationale

For Relying Parties to trust the integrity of information from Credentials they need to know they have been established and presented in a consistent and recognised way. This includes knowing the Credentials are genuine and the levels of assurance they provide.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart1))

##### FA10.01 Control

The FP MUST make level(s) of assurance for the Credential subject information available to the Relying Party.

**Additional information** — Level of assurance is an expression representing the assurance level achieved by each of the 3 elements — information, binding and authentication. There can be a separate expression for each attribute in the Credential subject information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart1-section47))

#### Implementing FA10.01 — Guidance

Make assurance levels available to Relying Parties for all Credential subject information. Express levels for each of the three elements (information, binding, authentication) and potentially for individual attributes.

##### FA10.02 Control

The FP MUST declare the lowest assurance level, where the presentation is not able to express individual levels of assurance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart1-section48))

#### Implementing FA10.02 — Guidance

When your presentation cannot express individual assurance levels, declare the lowest level to ensure Relying Parties understand the minimum assurance provided.

##### FA10.03 Control

The FP MUST make the following additional Presentation information available to a Relying Party, where the presentation allows:
* Transaction identifier: A unique identifier for the presentation
* Issuance: A timestamp indicating when the Credential was established (updated)
* Expiration: A timestamp indicating when the Credential is expected to expire
* Credential validity: Information and/or mechanisms for determining the validity of Credentials, including if they have been revoked
* Audience identifier: An identifier for the Relying Party that requested the presentation.

**Additional information** — Some Presentation information applies to the whole presentation, some to each value in the presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart1-section49))

#### Implementing FA10.03 — Guidance

Provide comprehensive presentation metadata to Relying Parties where your implementation allows. Note that some information applies to the entire presentation while other information is specific to individual values.

#### Objective 11 — Presentations are privacy-preserving

##### Rationale

The presentation of Credential(s) should not expose any holder to a reduction in privacy. Active application of privacy principles such as data minimisation and providing permission contribute to good identification management practice and reduce identity theft and its impacts.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2))

##### FA11.01 Control

The FP MUST ensure the holder has given permission to make Credential subject information available to the Relying Party.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section51))

#### Implementing FA11.01 — Guidance

Obtain explicit Holder permission before making any Credential subject information available to Relying Parties. Implement clear consent mechanisms.

##### FA11.02 Control

The FP MUST enable the holder to remove Credential subject information from the presentation, where the facilitation mechanism allows.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section52))

#### Implementing FA11.02 — Guidance

Where your facilitation mechanism supports it, enable Holders to selectively remove Credential subject information from presentations to minimize data exposure.

##### FA11.03 Control

The FP MUST only make available the Credential subject information that has been requested by the Relying Party.

**Additional information** — The Relying Party can request derived, inferred or estimated values from the Credential subject information, in which case the Credential Provider does not make available the full value.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section53))

#### Implementing FA11.03 — Guidance

Limit information disclosure to what the Relying Party specifically requests. Support derived values (like age from date of birth) to minimize full value disclosure.

##### FA11.04 Control

The FP SHOULD NOT make available Credential subject information to a Relying Party that cannot provide a purpose for collecting it.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section54))

#### Implementing FA11.04 — Guidance

Require Relying Parties to provide collection purposes before releasing Credential subject information. This supports privacy and purpose limitation principles.

##### FA11.05 Control

The FP MUST only release Presentation information and Facilitation information that are applicable to the Credential subject information the holder has given permission to be made available.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section55))

#### Implementing FA11.05 — Guidance

Align presentation and facilitation information disclosure with the Holder's permissions for Credential subject information. Don't release metadata for information the Holder hasn't authorized.

##### FA11.06 Control

The FP MUST reduce the ability for Relying Parties to correlate holders by not making available the same persistent identifiers in Credential subject information, Presentation information or Facilitation information, to multiple Relying Parties, except where allowed for by law.

**Additional information** — Providing each Relying Party with different identifiers for the holder prevents correlation between Relying Parties but will still allow a single Relying Party to track the activity of 1 holder within its context.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section56))

#### Implementing FA11.06 — Guidance

Use different identifiers for each Relying Party to prevent cross-party correlation. Note this still allows individual Relying Parties to track Holder activity within their own context.

##### FA11.07 Control

The FP MUST, in response to a request for an anonymous presentation by a Relying Party, preserve the anonymity of the holder by not making available any persistent identifiers.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section57))

#### Implementing FA11.07 — Guidance

When Relying Parties request anonymous presentations, exclude all persistent identifiers to maintain complete Holder anonymity.

##### FA11.08 Control

The FP MUST take measures to ensure the information made available is not observed or disclosed to an unauthorised entity during presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart2-section58))

#### Implementing FA11.08 — Guidance

Implement technical measures like encryption and secure channels to prevent unauthorized observation or disclosure during credential presentation.

#### Objective 12 — Presentation content is unaltered

##### Rationale

Once a Credential holder has given permission for the Credential subject information to be made available to a Relying Party, they both need to be able to trust that the same information is received by the Relying Party.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart3))

##### FA12.01 Control

The FP MUST take measures to ensure the information made available during presentation is not altered.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart3-section60))

#### Implementing FA12.01 — Guidance

Use integrity protection mechanisms like digital signatures, checksums, or cryptographic seals to ensure information remains unaltered during presentation.

##### FA12.02 Control

The FP MUST establish secure communication channels between all parties, where more than 1 party is required to complete a process.

**Additional information** — This refers only to where multiple parties are delivering the presentation of Credentials, not to the Entity or the Relying Party.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart3-section61))

#### Implementing FA12.02 — Guidance

When multiple parties deliver credential presentations, establish secure channels between all involved parties. This requirement doesn't apply to channels with the Entity or Relying Party.

#### Objective 13 — Presentation can be investigated

##### Rationale

An important element of trust in any identification process is the ability for an Entity or Relying Party to question a process or presentation. While various controls allow for anonymity, pseudonymity and blinding of various parties in the Credential presentation process, none of these should prevent the investigation of a suspicious transaction.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart4))

##### FA13.01 Control

The FP MUST make available contact information to holders and Relying Parties, for the purposes of initiating a query about the presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart4-section63))

#### Implementing FA13.01 — Guidance

Provide clear contact information for both Holders and Relying Parties to query presentations. Make this information easily accessible and maintain responsive support channels.

##### FA13.02 Control

The FP MUST collect the following information, where the presentation allows:
* Transaction identifier: A unique identifier for the presentation event
* Timestamp: A timestamp of when the presentation occurred
* Holder identifier: An identifier for the Entity that the presentation is about
* Audience identifier: An identifier for the Relying Party intended to receive the presentation
* Credential subject information: Values and references that describe the Credential subject information that was presented
* Credential Provider identifier: An identifier for the member of a multi-party Credential Provider who is the accountable party
* Presentation Information: Information about the integrity mechanisms used
* Facilitation information: Values and references that describe the facilitation information that was exchanged.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part6-subpart4-section64))

#### Implementing FA13.02 — Guidance

Collect comprehensive transaction information where your presentation mechanism allows. This enables investigation of suspicious transactions while respecting privacy controls implemented elsewhere in the standard.

---

### 4.5 Conformance Checklist Summary

The Federation Assurance Standard contains 42 controls across 13 objectives. For detailed conformance assessment, see [Section 8: Demonstrating Conformance](#section-8).

#### Quick Reference — Federation Assurance Controls

##### Part 1: Credential Providers (FA1-FA5)
* **FA1**: Credential risk assessment (2 controls)
* **FA2**: Recognised assurance levels (4 controls)
* **FA3**: Privacy preservation (2 controls)
* **FA4**: Inclusive participation (2 controls)
* **FA5**: Credential maintenance (10 controls)

##### Part 2: Facilitation Providers (FA6-FA9)
* **FA6**: Facilitation mechanism risk (2 controls)
* **FA7**: Binding assurance maintenance (3 controls)
* **FA8**: Privacy preservation for facilitation (4 controls)
* **FA9**: Facilitation mechanism maintenance (7 controls)

##### Part 3: Presentation Requirements (FA10-FA13)
* **FA10**: Consistent and recognised presentations (3 controls)
* **FA11**: Privacy-preserving presentations (8 controls)
* **FA12**: Unaltered presentation content (2 controls)
* **FA13**: Investigatable presentations (2 controls)

For complete conformance checklists and assessment guidance, refer to [Section 8](#section-8).

---

*Last updated: 10 January 2025*


## Section 5: Information Assurance Standard & Implementation

### 5.1 Introduction and Overview

Information Assurance provides specific information management controls to ensure information collected is suitable for accurate decisions to be made regarding the eligibility or capability of an Entity ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#h1-subtitle)).

#### What this standard covers

The Information Assurance Standard addresses the quality and accuracy of Entity Information through five key objectives:
* Understanding information risk
* Protecting information through minimal collection
* Ensuring information accuracy
* Verifying evidence quality
* Maintaining verification integrity

This standard applies to any Relying Party (RP). The RP is accountable for the controls stated in this standard, even if they have employed or contracted aspects to other parties ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part1-para1)).

#### Why information assurance matters

Information Assurance is about the quantity and quality of information collected in relation to an Entity. It applies whether the information is being collected during the initial enrolment of the Entity or updated during subsequent interactions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part1-para1)).

Application of the controls in this standard will contribute to the reduction of identity theft, entitlement fraud, misrepresentation of abilities and the impacts that result ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part1-para2)).

Information Assurance does not make any judgement as to whether the Entity is using their own information or not — this is covered as part of [Binding Assurance](#section-7) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part1-para1)).

#### How information assurance relates to other standards

Table 1 describes each of the assurance components and the processes they relate to. A separate standard has been developed for each assurance component. This standard addresses the first of these assurance components — Information Assurance ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part2-para1)).

**Table 1:** Assurance components

| Assurance component | Description |
|---|---|
| **IA**: Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information |
| **BA**: Binding Assurance | Robustness of the process to bind the Entity to Entity Information |
| **AA**: Authentication Assurance | Robustness of the process to ensure an Authenticator remains solely in control of its holder |
| **FA**: Federation Assurance | Additional steps undertaken to maintain the integrity, security and privacy of a credential used in multiple contexts |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part2-para2-tb1))

#### When this standard applies

This standard applies whenever information related to an entity is collected and stored (whether during enrolment or a subsequent transaction) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part1-subpart2-para1)).

Effective information and records management ensures the creation, usability, maintenance, and sustainability of the information and records needed for business operations ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part1-subpart2-para2)).

Requirements for good practice information management come from many sources including, but not limited to, the Privacy Act 1993 (currently under review) and the Public Records Act 2005. This standard does not replace these requirements but provides requirements for identification management in the form of controls that are not explicit elsewhere ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part1-subpart2-para3)).

---

### 5.2 Standard Objectives and Controls

#### Objective 1 — Information risk is understood

##### Rationale

For entities to trust that their information is sought and used appropriately, the information (IA) assurance level should be consistent with the risk posed.

Relying parties may also need to achieve specific levels of assurance to mitigate risks and potentially to comply with legislation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-section1-para1))

##### IA1.01 Control

The RP MUST carry out an assessment of the information risk posed by any service before offering it.

**Additional information** — While any risk assessment process can be used, specific guidance is available on [assessing identification risk](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-section2-para1))

#### Implementing IA1.01 — Guidance

Use any robust risk assessment process to identify the information risk posed. Apply the guidance provided in [Assessing identification risk](#section-2) to improve the quality of your assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-section1)).

A workbook is available to help undertake an identification risk assessment and provide the optimum level of assurance as an output. For a copy, email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).

If you're assessing risk for providing a credential, consider the accumulated risk posed by credential reuse.

> **Example**: A digital identity service would assess risks including:
> * Privacy breaches from over-collection
> * Identity theft potential
> * Service delivery impacts
> * Legislative compliance requirements
> * Downstream effects on relying parties

#### Objective 2 — Information is protected

##### Rationale

A key part of preventing identity theft is to build protections into the collection and storage of information from the beginning.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart1-section3-para1))

##### IA2.01 Control

The RP MUST collect enough distinctive information, related to an entity, for it to be distinguishable from another entity's information.

**Additional information** — Otherwise known as Entity information uniqueness. Entity information is likely to be made unique by an internal system number and by the addition of any reference identifier. However, this will be insufficient if these are not known by the claiming entity. The lack of distinctive information will also make it difficult to identify potential fraud where 2 entities attempt to claim the same entity information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart1-section4-para1))

#### Implementing IA2.01 — Guidance

Ensure there's enough distinct information in an Entity's Information to determine it as separate from another's, without relying solely on an assigned reference. This enables identification of specific Entity Information without knowing the assigned reference ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1)).

Collecting information for distinction doesn't mean gathering additional identifying attributes beyond those serving a specific purpose. Distinct Entity Information doesn't ensure an Entity is enrolled only once.

> **Examples of distinctive information**:
> * An email address like kiwi5@domain.com distinguishes entities within domain.com if each email address is unique
> * A mobile number distinguishes entities if each Entity provides only numbers they have sole use of
> * Residential address and initials may distinguish entities in most contexts

##### IA2.02 Control

The RP MUST have a justifiable need for every piece of information it collects.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart1-section5-para1))

#### Implementing IA2.02 — Guidance

Apply Information privacy principle 1 of the [Privacy Act 2020](http://www.legislation.govt.nz/act/public/2020/0031/latest/LMS23223.html). Collecting information, especially identifying or sensitive information, without purpose is intrusive and poses risks to privacy, security and identity theft ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1)).

When collecting information, ensure you've identified a need for it. Consider whether you need the full value or just a derived value.

> **Examples of derived values**:
> * Age — derived from date of birth
> * Adult Yes/No — derived from date of birth being more than 18 years ago
> * Salary range $50,000 to $60,000 Yes/No — derived from annual salary

##### IA2.03 Control

The RP MUST store only the information it requires to carry out its purpose.

**Additional information** — This includes considering if the full value of a piece of information is needed, a derived value from the information or a reference to some source of the information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart1-section6))

#### Implementing IA2.03 — Guidance

Apply Information privacy principle 9 of the [Privacy Act 2020](http://www.legislation.govt.nz/act/public/2020/0031/latest/LMS23223.html). Information is often collected for decision making. Once you've made the decision, determine if you still need the information or if a record or reference suffices ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1)).

> **Examples of recording without retention**:
> * Check evidence and record the check and outcome rather than retaining values
> * Sight a licence without photocopying — note that it was sighted on a specific date by staff
> * Perform online verification — keep transaction record but not the verified values
> * With Entity consent, retain a reference to information sources rather than storing information directly

##### IA2.04 Control

Where information is collected for the sole purpose of verifying required information, the RP MUST discard this information once verification is complete.

**Additional information** — Under this requirement, the RP may keep a record that the information was collected, and the verification process undertaken — see IA5.02.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart1-section7))

#### Implementing IA2.04 — Guidance

Further apply Information privacy principle 9 of the [Privacy Act 2020](http://www.legislation.govt.nz/act/public/2020/0031/latest/LMS23223.html). Discard any information collected solely to provide a link to another source for verification once verification completes. If you need to retain it, then IA2.03 applies ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1)).

> **Examples of information to discard**:
> * Driver licence number and version collected to check consistency — delete after checking
> * Unique identifier used for online verification — delete identifier and unneeded verified information after verification

#### Objective 3 — Information is accurate

##### Rationale

The accuracy of the information being sought is key to its usefulness for decision making or administrative needs. The level of assurance needed for information is established through undertaking a suitable risk assessment process.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart2-section8))

##### IA3.01 Control

The RP SHOULD use recommended data format standards for the collection and storage of information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart2-section9))

#### Implementing IA3.01 — Guidance

Use recognised and consistent data format standards to make information exchange easier, increase matching likelihood, and improve system information quality ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart2)).

For lists of standards containing data formats, see:
* [Register of government data content requirements](https://www.data.govt.nz/manage-data/data-content-standardisation/register-of-government-data-content-requirements/)
* [Government digital standards catalogue](https://www.digital.govt.nz/standards-and-guidance/technology-and-architecture/government-digital-standards-catalogue/)

> **Examples of data format standards**:
> * Address (email): RFC 5322 Section 3.4.1
> * Address (residential): ISO 19160—1:2015 Addressing Part 1: Conceptual Model
> * Date: ISO 8601: 2019 Date and time — Representations for information interchange
> * Names: New Zealand Government OASIS CIQ Name Profile

##### IA3.02 Control

The RP MUST establish the level of information assurance (IA) required for each piece of information collected.

**Additional information** — The outcome of the risk assessment can be used to determine the level of assurance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart2-section10))

#### Implementing IA3.02 — Guidance

Use the identification risk assessment process to determine the level of information assurance required. Alternatively, use analytical assessment considering ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart2)):
* Key business drivers and outcomes
* Risk of financial loss or liability
* Risk to privacy, standing, reputation or safety of people
* Harm to agency programmes or public interest
* Direct downstream effects including other parties relying on outcomes

Note that not all information needs the same level of assurance.

> **Examples of information assurance levels**:
> * **Level 4** — Critical information with severe risk and changeable values (e.g., COVID-19 status)
> * **Level 3** — Critical information with high risk and changeable values (e.g., residency status) or severe risk with static values (e.g., non-renewable qualification)
> * **Level 2** — Non-critical decision making information
> * **Level 1** — Information for personalisation, administration and statistics

##### IA3.03 Control

The RP verifies each piece of information using evidence at the established level of information assurance (IA).

For level 1 — The RP SHOULD use the entity as the evidence.

For level 2 — The RP SHOULD select evidence that has at least referenced a copy of an authoritative source as part of their creation.

For level 3 — The RP MUST select evidence that is a copy of an authoritative source, at a minimum.

For level 4 — The RP MUST select evidence that is an authoritative source or has a continuously synchronised link to an authoritative source, such that they are considered equal.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart2-section11))

#### Implementing IA3.03 — Guidance

Evidence for information accuracy typically includes ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart2)):
* Evidence containing or linking to Entity Information from another context (credentials)
* Databases and registers containing Entity Information
* Information or statement provided by the Entity
* Information or statement provided by a trusted third party

The more critical the information and associated risks, the higher the quality of source needed.

At Level 1, accept information from the Entity without seeking assurance. Note that when the Entity is the authority for their information, this qualifies as Level 4 — important if becoming a Credential Provider where [Federation Assurance](#section-4) applies.

Levels 2 and 3 use copies taken at points in time. Consider information criticality and likelihood of change.

Level 4 represents the most up-to-date and accurate source.

> **Examples of authorities and sources**:
> * **Addresses**: NZ Post (PO Boxes), LINZ (property ownership), Entity (where they live/receive mail)
> * **Birth information**: NZ Birth Register (Internal Affairs) for NZ-born, overseas registries for others
> * **Driver licence**: NZ Transport Agency for licence details
> * **Gender identity**: Entity is the authority for self-identification
> * **Preferred name**: Entity is the authority (can use any name not for deceit)

##### IA3.04 Control

The RP MUST NOT assign a level of assurance to evidence whose level has not been declared.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart2-section12))

#### Implementing IA3.04 — Guidance

If a Credential Provider hasn't indicated assurance levels, it's risky to assume them. Ideally, treat them as Level 1. Until level declaration becomes embedded, take a pragmatic approach to accepting higher levels ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart2)).

Estimate levels only in conjunction with the Credential Provider and identification standards expertise.

#### Objective 4 — Quality of evidence

##### Rationale

The level of accuracy of information is also dependent on the trustworthiness of the evidence used. Whether the evidence a credential (physical document, electronic), database or a statement made by the subject or a trusted 3rd party.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart3-section13))

##### IA4.01a Control

The RP establishes the quality of the credential or database evidence is consistent with the level of information assurance (IA) required.

For level 1 and 2 — The RP MUST take the evidence at 'face value'.

For level 3 — The RP MUST base quality on the evidence being manually identified and/or include physical security features that require proprietary knowledge to be able to reproduce it.

For level 4 — The RP MUST base quality on the evidence being systematically identified and accessed through a trusted communication channel.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart3-section14))

#### Implementing IA4.01a — Guidance

Ensure evidence quality is consistent with the required information assurance level ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart3)).

> **Examples of evidence quality**:
> * Documents with manually assessable security features
> * Sophisticated features requiring specialist devices and permissions
> * Digital certificates ensuring online access hasn't been fabricated

##### IA4.01b Control

The RP establishes the quality of the subject or 3rd party statement is consistent with the level of information assurance (IA) required.

For level 1 – The RP MUST take the statement at 'face value'.

For level 2 – The RP MUST ensure the statement maker is aware of the importance of the information being correct.

For level 3 – The RP MUST base the quality of the statement on a declaration or statutory declaration carrying some penalties.

For level 4 – The RP MUST base the quality of the statement on a declaration or statutory declaration associated to severe penalties.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart3-section15))

#### Implementing IA4.01b — Guidance

Base statement quality on pressure not to be false. Apply pressure through penalties like fines or imprisonment. The Criminal Procedure Act 2011 provides penalty level examples ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart3)).

Consider context and available penalties when applying levels.

##### IA4.02a Control

The RP establishes if any credential or database evidence has a registered status (such as suspended or revoked), that makes it unusable.

For level 1 and 2 — The control does not apply.

For level 3 — The RP SHOULD check for registered statuses with evidence issuers or equivalent service providers.

For level 4 — The RP MUST check for registered statuses with evidence issuers or equivalent service providers.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart3-section16))

#### Implementing IA4.02a — Guidance

Establish if evidence has suspended or revoked status, which is difficult without real-time online checking. Various services provide compromised evidence catalogues, and Credential Providers may offer validity checking services ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart3)).

Note that expiry doesn't necessarily mean revocation for all evidence aspects — an expired passport remains invalid for travel but may still evidence certain information.

##### IA4.02b Control

The RP establishes if any subject or 3rd party statement has a contradiction, that makes it unusable.

For level 1 and 2 – The control does not apply.

For level 3 – The RP SHOULD check for contradictory statements.

For level 4 – The RP MUST check for contradictory statements.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart3-section17))

#### Implementing IA4.02b — Guidance

Unlike credentials and databases, there are unlikely to be registers for checking statement status. Look for other statements or evidence that might contradict the statement made ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart3)).

> **Examples of contradictory statements**:
> * Statement about age doesn't match school transition information
> * Statement about qualification doesn't match employment roles

When finding contradictions, investigate further.

#### Objective 5 — Verification integrity is maintained

##### Rationale

There are other processes not directly related to the accuracy of information or quality of evidence that can be used to support and augment the process to provide additional confidence that the information is true. An important element of trust in any identification process is the ability for an Entity or Relying Party to question a process or presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart4-section18))

##### IA5.01 Control

The RP applies counter-fraud techniques, where possible.

For level 1 and 2 – The control does not apply.

For level 3 – The RP SHOULD apply counter-fraud techniques.

For level 4 – The RP MUST apply counter-fraud techniques.

**Additional information** – More information is available in the guide Counter fraud techniques. [Counter fraud techniques](https://docref.digital.govt.nz/nz/identification-management/counter-fraud-techniques/2023/en/)

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart4-section19))

#### Implementing IA5.01 — Guidance

Apply counter fraud techniques as activities that contribute to information assurance after deciding to accept evidence and enrol the Entity. For more information, refer to [Counter fraud techniques](#section-2) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart4)).

##### IA5.02 Control

The RP MUST store appropriate detail about the information verification and evidence to enable queries or investigation in the future.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part3-subpart4-section20))

#### Implementing IA5.02 — Guidance

Keep good records regardless of how you carry out information assurance. The ability to investigate processes contributes to trust building ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart4)).

What and how much you record depends on the risk behind enrolling the Entity plus any legislative requirements, such as the [Public Records Act 2005](http://www.legislation.govt.nz/act/public/2005/0040/latest/DLM345529.html).

---

### 5.3 Implementation Guidance

#### Understanding the risk-based approach

Apply a risk-based approach to information assurance to identify what drives risk levels. Understanding this enables you to develop mitigation strategies ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-para1)).

#### Information collection principles

When collecting information, apply these key principles:

##### Minimal collection
Collect only what you need for your service. Over-collection of information, especially identifying attributes, increases privacy breach and identity theft likelihood when exposed ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart1)).

##### Purpose limitation
For every piece of information, identify its purpose. Consider whether you need:
* The full value
* A derived value (e.g., age instead of date of birth)
* Just a reference to the source

##### Retention management
Once decisions are made, determine if you still need the information or if a record suffices. Information collected solely for verification should be discarded after verification completes.

#### Evidence quality framework

The quality of evidence determines achievable assurance levels. Without checking that evidence is genuine, declared levels won't be achievable ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part2-subpart3)).

Evidence quality requirements scale with assurance levels:
* **Levels 1-2**: Accept at face value
* **Level 3**: Manual verification with security features
* **Level 4**: Systematic verification through trusted channels

#### Related requirements

If you intend to provide information assurance or other identification services to other parties, also apply requirements for [Federation Assurance](#section-4) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-information-assurance-standard/2024/en/#part3-para1)).

---

### 5.4 NCSC Cybersecurity Integration

The National Cyber Security Centre (NCSC) has established 10 Minimum Cybersecurity Standards for New Zealand government agencies. Four of these standards directly relate to and support the Information Assurance Standard controls, providing implementation guidance and cybersecurity requirements that complement identification management practices.

#### NCSC Standards Mapping to Information Assurance Controls

##### Standard 1: Assets and their Importance (Asset Management)

**Maps to IA Controls**: IA2.01, IA2.02, IA2.03

Asset management principles apply directly to entity information lifecycle management. The NCSC requires agencies to maintain comprehensive asset inventories with classifications and lifecycle management processes ([NCSC Minimum Standard 1](https://www.ncsc.govt.nz/protect-your-organisation/assets-and-their-importance/)).

When you manage entity information as a data asset under NCSC Standard 1, you align with IA controls by:
* Maintaining an inventory of what entity information you collect and hold
* Classifying entity information based on sensitivity and privacy impacts
* Establishing retention schedules that respect minimum necessary collection principles

##### Standard 4: Least Privilege (Access Control)

**Maps to IA Controls**: IA2.02, IA3.02, IA4.02a

Least privilege access principles parallel information minimization in identification management. The NCSC mandates role-based access controls and privileged account monitoring ([NCSC Minimum Standard 4](https://www.ncsc.govt.nz/protect-your-organisation/least-privilege/)).

When you apply least privilege principles to information access, you support IA controls by:
* Limiting entity information collection to what staff roles genuinely require
* Monitoring who accesses and verifies sensitive entity information
* Restricting access to information assurance level determination processes

##### Standard 5: Data Recovery (Data Security)

**Maps to IA Controls**: IA2.03, IA2.04, IA5.02

Data recovery requirements ensure you understand what information to protect and retain. The NCSC requires backup strategies, recovery testing, and data classification ([NCSC Minimum Standard 5](https://www.ncsc.govt.nz/protect-your-organisation/data-recovery/)).

When you plan data recovery for entity information, you align with IA controls by:
* Including retention requirements in backup and recovery planning (IA2.03)
* Testing your ability to securely discard verification information when required (IA2.04)
* Maintaining investigation records according to data classification and retention rules (IA5.02)

##### Standard 8: Secure Configuration of Software (Application Security)

**Maps to IA Controls**: IA3.01, IA4.01a, IA4.02a

Software security affects information system integrity and the quality of credentials and databases used for verification. The NCSC requires baseline security configurations, regular audits, and secure-by-design practices ([NCSC Minimum Standard 8](https://www.ncsc.govt.nz/protect-your-organisation/secure-configuration-of-software/)).

When you implement secure software configuration, you support IA controls by:
* Establishing configuration standards that enforce data format requirements for entity information (IA3.01)
* Auditing configurations of systems that access credentials and authoritative databases (IA4.01a)
* Ensuring secure-by-default settings for credential status verification mechanisms (IA4.02a)

#### Summary Mapping Table

| NCSC Standard | NCSC Focus | Primary IA Controls | Integration Point |
|--------------|------------|---------------------|-------------------|
| **1: Assets and their Importance** | Asset management lifecycle | IA2.01, IA2.02, IA2.03 | Entity information as data assets |
| **4: Least Privilege** | Access control and monitoring | IA2.02, IA3.02, IA4.02a | Information minimization principles |
| **5: Data Recovery** | Backup and data protection | IA2.03, IA2.04, IA5.02 | Retention and secure disposal |
| **8: Secure Configuration** | Application security hardening | IA3.01, IA4.01a, IA4.02a | Data format and credential quality |

#### Using This Integration

**For Conformance Assessors**: When assessing Information Assurance Standard conformance, evaluate whether the party has aligned their cybersecurity practices with NCSC standards in these four areas. This demonstrates systemic commitment to information integrity beyond individual IA controls.

**For Implementers**: Treat NCSC standards as complementary requirements that strengthen your identification management practices. Applying these standards reduces security vulnerabilities in systems that handle entity information and verification processes.

**For Policy Makers**: Recognize that NCSC standards provide the cybersecurity foundation upon which reliable identification management is built. Information Assurance controls depend on secure systems, properly managed assets, and sound data protection practices.

**Related Resources**:
* [NCSC Minimum Cybersecurity Standards Overview](https://www.ncsc.govt.nz/protect-your-organisation/minimum-cyber-security-standards/)
* [NCSC Cyber Security Capability Maturity Model](https://www.ncsc.govt.nz/protect-your-organisation/capability-maturity-model/)

---

### 5.5 Conformance Checklist Summary

The Information Assurance Standard contains 14 controls across 5 objectives, with requirements varying by assurance level. For detailed conformance assessment, see [Section 8: Demonstrating Conformance](#section-8).

#### Quick Reference — Information Assurance Controls

##### Core Controls (Apply at all levels)
* **IA1**: Information risk assessment (1 control)
* **IA2**: Information protection through minimal collection (4 controls)
* **IA3**: Information accuracy and format standards (4 controls)

##### Level-Dependent Controls
* **IA4**: Evidence quality verification (4 controls - requirements vary by level)
* **IA5**: Verification integrity and fraud prevention (2 controls - IA5.01 applies at levels 3-4 only)

#### What compliance means

In order to comply with this standard ALL the controls will be met at the level required ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part4-para1)).

Voluntary compliance by any RP wishing to follow good practice for contributing to the prevention of identity theft and fraud, will be against the levels indicated by undertaking a risk assessment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part4-para2)).

Compliance with this Standard given through means such as contractual requirements, Cabinet mandate, legislation etc., will include mechanisms for assessment and certification. The RP will meet the levels determined by the risk assessment and any additional requirements specified ([DocRef](https://docref.digital.govt.nz/nz/identification-management/information-assurance-standard/2024/en/#part4-para3)).

For complete conformance checklists and assessment guidance, refer to [Section 8](#section-8).

---

*Last updated: 27 September 2024*


## Section 6: Authentication Assurance Standard & Implementation

### 6.1 Introduction and Overview

Authentication Assurance ensures that authenticators remain possessed and solely controlled by their authorized holders. This standard provides controls to verify that the entity attempting to access a service is the same entity that was initially enrolled, preventing unauthorized access to information and entitlements ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/)).

#### What authentication assurance covers

The Authentication Assurance Standard addresses:
* **Authenticator establishment** during enrollment or subsequent transactions
* **Authentication strength** through single-factor and multi-factor mechanisms
* **Authenticator lifecycle management** including registration, suspension, expiry, and revocation
* **Protection mechanisms** against guessing, acquisition, replication, forgery, and spoofing
* **Biometric authentication requirements** including false positive management and presentation attack detection

This standard applies to any Relying Party (RP). The RP is accountable for the controls stated in this standard, even if they have employed or contracted aspects to other parties. Application of the controls in this standard will contribute to the reduction of identity fraud by reducing the ability for unauthorised entities to gain access to the information and entitlements belonging to an enrolled entity ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part1-para1)).

#### The four levels of authentication assurance

Authentication assurance provides four graduated levels of confidence:

**Table 1:** Authentication Assurance Levels

| Level | Description | Authentication Requirements |
|---|---|---|
| **LoAA1** | Minimal confidence that the authenticator is controlled by the enrolled entity | Single factor with basic controls |
| **LoAA2** | Some confidence that the authenticator is controlled by the enrolled entity | Single factor with additional controls |
| **LoAA3** | High confidence that the authenticator is controlled by the enrolled entity | Two different factors OR good biometric |
| **LoAA4** | Very high confidence that the authenticator is controlled by the enrolled entity | Two factors including biometric with liveness |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part1))

#### Understanding authentication factors

This standard recognizes three authentication factor types ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part2)):

* **Knowledge factor** — something the Authenticator holder knows (password, PIN, security question)
* **Possession factor** — something the Authenticator holder has (device, token, card)
* **Biometric factor** — something the Authenticator holder is or does (fingerprint, face, voice)

Key principles:
* Combining two or more authentication factors of the **same type** adds some strength but does not reduce overall risk
* Authentication strength is determined by the **best instance** of each authentication factor type
* While three different authentication factors are possible, the extra effort does not significantly improve on the strength obtained by the two strongest factors

#### How authentication relates to other standards

Authentication Assurance works with the other identification standards to provide comprehensive identity verification:

**Table 2:** Assurance components

| Assurance component | Description |
|---|---|
| **IA**: Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information |
| **BA**: Binding Assurance | Robustness of the process to bind the Entity to Entity Information |
| **AA**: Authentication Assurance | **Robustness of the process to ensure an Authenticator remains solely in control of its holder** |
| **FA**: Federation Assurance | Additional steps undertaken to maintain the integrity, security and privacy of a credential used in multiple contexts |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part2-subpart1))

#### Structure of this standard

This standard divides requirements into 2 sections:
* **Requirements for Authentication** — These controls apply regardless of the Authenticators used (Objectives 1-6)
* **Requirements for Authenticator strength by factor** — These controls apply depending on the type of authentication factors the Authenticators use (Objectives 7-10)

---

### 6.2 Standard Objectives and Controls

#### Requirements for Authentication

### AA1 Authentication risk is understood

#### Rationale

For entities to trust that their information is being adequately protected from unauthorised access and use, the authentication level should be consistent with the risk posed.

Relying parties may also need to achieve specific levels of assurance to mitigate risks and potentially to comply with legislation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart1))

#### AA1.01 Control

The RP MUST carry out an assessment of the authentication risk posed by any service before offering it.

**Additional information** — While any risk assessment process can be used, specific guidance is available on [Assessing identification risk](#section-2), of which authentication is a part.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart1))

#### Implementing AA1 — Guidance

Conduct a risk assessment before offering any service requiring authentication. Focus your assessment on ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart1)):

* The value and sensitivity of information or entitlements being protected
* The impact on entities if authentication is compromised
* The likelihood of authentication attacks based on service visibility and value
* Legal or regulatory requirements for authentication strength

Apply the guidance in [Assessing identification risk](#section-2) to improve your assessment quality. A workbook is available to help undertake an identification risk assessment and provide the optimum level of assurance as an output. For a copy, email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).

> **Example**: An online banking service would assess:
> * Financial loss potential from unauthorized transactions
> * Privacy impact from account information exposure
> * Regulatory requirements for financial services authentication
> * Attack likelihood given the high value of bank accounts

When implementing biometric authentication, conduct the proportionality assessment required by the Biometric Processing Privacy Code (see Section 6.4).

### AA2 Ensure correct Authenticator holder behaviour

#### Rationale

Under normal conditions most Authenticator holders will act appropriately, and directive controls can be relatively effective. Penalties can also discourage incorrect behaviour.

However, Authenticator holders might not initially be aware of their obligations, so these need to be communicated. Over time, understanding may diminish, and ongoing reminders may be appropriate.

At the higher levels of assurance, two-factor authentication helps enforce correct behaviour, so too does detecting behaviour that is not normal in the authentication process.

The RP needs to support correct behaviour by providing the means for the Authenticator holder to report loss or compromise of an Authenticator and appropriately manage the loss of control.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### AA2.01 Control

The RP MUST issue terms and conditions describing the authenticator holder's obligations, including:

* the Authenticator is for the sole use of the Authenticator holder
* explaining how the holder will keep the Authenticator safe
* that the holder reports loss of the Authenticator including unauthorised use, sharing, theft of the Authenticator, possible compromise, or any other suspected loss of control of the Authenticator.

**Additional information** — Examples of expected behaviours:

* an access card should not be shared with another employee
* a passport should remain in the traveller's possession
* or a device provided by the Authenticator holder (such as a mobile phone) can only be used as an Authenticator when it's individually possessed and used by the holder.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### AA2.02 Control

The RP MUST provide communication to Authenticator holders reminding them about their obligations, including:

* the Authenticator is for the sole use of the holder
* the holder will keep the Authenticator safe
* that the holder reports loss of the Authenticator including unauthorised use, sharing, theft of the Authenticator, possible compromise, or any other suspected loss of control of the Authenticator.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### AA2.03 Control

The RP limits the ability to share an Authenticator by implementing 2 different factor types.

**For level 1 and 2** — This control does not apply.

**For level 3** — The RP MUST undertake this control.

**For level 4** — The RP MUST undertake this control using a biometric factor as 1 of the factors.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### AA2.04 Control

The RP allows no more than 30 consecutive unsuccessful attempts to authenticate by any factor, disables the account and triggers further investigation.

**For level 1 and 2** — This control does not apply.

**For level 3** — The RP SHOULD apply this control.

**For level 4** — The RP MUST apply this control.

**Additional information** — This control limits the total attempts by an attacker for any single challenge or combination of challenges of more than 1 authentication factor type. This upper limit applies to prevent multiple attempts that are only partially mitigated by subsequent controls such as the 30-minute timeout after a maximum of 5 incorrect attempts.

Where appropriate to the implementation, the RP MAY allow up to 3 re-entries for the same challenge attempt, for example the same received code for the code receiver method.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### AA2.05 Control

The RP MUST provide the means for the holder to report loss or compromise of an Authenticator, and can either:

* deregister the Authenticator and support a process for reregistration; or
* if appropriate, close the associated account and require reenrolment.

**Additional information** — Where a biometric factor is used and compromise was not prevented by presentation attack detection, disabling needs to include deregistering as the biometric characteristic cannot be revoked.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart2))

#### Implementing AA2 — Guidance

Establish clear communication channels and processes to ensure authenticator holders understand and fulfill their obligations ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart2)).

##### Terms and conditions (AA2.01)

Present terms and conditions clearly during enrollment:
* Use plain language that entities can understand
* Highlight critical obligations prominently
* Require explicit acknowledgment before issuing authenticators
* Make terms accessible for future reference

For biometric authentication, include the transparency requirements from the Biometric Processing Privacy Code (see Section 6.4.2).

##### Ongoing reminders (AA2.02)

Implement regular reminder strategies:
* Send periodic emails or notifications about security obligations
* Display reminders at login or during high-risk transactions
* Include security tips in account statements or regular communications
* Provide just-in-time reminders when detecting unusual behavior

> **Example reminder schedule**:
> * Initial: During enrollment and authenticator establishment
> * Regular: Quarterly security reminders via email
> * Contextual: When accessing sensitive functions
> * Reactive: After detecting failed authentication attempts

##### Multi-factor implementation (AA2.03)

For Level 3 and 4, implement two different factor types:
* Combine something they know with something they have (Level 3)
* Include a biometric factor as one of the two factors (Level 4)
* Ensure factors are truly independent (compromise of one doesn't affect the other)

##### Failed attempt management (AA2.04)

Implement progressive lockout mechanisms:
* Track consecutive failed attempts across all authentication methods
* Apply time-based lockouts after threshold breaches
* Trigger security reviews for accounts with repeated lockouts
* Consider risk-based adjustments (stricter for high-value accounts)

##### Compromise reporting (AA2.05)

Provide multiple channels for reporting compromised authenticators:
* 24/7 hotline for urgent reports
* Online self-service portal for immediate action
* Clear instructions on website and documentation
* Automated confirmation of reports received and actions taken

For biometric factors, implement the deletion requirements from the Biometric Processing Privacy Code (see Section 6.4.2) as biometric characteristics cannot be changed like passwords.

### AA3 Entity binding and Authenticator strength are consistent

#### Rationale

An Authenticator can be established during enrolment or later during a subsequent transaction. In either case it is essential to ensure that the Entity has been bound to the Entity Information at the required level of assurance before attempting to bind an Authenticator.

If there has been a disruption in the binding transaction this will necessitate repeating Entity Binding when the transaction is resumed.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart3))

#### AA3.01 Control

The RP MUST ensure that the Entity Binding is done in the same transaction session as the Authenticator is established.

**Additional information** – An Authenticator is not always issued when Entity Information and Entity Binding occur. If the implementation has the establishment of an Authenticator occurring in a separate transaction, a temporary Authenticator can be used to represent the Entity Binding process having previously been undertaken, providing they have the same level of assurance and this is the same or higher than the Authenticator. If the Authenticator being established is for a new delivery channel an existing Authenticator may be presented to confirm Entity Binding, provided it has an equal or greater level of assurance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart3))

#### AA3.02 Control

The RP MUST ensure the strength of the Authenticator is consistent with the level of binding assurance (BA) required.

**Additional information** – Any strength perceived to be gained by using an Authenticator of a higher level of assurance is negated when the corresponding Entity Binding assurance is lower.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart3))

#### Implementing AA3 — Guidance

Maintain consistency between entity binding and authenticator establishment to prevent security gaps ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart3)).

##### Same session requirement (AA3.01)

Complete entity binding and authenticator establishment in a single transaction:
* Design enrollment workflows to avoid session breaks
* If sessions must span multiple interactions, use temporary authenticators
* Validate that binding remains valid before establishing authenticators
* Re-verify entity binding if the session is interrupted

> **Example workflow**:
> 1. Entity provides identity evidence (binding begins)
> 2. System verifies evidence and binds entity to information
> 3. In same session, entity establishes authenticator
> 4. System confirms authenticator control before activation

##### Strength consistency (AA3.02)

Match authenticator strength to binding assurance level:
* Level 1 binding → Level 1 authentication acceptable
* Level 2 binding → Up to Level 2 authentication
* Level 3 binding → Up to Level 3 authentication
* Level 4 binding → Up to Level 4 authentication

Never implement authenticators stronger than the binding level, as this provides false confidence. See [Section 7: Binding Assurance](#section-7) for binding level requirements.

### AA4 Entity can control Authenticator

#### Rationale

Associating an Authenticator with Entity Information without first ensuring that the Entity has control of it, can result in an inability for it to be used by the Entity in a future Authentication event or increases the risk of coercion and impersonation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart4))

#### AA4.01 Control

The RP MUST ensure that the Entity can respond to all the Authenticator's challenges before the Authenticator is recorded as active in Entity Information.

**Additional information** – Depending on the implementation there may be a need to record the existence of the Authenticator in Entity Information before the challenges can be tested. However, the Authenticator will not be available as a recognition mechanism until successful completion of the challenges.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart4))

#### AA4.02 Control

The RP establishes if the Authenticator has been previously compromised to the extent it makes it unusable.

**For level 1 and 2** – The control does not apply

**For level 3** – The RP SHOULD check for compromise with Authenticator issuers or equivalent service providers.

**For level 4** – The RP MUST check for compromise with Authenticator issuers or equivalent service providers.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart4))

#### Implementing AA4 — Guidance

Verify entity control of authenticators before activation to prevent unauthorized registrations ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart4)).

##### Control verification (AA4.01)

Test all authentication challenges before activation:
* For passwords: Require initial entry and confirmation
* For devices: Send verification code and require correct entry
* For biometrics: Capture sample and verify successful match
* For multi-factor: Test each factor independently

Record authenticators as "pending" until control is verified, then activate only after successful challenge completion.

> **Example device verification**:
> 1. Entity registers mobile phone number
> 2. System sends SMS with verification code
> 3. Entity enters code to prove possession
> 4. System activates phone as authenticator

For biometric factors, follow the direct collection requirements from the Biometric Processing Privacy Code (see Section 6.4.2).

##### Compromise checking (AA4.02)

For Levels 3 and 4, check authenticator compromise status:
* Query breach databases for exposed passwords
* Verify device certificates haven't been revoked
* Check biometric templates against known compromise lists
* Validate authenticator apps against known vulnerable versions

Reject compromised authenticators and guide entities to secure alternatives.

### AA5 Authenticator registration status is maintained

#### Rationale

Authenticators have lifecycles distinct from the Entity and Entity Information. Authenticators can be reused in multiple contexts, therefore connected to different instances of Entity Information. The Authenticator Registration status provides information to the Authentication process as to whether an Authenticator should be accepted, even if the responses to challenges are successful. Typical statuses can include: active, suspended, expired and revoked.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart5))

#### AA5.01 Control

The RP MUST record enough information in Entity Information for an Authenticator to be recognised and its Authenticator Registration status to be managed.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart5))

#### AA5.02 Control

The RP MUST be able to update the Authenticator Registration status to prevent authentication occurring, even if the responses to challenges are successful.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart5))

#### AA5.03 Control

The RP MUST NOT accept an Authentication event as successful unless the Authenticator Registration status allows.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart5))

#### AA5.04 Control

The RP MUST be able to set an expiry on an Authenticator Registration where the implementation indicates this to be desirable.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart5))

#### Implementing AA5 — Guidance

Maintain comprehensive authenticator lifecycle management to ensure only valid authenticators remain active ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart5)).

##### Registration records (AA5.01)

Record sufficient information for each authenticator:
* Unique identifier for the authenticator
* Type and authentication factor category
* Registration date and time
* Current status (active, suspended, expired, revoked)
* Last successful use date
* Failed attempt counter

For biometric authenticators, include retention period information as required by the Biometric Processing Privacy Code (see Section 6.4.2).

##### Status management (AA5.02)

Implement status transitions:
* **Active**: Normal operation allowed
* **Suspended**: Temporarily disabled (e.g., during investigation)
* **Expired**: Past validity period
* **Revoked**: Permanently disabled

Provide administrative interfaces to update status immediately when needed.

##### Status enforcement (AA5.03)

Check status before accepting authentication:
* Query current status at each authentication attempt
* Reject authentication if status is not "active"
* Log attempted use of non-active authenticators
* Provide appropriate error messages to guide legitimate users

##### Expiry management (AA5.04)

Set appropriate expiry periods:
* Passwords: 90-365 days depending on risk level
* Certificates: Based on certificate validity period
* Biometric templates: As defined in retention policy (see Section 6.4.2)
* Temporary authenticators: Short periods (hours or days)

Notify entities before expiry and provide smooth renewal processes.

### AA6 Authentication events can be investigated

#### Rationale

An important element of trust in any identification process is the ability for an Entity or Relying Party to question a process or presentation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart6))

#### AA6.01 Control

The RP MUST record appropriate detail about the Authenticator establishment process to enable queries or investigation in the future.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart6))

#### AA6.02 Control

The RP MUST store appropriate detail about an authentication event to enable queries or investigation in the future.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part3-subpart6))

#### Implementing AA6 — Guidance

Maintain comprehensive audit trails for accountability and investigation ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part2-subpart6)).

##### Establishment records (AA6.01)

Document the authenticator establishment process:
* Date, time, and method of establishment
* Identity verification performed (link to binding records)
* Authenticator type and strength level
* Control verification results
* Any anomalies or exceptions noted

For biometric authenticators, record the transparency information provided as required by the Biometric Processing Privacy Code (see Section 6.4.2).

##### Authentication event logging (AA6.02)

Record each authentication attempt:
* Timestamp and source (IP address, device ID)
* Authenticator used and factor types
* Success or failure result
* Number of attempts if multiple tries
* Any risk indicators or anomalies detected

Retain logs according to your data retention policy and legal requirements. Ensure logs are tamper-evident and securely stored.

> **Example investigation scenario**:
> Entity reports unauthorized account access. Logs show:
> * Successful authentication from unusual location
> * Different device fingerprint than usual
> * Time outside normal usage pattern
> * Investigation reveals credential compromise

#### Requirements for Authenticator Strength by Factor

### AA7 Protect knowledge factor response from being guessed or discovered

#### Rationale

An unauthorised entity can obtain control of a knowledge factor by providing the response that the challenger expects. This threat is most significant when the expected response is static, as once obtained it can be used for multiple authentications. If an expected response is dynamic, then the correct initial response cannot be reused for a subsequent authentication.

Widespread attacks across many Authenticators utilise some form of guessing which may follow sequences, patterns, lists such as dictionaries, or similar techniques.

Targeted attacks on a few Authenticators may utilise some form of discovery to obtain the possible correct responses such as manipulating the holder into disclosing the response or using a list of previously compromised list secrets or the underlying key used to generate a response.

Limiting the number of unsuccessful attempts within a time period is an effective way of controlling automated guessing attacks.

These controls apply where a knowledge factor is used. The controls for replicating the codes related to non-physical challenges on possession factors are covered under Objective 9.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart1))

#### AA7.01 Control

The RP implements minimum levels of complexity on any knowledge factor response (secret).

**For level 1 and 3** — The RP MUST require a minimum complexity of 4 numeric characters or utilise an equivalent level of complexity for responses such as swiping points, matching pictograms, etc.

**For level 2 and 4** — The RP MUST require a minimum complexity of:

* 12 characters; or
* 7 characters from at least 3 of the lower case, upper case, numeric and symbol character sets; or
* an equivalent level of complexity for responses such as swiping points, matching pictograms, security questions, etc.

**Additional information** — Upper limits on characters should be set high enough to encourage the use of memorable phrases.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart1))

#### AA7.02 Control

The RP limits the creation of easily guessable knowledge factor responses by disallowing repetition or patterns and where the Authenticator has the form of an online password, apply the following exclusions (as applicable to the character sets being used):

* disallow repetitive or sequential characters
* disallow specific words, for example the identifier (for example, username), name of the service etc.
* disallow singular dictionary words and common character substitutions
* disallow passwords contained in blacklists (usually include overly common combinations and compromised passwords).

**For level 1 and 3** — The RP SHOULD undertake this control.

**For level 2 and 4** — The RP MUST undertake this control.

**Additional information** — These controls are best implemented using a strength meter during knowledge factor establishment.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart1))

#### AA7.03 Control

The RP implements maximum limits for unsuccessful attempts and prevents further attempts for a minimum period.

**For level 1** — The RP SHOULD limit unsuccessful attempts to 10 and further attempts for 15 minutes minimum.

**For level 2 and above** — The RP MUST limit unsuccessful attempts to 5 and disallow further attempts for 30 minutes minimum.

**Additional information** — In some circumstances, it may be reasonable for the RP to rely on the time and effort taken to provide a response — such as entering a PIN code, as a default control against guessing.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart1))

#### AA7.04 Control

The RP prevents use of a guessed or discovered knowledge factor by combining it with an authentication factor of another type.

**For level 1 and 2** — This control does not apply.

**For level 3** — The RP MUST undertake this control.

**For level 4** — The RP MUST undertake this control using a biometric factor as the second factor.

**Additional information** – While at level 4 this objective could be met by combining a knowledge factor with a possession factor, it has been restricted to a biometric factor to be consistent with the need for that combination in other level 4 controls.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart1))

#### Implementing AA7 — Guidance

Protect knowledge factors through complexity requirements, guessing prevention, and multi-factor authentication ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part4-subpart1)).

##### Complexity requirements (AA7.01)

Enforce appropriate password complexity:

**For Levels 1 and 3**:
* Minimum 4 digits for PINs
* Equivalent entropy for pattern-based authentication

**For Levels 2 and 4**:
* Option 1: 12+ character passphrases (encourage full sentences)
* Option 2: 7+ characters with mixed character sets
* Set maximum length high (e.g., 128 characters) to allow passphrases

> **Example passphrase**: "My cat Felix loves sleeping in sunny spots!" (43 characters, memorable, high entropy)

##### Pattern prevention (AA7.02)

Implement intelligent password checking:
* Block sequential patterns (123456, abcdef)
* Prevent keyboard walks (qwerty, asdfgh)
* Check against breach databases (HaveIBeenPwned)
* Reject context-specific words (username, service name)
* Provide real-time strength feedback during creation

Use password strength meters that explain why passwords are weak and suggest improvements.

##### Attempt limiting (AA7.03)

Implement progressive lockout:

**Level 1**:
* Allow 10 attempts
* Lock for 15 minutes after threshold

**Levels 2-4**:
* Allow 5 attempts
* Lock for 30 minutes after threshold
* Consider increasing lockout duration for repeated violations

Track attempts across all channels (web, mobile, API) to prevent bypass attempts.

##### Multi-factor protection (AA7.04)

For Levels 3 and 4, combine knowledge with another factor:
* Level 3: Add possession factor (SMS code, authenticator app)
* Level 4: Add biometric factor (fingerprint, facial recognition)

Ensure factors are independent—compromising the password shouldn't compromise the second factor.

### AA8 Prevent use of a physically acquired possession factor

#### Rationale

An Authenticator may be compromised by being physically acquired by someone else.

Possession factors can be acquired by another entity as occasional unauthorised usage or permanent theft.

Where a possession factor is a physical item, the Authenticator holder can become aware that it has been stolen. Requirements for non-physical challenges on possessions and biometric characteristics are covered under Objective 9.

This control applies where a possession factor is used.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart2))

#### AA8.01 Control

The RP prevents use of a physically acquired possession factor by combining it with an authentication factor of another type.

**For level 1 and 2** — This control does not apply. Controls in Objective 2 serve.

**For level 3** — The RP MUST undertake this control.

**For level 4** — The RP MUST undertake this control using a biometric factor as the second factor.

**Additional information** — This objective could be met by combining a possession with a knowledge factor. However, the level 4 requirement has been restricted to a biometric factor to be consistent with the need for this combination in other level 4 controls.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart2))

#### Implementing AA8 — Guidance

Protect against unauthorized use of stolen or borrowed possession factors through multi-factor authentication ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part4-subpart2)).

For Levels 3 and 4, combine possession factors with another factor type:

**Level 3 implementation**:
* Smart card + PIN
* Mobile device + password
* Hardware token + knowledge challenge

**Level 4 implementation**:
* Smart card + fingerprint
* Mobile device + facial recognition
* Hardware token + voice biometric

Design the authentication flow to require both factors in the same session. The possession factor proves the entity has the device, while the second factor proves they are the authorized holder.

> **Example**: Employee badge (possession) combined with fingerprint (biometric) for data center access—if the badge is stolen, the thief cannot use it without the authorized holder's fingerprint.

### AA9 Protecting against replication, forgery, or spoofing of possession and biometric factors

#### Rationale

Authenticators need to be protected against replication, forgery or spoofing by an attacker including the ability to provide the expected static response or 1 or more dynamic responses.

Knowledge-based Authenticators have been covered in Objectives 7.

Threats against possession-based Authenticators can take the following forms:

* replication or forgery of documents or devices that must be physically presented for manual or automated challenge
* replication of the codes (static or dynamic) used to respond to non-physical challenges on possession of a document, device or software
* replication of the value that represents existence in a specific location.

The RP needs to ensure that Authenticators based on biometric factors are protected against presentation by another entity (spoofing), including the construction of the expected static response, cloning of 1 or more live responses, or the means to produce all expected live responses.

Some level of protection is provided due to the effort required to undertake successful replication or forgery of a possession factor or spoofing of a biometric.

The requirement for two-factor authentication that protects against physical acquisition at higher levels of assurance also mitigates replication of the expected responses to possession factor challenges.

These controls apply where possession and biometric factors are used.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### AA9.01 Control

The RP MUST protect against replication or forgery of a physically presented Authenticator by incorporating features that ensure the cost of doing so is relative to the level of assurance.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### AA9.02 Control

The RP uses dynamic, non-predictable responses to non-physical challenges on possession factors and limits the response validity to a maximum of 10 minutes or 1 minute, where little messaging delay exists.

**For level 1** — The RP MAY undertake this control.

**For level 2 and above** — The RP MUST undertake this control.

**Additional information** — The limits need to be sufficiently short to reduce malicious reuse and sufficiently long to be useable by the holder. They can be influenced by the holder group (for example, technologically savvy versus challenged) and the type of Authenticator (for example, code receiver versus code generator).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### AA9.03 Control

The RP MUST, for responses to non-physical challenges on possession factors, utilise a minimum complexity of:

* 6 numeric characters; or
* 4 alphanumeric characters; or
* an equivalent level for other codes such as pictograms.

**Additional information** — For usability or avoidance of inappropriate words, some alphanumeric characters MAY be restricted when generating the received codes.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### AA9.04 Control

The RP addresses spoofing of biometric challenges by ensuring the biometric response is obtained from the person using appropriate measures to detect spoofing attempts (for example, recordings, masks, makeup or prosthetics etc.)

**For level 1** — The RP SHOULD undertake this control.

**For level 2 and above** — The RP MUST undertake this control.

**Additional information** — This control can also help reduce the occurrence of false acceptance of biometric comparisons when spoofing attempts are successfully recognised.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### AA9.05 Control

The RP obtains biometric factor samples in person or remotely incorporating liveness checking which demonstrates at least 90% resistance to presentation attacks.

**For level 1 to 3** — This control does not apply.

**For level 4** — The RP MUST undertake this control.

**Additional information** — Manual collection of biometric samples in person is comparable if not superior, to automated collection. Current best minimum practice for resistance to presentation attacks using technology is the use of Clause 12 of [ISO/IEC 30107-3](https://www.iso.org/obp/ui/#iso:std:iso-iec:30107:-3:ed-1:v1:en).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart3))

#### Implementing AA9 — Guidance

Implement robust anti-forgery and anti-spoofing measures appropriate to the assurance level ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part4-subpart3)).

##### Physical authenticator protection (AA9.01)

Build forgery-resistant features into physical authenticators:
* Security printing techniques (watermarks, holograms)
* Tamper-evident materials
* Cryptographic chips in smart cards
* Unique serial numbers with verification databases

Scale security features to match the assurance level—higher levels warrant more sophisticated (and expensive) protections.

##### Dynamic code implementation (AA9.02)

Use time-limited, one-time codes for possession factors:
* SMS or email codes: 10-minute validity maximum
* TOTP (authenticator apps): 30-60 second windows
* Push notifications: 1-2 minute response window
* Never allow code reuse after successful authentication

> **Example code flow**:
> 1. Generate random 6-digit code
> 2. Send via SMS/email/app
> 3. Start 10-minute countdown
> 4. Accept code once only
> 5. Invalidate after use or timeout

##### Code complexity (AA9.03)

Generate codes with sufficient entropy:
* Numeric: 6 digits minimum (1 million combinations)
* Alphanumeric: 4 characters minimum
* Exclude ambiguous characters (0/O, 1/l/I)
* Use cryptographically secure random generation

##### Biometric spoofing prevention (AA9.04)

Implement presentation attack detection (PAD):
* For facial recognition: Check for photos, videos, masks
* For fingerprints: Detect silicone, gelatin, printed copies
* For voice: Identify recordings or synthesized speech
* Use multiple detection techniques for defense in depth

For biometric systems, comply with the fair collection requirements of the Biometric Processing Privacy Code (see Section 6.4.2).

##### Liveness checking (AA9.05)

For Level 4, implement strong liveness detection:
* Challenge-response actions (blink, smile, turn head)
* Passive liveness (blood flow, 3D depth, texture analysis)
* Meet ISO/IEC 30107-3 standards (90% attack resistance)
* Combine multiple liveness indicators

Ensure liveness checking methods are not unreasonably intrusive, as required by the Biometric Processing Privacy Code (see Section 6.4.2).

### AA10 Managing biometric factor probability

#### Rationale

Biometric characteristics suitable for authentication are substantively unique to individual entities. Therefore, an Authenticator with a biometric factor challenge is potentially a more reliable means of authenticating a specific entity than a knowledge or possession factor. However, unlike the other 2 factor types, a biometric response is probabilistic rather than binary.

There remains the possibility that a manual or systematic comparison will incorrectly match a biometric response from another entity with that of the enrolled entity, resulting in a false positive response to the challenge.

At lower levels of assurance, false positives for a biometric factor challenge should be less than the unmitigated risks for knowledge or possession factor challenges.

There are no additional controls for the lower levels and the RP will need to accept that a small proportion of false positive results may be received.

For higher levels of assurance, an Authenticator with a biometric factor needs to have a very low false positive rate and be used in combination with another authentication factor to protect against the statistical possibility of incorrect authentication.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart4))

#### AA10.01 Control

The RP reduces the occurrence of false positives in biometric comparisons by using:

* manual comparison of the biometric characteristic by a trained operator
* systematic comparison with a rate of <0.01% false positives, based on a one-to-one comparison.

**For level 1 and 2** — This control does not apply

**For level 3** — The RP MUST undertake the control using 1 of the ways stated

**For level 4** — The RP MUST use systematic comparison.

**Additional information** — At level 4 manual comparison may be used, however, it needs to be supported by systematic comparison.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart4))

#### AA10.02 Control

The RP protects against the probabilistic nature of biometric comparisons by combining it with an authentication factor of another type.

**For level 1 and 2** — This control does not apply.

**For level 3** — The RP MUST undertake this control, when using manual comparison.

**For level 4** — The RP MUST undertake this control.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part4-subpart4))

#### Implementing AA10 — Guidance

Manage the probabilistic nature of biometric authentication through accuracy controls and multi-factor requirements ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part4-subpart4)).

##### False positive reduction (AA10.01)

**For Level 3**, choose one approach:

**Manual comparison**:
* Train operators in biometric comparison techniques
* Provide clear comparison guidelines and tools
* Implement quality assurance on operator decisions
* Combine with another factor (AA10.02 requirement)

**Systematic comparison**:
* Configure false match rate (FMR) below 0.01%
* Regularly test and calibrate biometric systems
* Monitor actual false positive rates in production
* Adjust thresholds based on operational data

**For Level 4**, use systematic comparison:
* Implement automated biometric systems
* Achieve FMR < 0.01% (1 in 10,000)
* May supplement with manual review for exceptions
* Document system accuracy metrics

##### Multi-factor requirement (AA10.02)

Combine biometrics with another factor type:

**Level 3 with manual comparison**: Always required
**Level 4**: Always required

Common combinations:
* Face + password (knowledge factor)
* Fingerprint + smart card (possession factor)
* Voice + SMS code (possession factor)

The second factor compensates for the probabilistic nature of biometric matching, providing defense against false positives.

> **Example accuracy calculation**:
> * Biometric system: 0.01% false positive rate
> * Password: 1 in 100,000 guess probability
> * Combined: Approximately 1 in 1 billion false acceptance

When implementing biometric systems, include false positive rates in the proportionality assessment required by the Biometric Processing Privacy Code (see Section 6.4.2).

---

### 6.3 Implementation Guidance Summary

#### Selecting appropriate authentication levels

Choose authentication levels based on risk assessment and service requirements ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part5)):

**Table 3:** Authentication Level Selection Guide

| Service Risk | Examples | Recommended Level |
|---|---|---|
| **Low** | Public information, newsletters | LoAA1 |
| **Moderate** | Personal profiles, non-financial services | LoAA2 |
| **High** | Financial transactions, health records | LoAA3 |
| **Very High** | Critical infrastructure, high-value transfers | LoAA4 |

#### Common authenticator combinations by level

**Level 1**: Single factor
* 4-digit PIN
* Simple password
* Email verification

**Level 2**: Single factor with controls
* Complex password (12+ characters)
* SMS codes with rate limiting
* Authenticator app codes

**Level 3**: Two different factors
* Password + SMS code
* Smart card + PIN
* Biometric + password (with FMR < 0.01%)

**Level 4**: Two factors including biometric
* Biometric (with liveness) + smart card
* Biometric (with liveness) + complex password
* Biometric (with liveness) + cryptographic token

#### Authentication lifecycle management

Implement comprehensive lifecycle processes:

1. **Establishment**: Verify control, check compromise, record details
2. **Activation**: Enable for authentication after verification
3. **Maintenance**: Monitor usage, remind of obligations, manage status
4. **Renewal**: Update before expiry, re-verify control
5. **Revocation**: Disable immediately on compromise, delete when appropriate

For biometric authenticators, follow the retention and deletion requirements of the Biometric Processing Privacy Code (see Section 6.4.2).

---

### 6.4 Biometric Processing Privacy Code Requirements

#### 6.4.1 Introduction to Biometric Privacy Requirements

**⚠️ MANDATORY LAW**: The Biometric Processing Privacy Code 2025 is mandatory law under the Privacy Act 2020, with strict compliance dates ([Biometric Processing Privacy Code](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/)):

* **3 November 2025** — All new biometric processing must comply
* **3 August 2026** — All existing biometric processing must comply

This Code applies to **all biometric authentication systems** implementing the Authentication Assurance Standard. Any use of biometric factors (AA2.03, AA2.04, AA7.04, AA8.01, AA9.04, AA9.05, AA10.01, AA10.02) **must comply with this Code**.

##### Who must comply

Any organization that:
* Collects biometric information for authentication
* Processes biometric templates or characteristics
* Stores biometric data for identity verification
* Uses facial recognition, fingerprints, voice, iris, or other biometric factors

Non-compliance may result in:
* Privacy Commissioner investigations and determinations
* Compliance notices requiring specific actions
* Compensation orders for affected individuals
* Reputational damage and loss of public trust

#### 6.4.2 The 13 Biometric Privacy Rules

The Code establishes comprehensive requirements through 13 rules. Key rules for authentication systems include:

##### Rule 1: Purpose of Collection (Necessity and Proportionality)

**You must not collect biometric information unless** ([Rule 1](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-1/)):

1. **Lawful Purpose**: The biometric processing serves a lawful purpose connected with your function
2. **Necessity**: Biometric processing is necessary, meaning:
   * It effectively achieves the purpose
   * The purpose cannot reasonably be achieved as effectively by less privacy-invasive means
3. **Privacy Safeguards**: You have adopted reasonable privacy safeguards
4. **Proportionality**: You believe on reasonable grounds the processing is proportionate to likely impacts

**Proportionality Assessment must consider**:
* The scope, extent, and degree of privacy risk
* Whether benefits outweigh privacy risks
* Cultural impacts and effects on Māori
* Alternative authentication methods available

> **Example proportionality decision**:
> A library considering biometric authentication would likely fail the necessity test—the risk and value of library services doesn't justify biometric collection when passwords suffice. However, a nuclear facility would likely pass—the extreme security requirements justify biometric authentication.

##### Rule 2: Source of Biometric Sample (Direct Collection)

**Biometric samples must be collected directly from the individual concerned** ([Rule 2](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-2/)).

This means:
* No covert biometric collection
* No using photos from social media for facial recognition enrollment
* No collecting fingerprints from objects people touch
* The individual must actively provide their biometric sample

This aligns with AA4.01 requiring the entity can respond to authenticator challenges.

##### Rule 3: Collection of Information from Individual (Transparency)

**When collecting biometric information, you must tell the individual** ([Rule 3](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-3/)):

1. That biometric information is being collected
2. Each specific purpose for collection
3. **Whether alternatives to biometric processing are available**
4. Who will receive the information
5. Your organization's name and contact details
6. Whether providing biometrics is voluntary or mandatory
7. Consequences if biometrics are not provided
8. Rights to access and correct biometric information
9. **Your retention period for biometric information**
10. How to raise concerns or complain
11. The right to complain to the Privacy Commissioner
12. Where to find your proportionality assessment (if public)

This information must be:
* **Clear and conspicuous**
* Provided **before or when** collecting biometrics
* Accessible for future reference

> **Example transparency notice**:
> "We use facial recognition for account security (purpose). You may choose password authentication instead (alternative). We delete biometric templates 90 days after account closure (retention). See our full biometric privacy notice at [URL]. Contact privacy@example.com with concerns."

##### Rule 4: Manner of Collection (Fair Collection)

**Collection must be lawful, fair, and not unreasonably intrusive** ([Rule 4](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-4/)).

Consider:
* Is the collection method respectful and dignified?
* Are you collecting from children or vulnerable persons? (extra care required)
* Does liveness checking create undue burden or embarrassment?
* Are collection environments appropriate (lighting, privacy, accessibility)?

This affects AA9.04 (spoofing detection) and AA9.05 (liveness checking) implementation.

##### Rule 5: Storage and Security (Template Security)

**You must protect biometric information with reasonable security safeguards against** ([Rule 5](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-5/)):
* Loss
* Unauthorized access, use, modification, or disclosure
* Other misuse

Requirements:
* Encrypt biometric templates at rest and in transit
* Implement access controls and audit logging
* Use secure deletion methods when removing templates
* If using service providers, ensure they maintain security

This reinforces AA9.01 (protect against replication) and relates to AA5.01-AA5.04 (registration management).

##### Rule 9: Retention (Deletion Requirements)

**You must not keep biometric information longer than required for lawful purposes** ([Rule 9](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-9/)).

This means:
* Define clear retention periods
* Delete templates when accounts close
* Remove biometrics when purpose expires
* Implement automated deletion processes

**Critical for AA2.05**: When biometric compromise occurs, templates must be deleted (not just disabled) as biometric characteristics cannot be changed like passwords.

##### Rule 10: Limits on Use (Purpose Limitation)

**Biometric information collected for one purpose must not be used for another purpose** ([Rule 10](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/rule-10/)).

Prohibitions:
* Authentication biometrics cannot be used for surveillance
* Cannot repurpose for emotion/demographic analysis
* Cannot share between unrelated systems
* Biometric categorization generally prohibited

> **Prohibited example**:
> Facial recognition collected for building access (authentication) cannot also be used for tracking employee movements (surveillance) or analyzing emotional states (categorization).

#### 6.4.3 Integration with Authentication Assurance Standard

The Biometric Processing Privacy Code requirements map directly to AA controls:

**Table 4:** Privacy Code to AA Standard Mapping

| Privacy Code Rule | AA Control | Integration Requirement |
|---|---|---|
| Rule 1 (Necessity) | AA1.01 | Include proportionality in risk assessment |
| Rule 1 (Necessity) | AA2.05 | Justify why biometrics needed at this level |
| Rules 2-4 (Collection) | AA4.01 | Ensure direct, fair collection with control verification |
| Rule 3 (Transparency) | AA2.01-AA2.02 | Include all Rule 3 requirements in terms and reminders |
| Rule 5 (Security) | AA9.01, AA9.04-AA9.05 | Implement security for templates and PAD |
| Rule 9 (Retention) | AA5.04, AA2.05 | Set expiry, delete on compromise |
| Rule 10 (Purpose) | AA3.01-AA3.02 | Limit to authentication purpose only |

##### For Level 3 Authentication (Biometric Optional)

If choosing biometric authentication at Level 3:
1. **Conduct full Rule 1 necessity assessment** — Document why biometrics are proportionate
2. **Provide Rule 3 transparency** — Clearly state password/token alternatives exist
3. **Implement Rule 5 security** — Protect templates to same standard as other authenticators
4. **Follow Rule 9 retention limits** — Delete when no longer needed
5. **Enforce Rule 10 purpose limitation** — Use only for authentication

##### For Level 4 Authentication (Biometric Mandatory)

Level 4 requires a biometric factor. You must:
1. **Justify in Rule 1 assessment** — Explain why highest assurance level is necessary
2. **Address no-alternative scenario** — Rule 3 requires explaining why biometrics are mandatory
3. **Implement liveness checking fairly** — Rule 4 requires non-intrusive methods for AA9.05
4. **Apply strongest template security** — Rule 5 critical as biometrics cannot be changed
5. **Plan for compromise** — Rule 9 deletion requirements when AA2.05 triggered

#### 6.4.4 Biometric Compliance Checklist

**Every organization using biometric authentication MUST**:

**Before Implementation**:
- [ ] Conduct Rule 1 necessity and proportionality assessment
- [ ] Document why less invasive alternatives insufficient
- [ ] Assess cultural impacts, particularly on Māori
- [ ] Prepare Rule 3 transparency notices
- [ ] Design fair, non-intrusive collection methods
- [ ] Plan retention periods and deletion processes

**During Collection**:
- [ ] Collect biometrics directly from individuals (Rule 2)
- [ ] Provide all Rule 3 information before/at collection
- [ ] Explain any available alternatives clearly
- [ ] Use fair, dignified collection methods (Rule 4)
- [ ] Take special care with children/vulnerable persons
- [ ] Record what transparency information was provided

**Ongoing Management**:
- [ ] Maintain security safeguards (Rule 5)
- [ ] Monitor for compromise or misuse
- [ ] Delete templates at end of retention period (Rule 9)
- [ ] Prevent scope creep beyond authentication (Rule 10)
- [ ] Handle compromise per AA2.05 with deletion
- [ ] Maintain audit trails per AA6.01-AA6.02

**If Compromise Occurs**:
- [ ] Immediately disable affected templates (AA5.02)
- [ ] Delete compromised templates (Rule 9 + AA2.05)
- [ ] Notify affected individuals
- [ ] Support re-enrollment with new biometrics if possible
- [ ] Document incident and response

**Annual Review**:
- [ ] Review necessity assessment remains valid
- [ ] Confirm alternatives still insufficient
- [ ] Verify retention periods are followed
- [ ] Check templates deleted as scheduled
- [ ] Update transparency notices if needed
- [ ] Test security safeguards effectiveness

#### 6.4.5 Additional Resources

For complete compliance information:
* [Full Biometric Processing Privacy Code 2025](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/)
* [Overview of Code Rules](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/overview-of-code-rules/)
* [Good Practice on Biometrics](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/good-practice-on-biometrics/)
* [Running a Trial Under the Code](https://www.privacy.org.nz/resources-and-learning/a-z-topics/biometrics/running-a-trial-under-the-code/)

**Privacy Commissioner Contact**:
* Phone: 0800 803 909
* Email: enquiries@privacy.org.nz
* Website: https://www.privacy.org.nz/

Remember: The Biometric Processing Privacy Code is **mandatory law**. Non-compliance risks enforcement action, compensation orders, and reputational damage. When in doubt, seek legal advice or contact the Privacy Commissioner's office.

---

### 6.5 Conformance Checklist Summary

Full conformance checklists are provided in [Section 8: Demonstrating Conformance](#section-8). The following table summarizes the 38 AA controls for quick reference:

**Table 5:** Authentication Assurance Controls Summary

| Control | Level 1 | Level 2 | Level 3 | Level 4 | Description |
|---|---|---|---|---|---|
| **Requirements for Authentication** ||||||
| AA1.01 | MUST | MUST | MUST | MUST | Assess authentication risk |
| AA2.01 | MUST | MUST | MUST | MUST | Issue terms and conditions |
| AA2.02 | MUST | MUST | MUST | MUST | Provide ongoing reminders |
| AA2.03 | — | — | MUST | MUST (bio) | Two different factors |
| AA2.04 | — | — | SHOULD | MUST | Limit to 30 failed attempts |
| AA2.05 | MUST | MUST | MUST | MUST | Provide compromise reporting |
| AA3.01 | MUST | MUST | MUST | MUST | Same session binding |
| AA3.02 | MUST | MUST | MUST | MUST | Consistent BA strength |
| AA4.01 | MUST | MUST | MUST | MUST | Verify entity control |
| AA4.02 | — | — | SHOULD | MUST | Check for compromise |
| AA5.01 | MUST | MUST | MUST | MUST | Record registration info |
| AA5.02 | MUST | MUST | MUST | MUST | Update registration status |
| AA5.03 | MUST | MUST | MUST | MUST | Enforce status checks |
| AA5.04 | MUST | MUST | MUST | MUST | Set expiry if needed |
| AA6.01 | MUST | MUST | MUST | MUST | Record establishment details |
| AA6.02 | MUST | MUST | MUST | MUST | Log authentication events |
| **Knowledge Factor Controls** ||||||
| AA7.01 | 4 digits | 12 chars | 4 digits | 12 chars | Minimum complexity |
| AA7.02 | SHOULD | MUST | SHOULD | MUST | Prevent weak passwords |
| AA7.03 | 10/15min | 5/30min | 5/30min | 5/30min | Failed attempt limits |
| AA7.04 | — | — | MUST | MUST (bio) | Add second factor |
| **Possession Factor Controls** ||||||
| AA8.01 | — | — | MUST | MUST (bio) | Add second factor |
| **Possession & Biometric Controls** ||||||
| AA9.01 | MUST | MUST | MUST | MUST | Anti-forgery features |
| AA9.02 | MAY | MUST | MUST | MUST | Dynamic codes |
| AA9.03 | MUST | MUST | MUST | MUST | Code complexity |
| AA9.04 | SHOULD | MUST | MUST | MUST | Spoofing detection |
| AA9.05 | — | — | — | MUST | 90% liveness checking |
| **Biometric Probability Controls** ||||||
| AA10.01 | — | — | MUST | MUST (sys) | <0.01% false positives |
| AA10.02 | — | — | Manual only | MUST | Add second factor |

**Note**: Biometric authentication at any level requires full compliance with the Biometric Processing Privacy Code (Section 6.4).

### Related Resources

* [Section 2: Assessing Identification Risk](#section-2) — Risk assessment methodology
* [Section 3: Levels of Assurance](#section-3) — Understanding assurance levels
* [Section 5: Information Assurance Standard](#section-5) — Information quality requirements
* [Section 7: Binding Assurance Standard](#section-7) — Entity binding requirements
* [Section 8: Demonstrating Conformance](#section-8) — Full conformance checklists
* [Section 9: Reference Materials](#section-9) — Authenticator types and terminology

### Contact

Te Tari Taiwhenua Department of Internal Affairs
Email: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)

Last updated: 20 November 2025


## Section 7: Binding Assurance Standard & Implementation

### 7.1 Introduction and Overview

Binding Assurance ensures that entities are appropriately bound to their entity information to prevent identity theft and account takeover. This standard provides controls for establishing and maintaining the connection between an entity and the information that represents them in a system ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/)).

#### What binding assurance covers

The Binding Assurance Standard addresses:
* **Risk assessment** for understanding binding requirements
* **Entity claims** to specific instances of entity information
* **Verification processes** to confirm entities are the rightful subjects of information
* **Entity uniqueness** requirements in specific contexts
* **Binding integrity** maintenance over time

This standard applies to any Relying Party (RP). The RP is accountable for the controls stated in this standard, even if they have employed or contracted aspects to other parties. Application of the controls in this standard will contribute to the reduction of identity theft, entity information (account) takeover, and therefore the impacts that result ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part1-para1)).

#### When binding occurs

Entity Binding can be undertaken at various times over the life of the Entity Information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part1-subpart2-para3)):

* During initial enrollment when entity information is first collected
* When entity information is orphaned through loss of all authenticators
* When adding new authenticators to existing accounts
* When increasing the assurance level in binding processes
* When entity information is believed to have been compromised

#### The three binding levels

Binding Assurance provides three graduated levels of confidence:

**Table 1:** Binding Assurance Levels

| Level | Description | Binding Requirements |
|---|---|---|
| **LoBA1** | Minimal confidence in the binding | Self-assertion, basic claim to information |
| **LoBA2** | Some confidence in the binding | One binding factor verified |
| **LoBA3** | High confidence in the binding | Two binding factors verified |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart1))

#### Binding factors

The factors for binding are the same types as those used for authentication ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part3-para2)):

* **Knowledge factor** — something the entity knows (shared secrets, personal information)
* **Possession factor** — something the entity has (documents, devices, credentials)
* **Biometric factor** — something the entity is or does (fingerprint, face, voice)

#### How binding relates to other standards

Binding Assurance works with the other identification standards to ensure comprehensive identity management:

**Table 2:** Assurance components

| Assurance component | Description |
|---|---|
| **IA**: Information Assurance | Robustness of the process to establish the quality and accuracy of Entity Information |
| **BA**: Binding Assurance | **Robustness of the process to bind the Entity to Entity Information** |
| **AA**: Authentication Assurance | Robustness of the process to ensure an Authenticator remains solely in control of its holder |
| **FA**: Federation Assurance | Additional steps undertaken to maintain the integrity, security and privacy of a credential used in multiple contexts |

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part2-subpart1))

#### Key principles

During enrollment, the provision of Entity Information by the Entity establishes a minimum level of assurance while the transaction session is maintained. As soon as there is an interruption in the transaction there is the possibility that a returning Entity may not be the same Entity that initiated the enrollment ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part3-para3)).

Binding an Entity to Entity Information establishes that the Entity Information, regardless of its level of assurance, relates to the Entity claiming it. Effective binding ensures the authorized use of Entity Information needed for business operations ([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part1-subpart2-para2)).

---

### 7.2 Standard Objectives and Controls

### BA1 Binding risk is understood

#### Rationale

For entities to trust that their information and the services they are enrolled in are being adequately protected from unauthorised access and use, the binding level should be consistent with the risk posed.

Relying parties may also need to achieve specific levels of assurance to mitigate risks and potentially to comply with legislation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-section1))

#### BA1.01 Control

The RP MUST carry out an assessment of the binding risk posed by any service before offering it.

**Additional information** — While any risk assessment process can be used, specific guidance is available on [assessing identification risk](#section-2) of which binding is a part.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-section2))

#### Implementing BA1 — Guidance

Apply a risk-based approach to identify the aspects of binding that drive the level of risk. Use any robust risk assessment process to identify the binding risk posed ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart1)).

Apply the guidance in [Assessing identification risk](#section-2) to improve your assessment quality. A workbook is available to help undertake an identification risk assessment and provide the optimum level of assurance as an output. For a copy, email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).

Consider these factors in your risk assessment:
* The sensitivity and value of the information or services being protected
* The impact on entities if binding is compromised
* The likelihood of identity theft attempts
* Legal or regulatory requirements for identity verification

> **Example risk scenarios**:
> * **Low risk**: Newsletter subscription — minimal impact if wrong entity bound
> * **Medium risk**: Library membership — moderate impact, some services affected
> * **High risk**: Banking enrollment — significant financial and privacy impact
> * **Very high risk**: Passport issuance — severe impact on national security and individual

### BA2 Entity can claim an instance of Entity Information

#### Rationale

Before binding an Entity to Entity Information, the relevant instance of Entity Information needs to be identified. Entity Information is expected to be specific to a single Entity, therefore only 1 Entity can have a legitimate association or binding with an instance of Entity Information. Failure to ensure Entity Information is specific to a single Entity can result in Entity Information being inadvertently disclosed or it being taken over by another Entity once binding occurs. If there are multiple claims to the same Entity Information, counter fraud investigation might be indicated.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart1-section3))

#### BA2.01 Control

The RP MUST ensure the Entity provides enough information to identify a distinct instance of Entity Information.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart1-section4))

#### BA2.02 Control

The RP MUST be able to identify when an instance of Entity Information has been claimed.

**Additional information** — Orphaned or unclaimed instances of Entity Information are at greater risk of being incorrectly bound to an Entity. A subsequent claim to an association with Entity Information, that has already been recorded as having been bound, should raise concerns.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart1-section5))

#### Implementing BA2 — Guidance

Ensure entities can accurately claim their specific instance of entity information while preventing unauthorized claims ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart2)).

##### Identifying distinct instances (BA2.01)

Collect sufficient information to uniquely identify the correct instance:
* Request additional attributes if initial information yields multiple matches
* Use combinations of attributes that create uniqueness
* Verify the entity recognizes the instance details before proceeding
* Never proceed with binding if uncertainty exists about the correct instance

> **Example of insufficient vs. sufficient identification**:
> * **Insufficient**: Name "John Smith" yields 50 matches
> * **Better**: Add date of birth — reduces to 3 matches
> * **Sufficient**: Add account number or unique reference — identifies single instance

##### Tracking claimed status (BA2.02)

Implement mechanisms to track when entity information has been claimed:
* Record authenticator registration as the primary indicator
* Flag unclaimed or orphaned instances for special handling
* Alert on attempts to claim already-bound information
* Investigate any subsequent claims to bound information

Never assume the first entity to claim orphaned information is the rightful owner. Implement verification processes proportionate to the risk.

> **Types of entity information states**:
> * **Unclaimed**: Information received but no entity has claimed it (e.g., birth registration)
> * **Orphaned**: Previously bound but authenticators lost
> * **Claimed**: Currently bound to an entity with active authenticators
> * **Disputed**: Multiple entities claiming the same information

### BA3 Entity is the subject of Entity Information

#### Rationale

Establishing that an Entity is the subject of either Entity Information they have provided or are claiming (for example, orphaned) is fundamental to preventing impersonation of an Entity for the purposes of gaining a benefit or avoiding an obligation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart2-section6))

#### BA3.01 Control

The RP MUST establish the level of binding assurance (BA) required, for establishing the relationship between the Entity and the information collected.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart2-section7))

#### BA3.02 Control

The RP binds each piece of Entity information at the established level of binding assurance (BA) required, using the following binding factor types:

* knowledge factors that are not publicly known, easily determined or predictable
* possession factors that contain enough features to assess as genuine
* biometric factors with appropriate measures to detect spoofing attempts (for example, recordings, masks, makeup or prosthetics etc.)

**For level 1** — This control does not apply, the Party relies on the ability of the Entity to identify a distinct instance of Entity Information.

**For level 2** — The RP MUST use a minimum of 1 of the binding factor types or an existing Authenticator or Credential of equal or greater assurance level.

**For level 3** — The RP MUST use a minimum of 2 of the binding factor types or an existing Authenticator or Credential of equal or greater assurance level.

**For level 4** — The RP MUST use a biometric factor compliant with controls AA9.04, AA9.05 and AA10.01 with either of the knowledge or possession binding factor types; or an existing Authenticator or Credential of equal assurance level.

**Additional information** — The Authentication Assurance Standard can be used as additional guidance on desirable features for each of the factor types and their levels. An existing registered Authenticator, potentially for another delivery channel, can be used to support binding, as can Credentials.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart2-section8))

#### BA3.03 Control

The RP MUST NOT assign a level of assurance to the binding, where an Authenticator or Credential is used, if the level has not been declared.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart2-section9))

#### BA3.04 Control

The RP MUST limit the number of unsuccessful attempts to bind, disallow further attempts and trigger further investigation.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart2-section10))

#### Implementing BA3 — Guidance

Verify that entities are the rightful subjects of the information they claim through appropriate binding factors ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart3)).

##### Establishing binding level (BA3.01)

Use the identification risk assessment to determine the required binding level. Alternatively, use analytical assessment considering:
* Key business drivers and outcomes
* Risk of financial loss or liability
* Risk to privacy, standing, reputation, or safety
* Harm to agency programs or public interest
* Downstream effects on other parties relying on the binding

> **General binding level examples**:
> * **Level 1**: Self-asserted information, negligible impact if misused
> * **Level 2**: Distinct link needed for some business decisions
> * **Level 3**: Solid binding required, moderate impact from incorrect binding
> * **Level 4**: Critical binding required, severe impact from incorrect binding

##### Implementing binding factors (BA3.02)

Select and implement appropriate binding factors for each level:

**Knowledge factors**:
* Personal information not in public records
* Shared secrets established at enrollment
* Historical transaction details
* Answers to challenge questions

**Possession factors**:
* Government-issued documents with security features
* Financial cards or statements
* Registered devices or tokens
* Physical credentials with anti-forgery features

**Biometric factors** (Level 4 only):
* Implement spoofing detection (AA9.04)
* Use liveness checking for remote capture (AA9.05)
* Achieve false positive rate below 0.01% (AA10.01)

##### Credential level verification (BA3.03)

When using existing authenticators or credentials:
* Verify the declared assurance level
* Request level declaration from credential provider if absent
* Never assume a level without verification
* Document the verified level for audit purposes

##### Failed attempt management (BA3.04)

Implement controls for unsuccessful binding attempts:
* Set maximum attempts (recommend 3-5)
* Lock account after threshold exceeded
* Trigger security investigation
* Require alternative verification process for unlock

### BA4 Entity uniqueness in a context

#### Rationale

Having each instance of Entity Information distinguishable from another in a context and ensuring that each instance is claimed by 1 Entity still allows for 1 Entity to claim multiple instances of Entity Information. In some contexts, there can be an additional need to ensure that an Entity has an association to 1 and only 1 instance of Entity Information. Otherwise known as Entity uniqueness. Examples can include contexts such as passports, justice or certain entitlements.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart3-section11))

#### BA4.01 Control

The RP SHOULD ensure an Entity cannot claim more than 1 instance of Entity Information, where Entity uniqueness is required by the context.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart3-section12))

#### Implementing BA4 — Guidance

Prevent duplicate enrollments where entity uniqueness is required ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart4)).

Implement uniqueness checks when required by:
* Legal requirements (passports, voting registration)
* Entitlement programs (single benefit per person)
* Security contexts (one clearance per individual)
* Financial services (anti-money laundering requirements)

Methods to ensure uniqueness:
* Biometric deduplication (fingerprint, face matching)
* Unique identifier verification (tax number, national ID)
* Cross-reference with authoritative sources
* Data matching across multiple attributes

> **Example uniqueness check**:
> Electoral enrollment system:
> 1. Collect name, date of birth, address
> 2. Check against existing enrollments
> 3. Match with birth register for uniqueness
> 4. Flag any potential duplicates for investigation
> 5. Ensure one person = one enrollment

### BA5 Entity Binding integrity is maintained

#### Rationale

The longer an Authenticator is used to represent the binding between an Entity and Entity Information, especially when challenged remotely, the more likely it can become compromised or the Entity can have lost control of it. In this case the Entity Binding has not being maintained. Changes to the risk profile for the service or transaction, may necessitate increasing the binding which will retest it.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart4-section13))

#### BA5.01 Control

The RP retests Entity Binding at least once every 5 years to ensure it remains consistent with the level of binding assurance (BA) required.

**For levels 1 and 2** — The RP SHOULD undertake this control.

**For levels 3 and 4** — The RP MUST carry out this control unless authentication events involve a biometric factor.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart4-section14))

#### BA5.02 Control

The RP applies counter fraud techniques, where possible.

**For levels 1 and 2** – The control does not apply

**For level 3** – The RP SHOULD apply counter fraud techniques.

**For level 4** – The RP MUST apply counter fraud techniques.

**Additional information** – More information is available in the guide [Counter fraud techniques](#section-2).

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart4-section15))

#### BA5.03 Control

The RP MUST store appropriate detail about the Entity binding process to enable queries or investigation in the future.

([DocRef](https://docref.digital.govt.nz/nz/identification-management/binding-assurance-standard/2024/en/#part4-subpart4-section16))

#### Implementing BA5 — Guidance

Maintain binding integrity over time through periodic verification and fraud prevention ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart5)).

##### Periodic retesting (BA5.01)

Implement binding revalidation processes:
* Schedule automatic reminders for 5-year reviews
* Use risk-based triggers for earlier review if needed
* Retest using current binding level requirements
* Update binding evidence with current documentation

Exemption for biometric authentication:
* If authentication regularly uses biometrics, retesting is not required
* Biometric factor provides ongoing binding verification
* Document biometric usage for compliance evidence

##### Counter fraud techniques (BA5.02)

For Levels 3 and 4, implement fraud detection:
* Behavioral analytics for unusual patterns
* Velocity checks on information changes
* Cross-reference with fraud databases
* Device fingerprinting and location analysis
* Link analysis for related accounts

See [Counter fraud techniques](#section-2) for detailed guidance.

##### Audit trail requirements (BA5.03)

Document all binding processes for investigation:
* Date, time, and method of binding
* Evidence reviewed and verification results
* Factors used and their verification methods
* Any anomalies or exceptions noted
* Identity of staff performing verification (if applicable)

Retain records according to legal requirements and ensure tamper-evident storage.

---

### 7.3 Implementation Guidance Summary

#### Selecting appropriate binding levels

Choose binding levels based on risk assessment:

**Table 3:** Binding Level Selection Guide

| Service Risk | Examples | Recommended Level |
|---|---|---|
| **Minimal** | Public information access, newsletters | LoBA1 |
| **Low** | Library services, community programs | LoBA2 |
| **Moderate** | Financial services, health records | LoBA3 |
| **High** | Passports, security clearances | LoBA4 |

#### Common binding methods by level

**Level 1**: Self-assertion
* Entity claims information without verification
* Relies on ability to identify correct instance
* Suitable for low-value, low-risk services

**Level 2**: Single factor verification
* Knowledge factor (shared secrets, personal information)
* Possession factor (email verification, SMS code)
* Basic document verification

**Level 3**: Two factor verification
* Document + knowledge questions
* Device + personal information
* Credential + additional verification

**Level 4**: Biometric with additional factor
* Biometric capture + document verification
* Face match + knowledge verification
* Includes liveness detection and anti-spoofing

#### Binding lifecycle management

1. **Initial binding**: Verify entity is rightful subject of information
2. **Maintenance**: Monitor for compromise indicators
3. **Revalidation**: Retest every 5 years (unless biometric)
4. **Investigation**: Respond to fraud indicators or disputes
5. **Recovery**: Re-bind after authenticator loss or compromise

---

### 7.4 Special Topics

#### 7.4.1 Derived Information

Derived information includes values that are inferred, estimated, or calculated from other information rather than being directly asserted or verified ([DocRef](https://docref.digital.govt.nz/nz/identification-management/derived-information/2024/en/)).

##### Methods of establishing derived values

**Authoritative values**: Established directly by the authority for that information
* Entity's self-declared preferences
* Official registrations and records
* System-generated identifiers

**Derived values**: Calculated or inferred from authoritative values
* Age calculated from date of birth
* Eligibility determined from multiple attributes
* Risk scores computed from behavioral data

**Estimated values**: Approximations when exact values unavailable
* Age range from appearance
* Income bracket from occupation
* Location from IP address

**Inferred values**: Logical conclusions from available information
* Relationship status from joint accounts
* Preferences from transaction history
* Capability from qualification records

##### Levels of assurance for derived values

Derived values typically have lower assurance than their source:
* Authoritative source at Level 4 → Derived value at Level 3
* Real-time derivation maintains higher assurance
* Point-in-time derivation degrades over time
* Chain of derivation affects final assurance level

##### Privacy-preserving techniques

Use zero-knowledge proofs where appropriate:
* Prove age eligibility without revealing birth date
* Confirm income threshold without exact amount
* Verify location without precise address

> **Example zero-knowledge proof**:
> Proof of age for alcohol purchase:
> * Source: Date of birth (Level 3 verified)
> * Derivation: Calculate age ≥ 18
> * Presentation: Boolean "eligible" without revealing age
> * Privacy: Merchant knows eligibility, not birth date

#### 7.4.2 Using Documents as Evidence

Physical and digital documents serve as common evidence for binding processes, but vary significantly in reliability and security features ([DocRef](https://docref.digital.govt.nz/nz/identification-management/using-documents-as-evidence/2021/en/)).

##### Document quality assessment

**High-quality documents**:
* Government-issued with security features
* Machine-readable zones or chips
* Cryptographic signatures (digital documents)
* Verifiable against issuing authority

**Medium-quality documents**:
* Utility bills or bank statements
* Employment letters on letterhead
* Educational certificates
* Professional licenses

**Low-quality documents**:
* Self-printed documents
* Unverified digital copies
* Documents without security features
* Easily forged items

##### Verification techniques

**Physical documents**:
* Check security features (watermarks, holograms)
* Verify against document databases
* Use UV light for hidden features
* Compare with genuine samples

**Digital documents**:
* Verify digital signatures
* Check certificate chains
* Validate against issuing systems
* Confirm document hasn't been altered

##### Common fraud indicators

Watch for these warning signs:
* Inconsistent fonts or formatting
* Misaligned text or images
* Incorrect or missing security features
* Sequential document numbers across different entities
* Documents that appear too new or too old
* Information that conflicts with other evidence

##### Best practices for document verification

Always sight original documents when possible:
* Originals show security features better than copies
* Easier to detect physical tampering
* Can verify texture and materials
* Reduced risk of digital manipulation

For remote verification:
* Use live video to examine documents
* Request multiple angles and lighting
* Verify against issuing authority databases
* Combine with other binding factors

> **Example document verification process**:
> Driver license verification:
> 1. Check physical security features
> 2. Scan barcode/magnetic stripe
> 3. Verify against transport authority database
> 4. Compare photo with entity (live or video)
> 5. Cross-check details with other evidence
> 6. Document verification results

---

### 7.5 Conformance Checklist Summary

Full conformance checklists are provided in [Section 8: Demonstrating Conformance](#section-8). The following table summarizes the 11 BA controls for quick reference:

**Table 4:** Binding Assurance Controls Summary

| Control | Level 1 | Level 2 | Level 3 | Level 4 | Description |
|---|---|---|---|---|---|
| BA1.01 | MUST | MUST | MUST | MUST | Assess binding risk |
| BA2.01 | MUST | MUST | MUST | MUST | Identify distinct instance |
| BA2.02 | MUST | MUST | MUST | MUST | Track claimed status |
| BA3.01 | MUST | MUST | MUST | MUST | Establish binding level |
| BA3.02 | — | 1 factor | 2 factors | Bio + 1 | Apply binding factors |
| BA3.03 | MUST | MUST | MUST | MUST | Verify credential levels |
| BA3.04 | MUST | MUST | MUST | MUST | Limit failed attempts |
| BA4.01 | SHOULD | SHOULD | SHOULD | SHOULD | Ensure uniqueness if required |
| BA5.01 | SHOULD | SHOULD | MUST | MUST* | Retest every 5 years |
| BA5.02 | — | — | SHOULD | MUST | Apply counter fraud |
| BA5.03 | MUST | MUST | MUST | MUST | Store binding details |

*Unless authentication uses biometric factor

### Related Resources

* [Section 2: Assessing Identification Risk](#section-2) — Risk assessment methodology
* [Section 2: Counter Fraud Techniques](#section-2) — Fraud detection and prevention
* [Section 3: Levels of Assurance](#section-3) — Understanding assurance levels
* [Section 5: Information Assurance Standard](#section-5) — Information quality requirements
* [Section 6: Authentication Assurance Standard](#section-6) — Authenticator requirements
* [Section 8: Demonstrating Conformance](#section-8) — Full conformance checklists
* [Section 9: Authority to Act](#section-9) — Acting on behalf of others

### Contact

Te Tari Taiwhenua Department of Internal Affairs
Email: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)

Last updated: 20 November 2025


## Section 8: Demonstrating Conformance

Conformance with the Identification Standards demonstrates that your identification services meet New Zealand's requirements for secure, privacy-preserving, and interoperable identity management. This section provides comprehensive guidance on preparing for, undertaking, and maintaining conformance with the standards.

### 8.1 Preparing for Conformance Assessment

Before beginning the formal conformance assessment, take time to prepare thoroughly. Effective preparation saves significant time and effort during the assessment itself and increases your likelihood of successful conformance. This section provides practical guidance on the key considerations and actions needed before you start.

#### 8.1.1 Understanding When Conformance Is Needed

Determine whether your organisation needs to demonstrate conformance and understand what triggers this requirement.

##### Mandatory Conformance Contexts

You **must** demonstrate conformance if you are:

* **A DISTF agency** — The Digital Identity Services Trust Framework requires conformance with the Identification Standards for all participating agencies providing identity services
* **Providing identity services under government contract** — Government contracts for identity services typically require conformance as a contractual obligation
* **Handling identity information for government services** — When processing identity data on behalf of government agencies, conformance ensures appropriate security and privacy protections

##### Voluntary Conformance Contexts

You should **strongly consider** conformance if you are:

* **Operating identity services in regulated sectors** — Financial services, health, and telecommunications sectors benefit from demonstrating robust identity practices
* **Seeking to establish trust with partners** — Conformance statements provide independent validation of your identity management capabilities
* **Managing high-risk identity transactions** — When identity failures could cause significant harm, conformance provides assurance of appropriate controls
* **Planning to integrate with government services** — Future integration often requires conformance, so early assessment positions you well

##### Threshold Considerations

Ask yourself these key questions to determine your conformance needs:

1. **What is your risk profile?** — Complete the risk assessment in Section 2 to understand your identification risks
2. **What are your regulatory obligations?** — Check whether legislation or contracts require specific identity standards
3. **Who are your relying parties?** — Understand what assurance your partners and customers need
4. **What is the impact of identity failure?** — Consider financial, privacy, safety, and reputational consequences
5. **Are you planning system changes?** — Assess before major implementations to avoid costly rework

If you answer "yes" to mandatory contexts or identify significant risks through these threshold questions, proceed with conformance preparation.

#### 8.1.2 Assembling Your Conformance Team

Successful conformance requires input from multiple perspectives across your organisation. Assemble a cross-functional team early to ensure comprehensive coverage of all requirements.

##### Core Team Members

Your conformance team should include:

**Technical Lead**
* Understands system architecture and implementation details
* Can explain technical controls and security measures
* Accesses system documentation and configurations
* Coordinates technical evidence gathering

**Information Security Lead**
* Knows current security controls and risk management approaches
* Understands threat landscape and vulnerability management
* Documents security policies and procedures
* Validates security-related controls

**Privacy Officer**
* Understands privacy obligations under the Privacy Act 2020
* Knows data handling and retention practices
* Documents privacy impact assessments
* Ensures privacy-preserving controls

**Business/Service Owner**
* Knows operational context and business requirements
* Understands user needs and service objectives
* Makes decisions about risk acceptance
* Authorises resource allocation

**Legal/Compliance Representative**
* Understands regulatory requirements and obligations
* Interprets legal frameworks and contractual terms
* Advises on compliance implications
* Reviews conformance statements

**Project Manager**
* Coordinates assessment timeline and activities
* Manages evidence collection and documentation
* Tracks progress against milestones
* Facilitates communication between team members

##### Extended Team Members

Depending on your context, you may also need:

* **External Assessor** — Independent conformance assessor for qualified or audited assessments
* **Vendor Representatives** — If using third-party identity services or components
* **Internal Auditor** — For pre-assessment readiness checks
* **Change Manager** — To implement required control improvements
* **Training Coordinator** — To address capability gaps

##### Team Assembly Guidance

**Start with a kick-off workshop** to:
* Explain conformance objectives and benefits
* Review the standards and requirements
* Assign responsibilities and owners
* Establish communication protocols
* Set timeline and milestones

**Maintain engagement through**:
* Regular progress meetings (weekly during active assessment)
* Clear escalation paths for issues
* Documented decisions and actions
* Shared repository for evidence
* Celebration of milestones achieved

#### 8.1.3 Key Topics to Address Before Starting

Work through these critical topics with your team before beginning the formal assessment process.

##### Risk Assessment Completion

**Have you completed the identification risk assessment from Section 2?**

You cannot meaningfully select assurance levels or justify control implementations without understanding your risks. Ensure you have:

* Identified all identification-related threats
* Assessed likelihood and consequence of risks
* Documented risk scenarios and impacts
* Determined your risk tolerance
* Identified required risk treatments

If your risk assessment is incomplete, pause conformance preparation and complete Section 2 first. The risk assessment outputs directly inform your assurance level selection and control implementation decisions.

##### Assurance Level Selection

**Have you selected appropriate assurance levels using Section 3 guidance?**

Your conformance assessment will validate that your implementations meet the claimed assurance levels. Ensure you have:

* Mapped risks to assurance requirements
* Selected levels for Information Assurance (IA)
* Selected levels for Binding Assurance (BA)
* Selected levels for Authentication Assurance (AA)
* Documented your rationale for each selection
* Confirmed levels meet partner expectations

Remember that assurance levels form a three-part expression {IAn, BAn, AAn}. Each component must be justified based on your risk assessment.

##### Control Mapping

**Which controls from the standards apply to your context?**

Not all controls apply to every organisation. Work through Sections 4-7 to identify:

* **Applicable standards** based on your role:
  * Federation Assurance (FA) — If you provide credentials or facilitation services
  * Information Assurance (IA) — If you establish identity information
  * Authentication Assurance (AA) — If you authenticate users
  * Binding Assurance (BA) — If you bind entities to information

* **Mandatory controls** that always apply at your assurance level
* **Conditional controls** that apply based on your implementation choices
* **Non-applicable controls** with documented justification for exclusion

Create a control applicability matrix showing which controls apply and why. This becomes your assessment scope.

##### Evidence Gathering Approach

**How will you demonstrate conformance with each applicable control?**

Plan your evidence strategy before the assessment begins:

* **Existing documentation inventory**:
  * Architecture diagrams and technical specifications
  * Security policies and procedures
  * Privacy impact assessments
  * Risk assessments and treatment plans
  * Operating procedures and user guides
  * Audit reports and penetration tests

* **Documentation gaps to address**:
  * Missing policies or procedures
  * Outdated technical documentation
  * Incomplete risk assessments
  * Absent privacy documentation

* **Evidence organisation approach**:
  * Create evidence repository structure
  * Establish naming conventions
  * Map evidence to specific controls
  * Maintain version control
  * Track evidence currency

* **Evidence retention requirements**:
  * Assessment evidence (3 years minimum)
  * Conformance statements (validity period plus 1 year)
  * Change documentation (until next assessment)

##### System Understanding

**Do you have comprehensive documentation of your identification systems?**

Assessors need to understand how your systems work. Prepare:

* **Architecture documentation**:
  * System architecture diagrams
  * Network topology and segmentation
  * Data flow diagrams
  * Integration architectures
  * Component descriptions

* **Technical specifications**:
  * Authentication mechanisms
  * Cryptographic implementations
  * API specifications
  * Database schemas
  * Security controls

* **Operational documentation**:
  * User journeys and workflows
  * Business process maps
  * Incident response procedures
  * Change management processes
  * Business continuity plans

Update all documentation to reflect current state before assessment begins.

##### Compliance Baseline

**What is your current conformance state?**

Conduct a gap analysis to understand your readiness:

* **Current state assessment**:
  * Review each applicable control
  * Document current implementation
  * Identify full, partial, or non-compliance
  * Estimate effort to achieve compliance

* **Gap analysis approach**:
  * Use conformance checklists from Section 8.3
  * Rate each control (compliant/partial/non-compliant)
  * Document evidence of current state
  * Identify remediation requirements

* **Remediation priorities**:
  * Critical gaps affecting security or privacy
  * High-effort items needing early start
  * Quick wins to build momentum
  * Dependencies between controls

* **Timeline for addressing gaps**:
  * Immediate actions (before assessment)
  * Short-term improvements (during assessment)
  * Long-term enhancements (post-assessment)
  * Accepted risks (with documented rationale)

##### External Dependencies

**How do third parties affect your conformance?**

Identify and document:

* **Third-party services**:
  * Identity verification providers
  * Authentication services
  * Credential providers
  * Cloud infrastructure providers

* **Inherited controls**:
  * Controls implemented by service providers
  * Shared responsibility matrices
  * Service level agreements
  * Compliance attestations

* **Verification requirements**:
  * Vendor conformance statements
  * SOC reports or certifications
  * Contractual obligations
  * Right to audit clauses

Ensure you can demonstrate how third-party controls meet standard requirements.

#### 8.1.4 Internal Readiness Checklist

Use this checklist to confirm your preparation before engaging with the formal assessment process:

##### Preparation Fundamentals

- [ ] **Scope defined and documented** — Clear boundaries of what will be assessed
- [ ] **Conformance team assembled** — All necessary roles filled and engaged
- [ ] **Executive sponsorship secured** — Leadership understands and supports the initiative
- [ ] **Budget approved** — Funding for preparation, assessment, and remediation
- [ ] **Timeline established** — Realistic schedule with contingency

##### Risk and Assurance

- [ ] **Risk assessment completed** — Section 2 risk assessment documented
- [ ] **Assurance levels selected** — Section 3 levels chosen and justified
- [ ] **Control applicability determined** — Clear on which controls apply
- [ ] **Compliance baseline established** — Current state assessed

##### Documentation and Evidence

- [ ] **Technical documentation current** — Architecture, specifications, and configurations updated
- [ ] **Policies and procedures complete** — Security, privacy, and operational documentation ready
- [ ] **Evidence repository prepared** — Structure created and evidence gathering underway
- [ ] **Gaps identified and prioritised** — Remediation plan in place

##### Stakeholder Readiness

- [ ] **Team trained on standards** — Everyone understands requirements
- [ ] **Communication plan activated** — Stakeholders informed of process
- [ ] **Third-party documentation obtained** — Vendor compliance evidence collected
- [ ] **Assessment approach decided** — Self, qualified, or audited assessment chosen

##### Practical Considerations

- [ ] **System access arranged** — Assessors can review implementations
- [ ] **Demonstration environment ready** — Can show system operations
- [ ] **Key personnel availability confirmed** — Team available during assessment
- [ ] **Confidentiality agreements prepared** — NDAs ready if needed

#### 8.1.5 Common Preparation Pitfalls to Avoid

Learn from others' experiences by avoiding these common preparation mistakes:

##### Pitfall 1: Starting Assessment Before Completing Risk Assessment

**Problem**: Without a completed risk assessment, you cannot justify assurance level selections or explain why certain controls are necessary.

**Solution**: Complete the Section 2 risk assessment first. Use the risk outputs to inform your assurance level selection and control implementation priorities. The risk assessment provides the business context that makes your conformance meaningful rather than just a compliance exercise.

##### Pitfall 2: Inadequate Team Representation

**Problem**: Missing critical perspectives leads to incomplete assessment preparation and surprises during the formal assessment.

**Solution**: Ensure cross-functional representation from the start. Include technical, security, privacy, legal, and business perspectives. Each brings essential knowledge about different aspects of your identification services.

##### Pitfall 3: Underestimating Evidence Gathering Effort

**Problem**: Assessment stalls while waiting for documentation that should have been prepared in advance.

**Solution**: Conduct an evidence gap analysis early in preparation. Start gathering and creating documentation immediately. Allow at least 4-6 weeks for evidence preparation, depending on your current documentation state.

##### Pitfall 4: Treating Conformance as a Checkbox Exercise

**Problem**: Focusing on minimal compliance rather than genuine risk management misses the value of conformance and often leads to assessment failure.

**Solution**: Understand that conformance demonstrates effective identity risk management. Focus on implementing controls that genuinely address your identified risks. Use the standards to improve your identification services, not just to pass an assessment.

##### Pitfall 5: Not Planning for Remediation

**Problem**: Discovering gaps during assessment without a plan to address them causes delays and budget overruns.

**Solution**: Build a remediation roadmap during assessment planning. Include time and budget for addressing identified gaps. Plan for both quick fixes and longer-term improvements. Some gaps may be acceptable risks if properly documented.

##### Pitfall 6: Ignoring Operational Context

**Problem**: Assessment doesn't reflect how your services actually operate, leading to impractical or unsustainable control implementations.

**Solution**: Ensure assessors understand your operational constraints and business context. Document legitimate reasons why certain control approaches are used. Show how compensating controls address risks where standard controls aren't practical.

##### Pitfall 7: Inadequate Stakeholder Engagement

**Problem**: Leadership is surprised by findings, resource requirements, or timeline extensions because they weren't properly engaged throughout the process.

**Solution**: Establish regular communication with leadership and key stakeholders. Provide updates on preparation progress, identified gaps, and resource needs. Celebrate milestones to maintain engagement. Ensure leadership understands both the benefits and the commitments of conformance.

##### Pitfall 8: Attempting Everything at Once

**Problem**: Trying to achieve conformance with all standards simultaneously overwhelms the team and dilutes focus.

**Solution**: Consider a phased approach. Start with the most critical standards based on your risk profile. Build capability and momentum with initial successes. Plan subsequent phases to achieve full conformance over time.

### 8.2 Understanding Conformance Assessment

Once you have completed your preparation, you need to understand the conformance assessment process itself. This section explains the types of assessment available, the formal process, and what to expect at each stage.

#### 8.2.1 Why Demonstrate Conformance?

Conformance with the Identification Standards provides multiple benefits to your organisation, your partners, and your users.

##### Value Proposition

**Build Trust and Confidence**
* Independent validation of your identity management practices
* Demonstrated commitment to security and privacy
* Reduced concerns from partners and customers
* Enhanced reputation in the market

**Enable Interoperability**
* Common standards facilitate integration with partners
* Reduced friction in identity federation scenarios
* Simplified procurement and partnering processes
* Future-ready for ecosystem participation

**Ensure Compliance**
* Meet DISTF requirements if applicable
* Satisfy contractual obligations
* Demonstrate regulatory compliance
* Reduce legal and compliance risks

**Improve Operations**
* Structured approach to identity management
* Clear documentation and processes
* Identified and managed risks
* Continuous improvement framework

##### Who Cares About Your Conformance?

Different stakeholders value your conformance for different reasons:

**Government Partners**
* Require conformance for service integration
* Need assurance for information sharing
* Expect consistent identity standards
* Value reduced integration complexity

**Commercial Partners**
* Seek confidence in identity assertions
* Want reduced liability exposure
* Need interoperability assurance
* Appreciate standardised approaches

**Regulators and Auditors**
* Expect appropriate control implementation
* Require evidence of compliance
* Value independent assessment
* Need documented risk management

**Your Users**
* Deserve privacy protection
* Expect secure identity handling
* Want consistent experiences
* Need reliable services

##### Conformance Statement as Market Differentiator

Your conformance statement becomes a powerful tool for:

* **Winning new business** — Demonstrate capability during procurement
* **Accelerating partnerships** — Reduce due diligence requirements
* **Building user confidence** — Show commitment to best practice
* **Accessing opportunities** — Qualify for framework participation

#### 8.2.2 Three Types of Conformance Assessment

The Identification Standards support three types of assessment, each suited to different needs and contexts. Choose the type that aligns with your objectives and obligations.

##### 1. Self-Assessed Conformance

Conduct your own assessment against the standards to understand your compliance level and identify improvement areas.

**When Appropriate**
* No mandatory conformance requirement exists
* You want to understand your current state
* Preparing for formal assessment later
* Limited resources for external assessment
* Internal capability building

**Process and Requirements**
1. **Use the conformance checklists** from Section 8.3 to review each applicable control
2. **Document your assessment** including evidence of control implementation
3. **Identify gaps** and create remediation plans
4. **Implement improvements** based on your findings
5. **Re-assess periodically** to track progress

**Benefits**
* Low cost and resource requirement
* Completed at your own pace
* Builds internal knowledge
* Identifies improvement priorities
* Prepares for formal assessment

**Limitations**
* No independent validation
* No conformance statement issued
* May not satisfy partner requirements
* Potential for bias or blind spots
* Limited external recognition

Self-assessment works well for initial understanding and preparation but does not result in a conformance statement that others can rely upon. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part1-det1-para1))

##### 2. Qualified Assessor Conformance

Engage a qualified assessor to review your implementation and provide an opinion on your conformance readiness.

**When Required**
* Partners request independent validation
* Preparing for audited assessment
* Significant gaps need expert input
* Building stakeholder confidence
* Contractual requirements for review

**Process**
1. **Contact the Identification Team** at identity@dia.govt.nz to arrange assessment
2. **Submit preliminary documentation** for initial review
3. **Participate in assessment activities** including interviews and demonstrations
4. **Receive assessor opinion** on conformance gaps and readiness
5. **Implement recommendations** to achieve full conformance

**Benefits**
* Independent perspective on compliance
* Expert guidance on improvements
* Formal opinion document
* Lower cost than audited assessment
* Good preparation for full audit

**Limitations**
* Opinion only, not conformance statement
* May not satisfy all requirements
* Less rigorous than full audit
* No public register listing
* Shorter validity period

The qualified assessment provides valuable feedback on your conformance readiness and helps identify areas needing attention before pursuing full audited assessment. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part1-det2))

##### 3. Independent Audited Conformance

Undergo a comprehensive audit to achieve a formal Identification Standards Conformance Statement.

**When Required**
* DISTF participation
* Government contracts mandate it
* High-risk identity services
* Market differentiation needed
* Maximum assurance required

**Process**
1. **Complete all preparation** from Section 8.1
2. **Schedule formal assessment** with the Identification Team
3. **Submit comprehensive evidence** for detailed review
4. **Demonstrate system operations** to validate documentation
5. **Address any findings** identified during assessment
6. **Receive conformance statement** upon successful completion

**Benefits**
* Formal conformance statement issued
* Maximum credibility and recognition
* Public register listing (with permission)
* Three-year validity period
* Satisfies all requirements

**Requirements**
* Comprehensive documentation
* Full control implementation
* System demonstration
* Significant resource investment
* Ongoing maintenance commitment

The audited assessment provides the highest level of assurance and results in a formal conformance statement that can be relied upon by all parties. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part1-det3))

#### 8.2.3 The Three-Stage Assessment Process

The formal conformance assessment follows three key stages, whether pursuing qualified or audited assessment. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-para1))

##### Stage 1: Documentation Review

The assessor reviews your documentation to understand your identification services and control implementations.

**What Happens**
* You submit evidence packages organised by control
* The assessor reviews documentation for completeness
* Initial findings identify areas needing clarification
* You provide additional documentation as requested
* The assessor prepares for implementation assessment

**Success Factors**
* Well-organised evidence repository
* Clear mapping of evidence to controls
* Complete and current documentation
* Responsive to clarification requests
* Available subject matter experts

**Typical Duration**: 2-3 weeks depending on documentation quality and completeness

##### Stage 2: Implementation Assessment

The assessor validates that your actual implementation matches your documentation.

**What Happens**
* Schedule demonstration sessions
* Walk through key user journeys
* Show system configurations
* Demonstrate security controls
* Validate operational procedures

**Success Factors**
* Working demonstration environment
* Knowledgeable staff available
* Actual system matches documentation
* Controls operate as described
* Evidence of ongoing operation

**Typical Duration**: 1-2 weeks including demonstrations and follow-up

##### Stage 3: Verification and Statement

The assessor completes their evaluation and issues the assessment outcome.

**What Happens**
* Assessor consolidates findings
* You review preliminary findings
* Opportunity to address issues
* Final assessment decision made
* Opinion or statement issued

**Success Factors**
* Prompt response to findings
* Clear remediation evidence
* Senior decision-maker availability
* Understanding of residual risks
* Commitment to ongoing compliance

**Typical Duration**: 1 week for final assessment and documentation

The complete assessment process typically takes 4-6 weeks from initial documentation submission to final statement issuance, assuming good preparation and no significant findings requiring remediation.

### 8.3 Conformance Requirements by Standard

This section provides comprehensive checklists covering all controls across the four identification standards. Use these checklists to track your conformance evidence and ensure complete coverage of all requirements.

#### How to Use These Checklists

These checklists help you systematically work through all applicable controls:

1. **Determine which standards apply** based on your role (see Section 8.1.3)
2. **Review each control** to understand the requirement
3. **Gather evidence** demonstrating your implementation
4. **Mark conformance status** for tracking progress
5. **Document notes** for assessor context or follow-up items

For each control, consider:
* Does this control apply to my context?
* What evidence demonstrates conformance?
* At what assurance level must I implement this?
* Are there any compensating controls?

#### 8.3.1 Federation Assurance (FA) Checklist

The Federation Assurance Standard applies if you provide credentials or facilitation services on which others rely. This checklist covers all 42 FA controls across 13 objectives.

##### Part 1: Requirements for Credential Providers

##### Objective 1 — Credential risk is understood

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA1.01 | Conduct risk assessment for credential before offering it | Risk assessment documentation, threat analysis, impact assessment | All | ☐ Yes ☐ No ☐ N/A |
| FA1.02 | Evaluate risk of information available to holders and apply appropriate authentication | Risk evaluation documentation, authentication level mapping | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 2 — Credentials have recognised levels of assurance

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA2.01 | Establish credential using IA, BA, AA standards compliance | Evidence of standards implementation, conformance documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA2.02 | Make assurance levels available to holders, RPs, and FPs | Published assurance levels, communication mechanisms | All | ☐ Yes ☐ No ☐ N/A |
| FA2.03 | Provide mechanisms for credential recognition | Credential verification features, anti-counterfeit measures | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| FA2.04 | Provide mechanisms for CP recognition | Provider authentication mechanisms, trust marks | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 3 — Credential is privacy-preserving

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA3.01 | Reduce correlation ability by not including unique entity identifiers | Credential design documentation, privacy impact assessment | All | ☐ Yes ☐ No ☐ N/A |
| FA3.02 | Support information minimisation through partial credential use | Technical implementation, selective disclosure capability | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 4 — Participation is inclusive

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA4.01 | Identify population requiring the credential | Population analysis, accessibility assessment | All | ☐ Yes ☐ No ☐ N/A |
| FA4.02 | Support all entities in identified population | Inclusion measures, alternative pathways documentation | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 5 — Credential is maintained

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA5.01 | Provide means to update credential information | Update procedures, change management processes | All | ☐ Yes ☐ No ☐ N/A |
| FA5.02 | Provide means for holder to cancel credential | Cancellation procedures, user interface documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA5.03 | Provide means to report loss/compromise and receive support | Incident reporting procedures, support documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA5.04 | Provide means to address holder complaints | Complaint procedures, resolution tracking | All | ☐ Yes ☐ No ☐ N/A |
| FA5.05 | Provide means to address holder/RP complaints from presentation | Presentation complaint procedures, issue tracking | All | ☐ Yes ☐ No ☐ N/A |
| FA5.06 | Ability to update credential status to prevent use | Revocation procedures, status management system | All | ☐ Yes ☐ No ☐ N/A |
| FA5.07 | Set credential expiry where appropriate | Expiry policy, risk-based expiry determination | Risk-based | ☐ Yes ☐ No ☐ N/A |
| FA5.08 | Log all system activity | Logging configuration, audit trail documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA5.09 | Take preventative measures for credential integrity | Security controls, tamper prevention measures | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| FA5.10 | Provide compromise detection notifications to holders | Notification system, alert mechanisms | All | ☐ Yes ☐ No ☐ N/A |

##### Part 2: Requirements for Facilitation Providers

##### Objective 6 — Facilitation mechanism risk is understood

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA6.01 | Conduct risk assessment for facilitation mechanism | Risk assessment documentation, threat analysis | All | ☐ Yes ☐ No ☐ N/A |
| FA6.02 | Evaluate risk of information available and apply appropriate authentication | Risk evaluation, authentication level mapping | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 7 — Binding assurance is maintained

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA7.01 | Provide authenticators for facilitation mechanism | Authenticator implementation documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA7.02 | Ensure authenticator has equivalent assurance to connected credentials | Assurance level mapping, equivalence validation | All | ☐ Yes ☐ No ☐ N/A |
| FA7.03 | Ensure entity proves authenticator control before credential connection | Proof of control procedures, verification mechanisms | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 8 — Facilitation mechanism is privacy-preserving

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA8.01 | Ensure holder permission for credential availability | Consent mechanisms, permission documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA8.02 | Enable holder to select which information is added | Selection interface, user control documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA8.03 | Inform holder of correlation or analysis | Transparency notices, analysis disclosures | All | ☐ Yes ☐ No ☐ N/A |
| FA8.04 | Only correlate/analyse with holder permission | Consent management, analysis controls | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 9 — Facilitation mechanism is maintained

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA9.01 | Provide means to add/remove credentials | Credential management interface, procedures | All | ☐ Yes ☐ No ☐ N/A |
| FA9.02 | Provide means to cancel facilitation mechanism | Cancellation procedures, termination processes | All | ☐ Yes ☐ No ☐ N/A |
| FA9.03 | Provide means to report loss/compromise | Incident reporting, support procedures | All | ☐ Yes ☐ No ☐ N/A |
| FA9.04 | Provide means to address complaints | Complaint procedures, resolution processes | All | ☐ Yes ☐ No ☐ N/A |
| FA9.05 | Log all system activity | Audit logging, trail documentation | All | ☐ Yes ☐ No ☐ N/A |
| FA9.06 | Take preventative integrity measures | Security controls, integrity protection | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| FA9.07 | Provide compromise detection notifications | Alert system, notification mechanisms | All | ☐ Yes ☐ No ☐ N/A |

##### Part 3: Requirements for Presentation by Facilitation Providers

##### Objective 10 — Presentations are consistent and recognised

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA10.01 | Make assurance levels available to RP | Assurance level communication, presentation metadata | All | ☐ Yes ☐ No ☐ N/A |
| FA10.02 | Declare lowest assurance level when individual levels unavailable | Level declaration logic, minimum level determination | All | ☐ Yes ☐ No ☐ N/A |
| FA10.03 | Make additional presentation information available | Supplementary information provision, metadata | Context-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 11 — Presentations are privacy-preserving

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA11.01 | Ensure holder permission for information release to RP | Consent mechanisms, release authorisation | All | ☐ Yes ☐ No ☐ N/A |
| FA11.02 | Enable holder to remove information from presentation | Selection controls, data minimisation interface | Where possible | ☐ Yes ☐ No ☐ N/A |
| FA11.03 | Only provide requested information to RP | Data filtering, request validation | All | ☐ Yes ☐ No ☐ N/A |
| FA11.04 | Should not provide information without stated purpose | Purpose collection, validation procedures | All | ☐ Yes ☐ No ☐ N/A |
| FA11.05 | Only release applicable presentation/facilitation information | Information filtering, relevance controls | All | ☐ Yes ☐ No ☐ N/A |
| FA11.06 | Reduce correlation through non-persistent identifiers | Identifier management, privacy engineering | All | ☐ Yes ☐ No ☐ N/A |
| FA11.07 | Preserve anonymity for anonymous presentation requests | Anonymity mechanisms, privacy controls | When requested | ☐ Yes ☐ No ☐ N/A |
| FA11.08 | Prevent unauthorised observation during presentation | Secure channels, encryption implementation | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 12 — Presentation content is unaltered

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA12.01 | Ensure information is not altered during presentation | Integrity controls, tamper detection | All | ☐ Yes ☐ No ☐ N/A |
| FA12.02 | Establish secure channels between parties | Channel security documentation, encryption | Multi-party | ☐ Yes ☐ No ☐ N/A |

##### Objective 13 — Presentation can be investigated

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| FA13.01 | Make contact information available for queries | Published contact details, support channels | All | ☐ Yes ☐ No ☐ N/A |
| FA13.02 | Collect transaction information (ID, timestamp, parties) | Transaction logging, audit trail | Where possible | ☐ Yes ☐ No ☐ N/A |

#### 8.3.2 Information Assurance (IA) Checklist

The Information Assurance Standard applies to establishing the quality and accuracy of identity information. This checklist covers all 14 IA controls across 5 objectives.

##### Objective 1 — Accuracy of entity information

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| IA1.01 | Assess identification risk to determine IA levels | Risk assessment, level determination documentation | All | ☐ Yes ☐ No ☐ N/A |
| IA1.02 | Select IA level appropriate to risk | Level selection rationale, risk mapping | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 2 — Information integrity

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| IA2.01 | Maintain information asset register | Asset inventory, classification documentation | All | ☐ Yes ☐ No ☐ N/A |
| IA2.02 | Implement access controls | Access control matrix, permission documentation | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| IA2.03 | Implement backup and recovery | Backup procedures, recovery testing evidence | All | ☐ Yes ☐ No ☐ N/A |
| IA2.04 | Monitor and respond to security events | Security monitoring, incident response procedures | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 3 — Evidence quality

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| IA3.01 | Verify evidence authenticity | Verification procedures, authenticity checks | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| IA3.02 | Validate evidence against authoritative sources | Validation procedures, source verification | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 4 — Information accuracy

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| IA4.01 | Cross-check information consistency | Consistency checking procedures, validation rules | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| IA4.02 | Verify information currency | Currency checks, update procedures | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 5 — Information maintenance

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| IA5.01 | Provide update mechanisms for entity information | Update procedures, change management | All | ☐ Yes ☐ No ☐ N/A |
| IA5.02 | Implement retention and disposal policies | Retention schedule, disposal procedures | All | ☐ Yes ☐ No ☐ N/A |

#### 8.3.3 Authentication Assurance (AA) Checklist

The Authentication Assurance Standard ensures authenticators remain under the control of authorised holders. This checklist covers all 38 AA controls across 10 objectives.

**Note**: For biometric authentication (particularly at Level 3 or 4), you must also comply with the Privacy Act 2020 Biometric Processing Privacy Code. See Section 6 for integrated requirements.

##### Objective 1 — Authentication risk assessment

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA1.01 | Assess authentication risk to determine AA levels | Risk assessment, threat analysis | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 2 — Authenticator strength

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA2.01 | Implement appropriate authenticator types for level | Authenticator specification, type documentation | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| AA2.02 | Ensure sufficient entropy for knowledge factors | Entropy calculations, complexity requirements | Knowledge factors | ☐ Yes ☐ No ☐ N/A |
| AA2.03 | Implement anti-automation measures | Rate limiting, CAPTCHA, lockout procedures | All | ☐ Yes ☐ No ☐ N/A |
| AA2.04 | Protect authenticator storage | Storage security, encryption documentation | All | ☐ Yes ☐ No ☐ N/A |
| AA2.05 | Implement biometric performance requirements | FAR/FRR specifications, testing results | Biometric only | ☐ Yes ☐ No ☐ N/A |

##### Objective 3 — Authenticator lifecycle

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA3.01 | Secure authenticator issuance/registration | Issuance procedures, registration security | All | ☐ Yes ☐ No ☐ N/A |
| AA3.02 | Verify entity before authenticator issuance | Identity verification procedures, BA compliance | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 4 — Authenticator management

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA4.01 | Provide authenticator update mechanisms | Update procedures, change processes | All | ☐ Yes ☐ No ☐ N/A |
| AA4.02 | Implement authenticator revocation | Revocation procedures, status management | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 5 — Authentication process

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA5.01 | Implement secure authentication protocols | Protocol documentation, security analysis | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| AA5.02 | Protect authentication sessions | Session management, timeout policies | All | ☐ Yes ☐ No ☐ N/A |
| AA5.03 | Implement replay attack prevention | Anti-replay mechanisms, nonce usage | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| AA5.04 | Log authentication events | Audit logging, event tracking | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 6 — Multi-factor authentication

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA6.01 | Implement independent factors | Factor independence analysis, implementation | MFA required | ☐ Yes ☐ No ☐ N/A |
| AA6.02 | Ensure factor diversity | Different factor types, diversity documentation | MFA required | ☐ Yes ☐ No ☐ N/A |

##### Objective 7 — Credential service provider requirements

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA7.01 | Implement secure credential storage | Storage security, encryption methods | CSP only | ☐ Yes ☐ No ☐ N/A |
| AA7.02 | Protect credential transmission | Transmission security, channel encryption | CSP only | ☐ Yes ☐ No ☐ N/A |
| AA7.03 | Implement credential lifecycle management | Lifecycle procedures, management controls | CSP only | ☐ Yes ☐ No ☐ N/A |
| AA7.04 | Provide credential recovery mechanisms | Recovery procedures, verification methods | CSP only | ☐ Yes ☐ No ☐ N/A |

##### Objective 8 — Verifier requirements

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA8.01 | Implement verifier security controls | Verifier protection, security measures | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 9 — Privacy protection

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA9.01 | Minimise authentication data collection | Data minimisation policy, collection limits | All | ☐ Yes ☐ No ☐ N/A |
| AA9.02 | Implement privacy-preserving authentication | Privacy controls, anonymisation where appropriate | All | ☐ Yes ☐ No ☐ N/A |
| AA9.03 | Provide transparency about authentication data use | Privacy notices, data use documentation | All | ☐ Yes ☐ No ☐ N/A |
| AA9.04 | Comply with biometric data protection requirements | Biometric privacy policy, legal compliance | Biometric only | ☐ Yes ☐ No ☐ N/A |
| AA9.05 | Implement biometric template protection | Template security, privacy measures | Biometric only | ☐ Yes ☐ No ☐ N/A |

##### Objective 10 — Usability and accessibility

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| AA10.01 | Provide accessible authentication options | Accessibility features, alternative methods | All | ☐ Yes ☐ No ☐ N/A |
| AA10.02 | Implement user-friendly authentication | Usability testing, user guidance | All | ☐ Yes ☐ No ☐ N/A |

#### 8.3.4 Binding Assurance (BA) Checklist

The Binding Assurance Standard ensures entities are correctly bound to their identity information. This checklist covers all 15 BA controls across 5 objectives.

##### Objective 1 — Binding risk assessment

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| BA1.01 | Assess binding risk to determine BA levels | Risk assessment, threat analysis | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 2 — Evidence of identity

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| BA2.01 | Collect appropriate identity evidence | Evidence requirements, collection procedures | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| BA2.02 | Verify evidence authenticity | Verification procedures, authenticity checks | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| BA2.03 | Validate evidence against authoritative sources | Source validation, verification procedures | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 3 — Binding process

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| BA3.01 | Link entity to evidence | Linking procedures, verification methods | All | ☐ Yes ☐ No ☐ N/A |
| BA3.02 | Verify entity presence (in-person or remote) | Presence verification, liveness detection | Level-dependent | ☐ Yes ☐ No ☐ N/A |
| BA3.03 | Implement binding strength appropriate to level | Binding procedures, strength documentation | Level-dependent | ☐ Yes ☐ No ☐ N/A |

##### Objective 4 — Binding maintenance

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| BA4.01 | Maintain binding over time | Maintenance procedures, periodic verification | All | ☐ Yes ☐ No ☐ N/A |
| BA4.02 | Re-verify binding when required | Re-verification triggers, procedures | Context-dependent | ☐ Yes ☐ No ☐ N/A |
| BA4.03 | Update binding information | Update procedures, change management | All | ☐ Yes ☐ No ☐ N/A |

##### Objective 5 — Binding records

| Control | Description | Evidence Required | LOA | Conformant |
|---------|-------------|-------------------|-----|------------|
| BA5.01 | Record binding events | Event logging, audit trail | All | ☐ Yes ☐ No ☐ N/A |
| BA5.02 | Protect binding records | Record security, access controls | All | ☐ Yes ☐ No ☐ N/A |
| BA5.03 | Retain binding evidence appropriately | Retention policies, disposal procedures | All | ☐ Yes ☐ No ☐ N/A |

#### 8.3.5 Downloadable Conformance Checklists and Templates

The checklists presented in Sections 8.3.1-8.3.4 are also available as standalone markdown files for your convenience. These downloadable versions provide the same comprehensive coverage but in formats you can use as working documents during your conformance journey.

##### Available Checklist Files

**Federation Assurance Checklists** (2 files):

1. **Credential Establishment Checklist** (FA1-FA5)
   * **Coverage**: Objectives 1-5 for Credential Providers
   * **Controls**: FA1.01-FA5.10 (19 controls)
   * **Use for**: Conformance assessment of credential creation and issuance services
   * **Format**: Markdown table with evidence columns

2. **Facilitation Mechanisms Checklist** (FA6-FA13)
   * **Coverage**: Objectives 6-13 for Facilitation Providers
   * **Controls**: FA6.01-FA13.02 (23 controls)
   * **Use for**: Conformance assessment of credential presentation and facilitation services
   * **Format**: Markdown table with evidence columns

**Information & Binding Assurance Checklist** (Combined IA/BA):

3. **Information & Binding Assurance Checklist**
   * **Coverage**: All IA objectives (1-5) and BA objectives (1-5)
   * **Controls**: IA1.01-IA5.02 (14 controls) + BA1.01-BA5.03 (15 controls)
   * **Use for**: Combined assessment of information quality and binding processes
   * **Format**: Markdown table with evidence columns
   * **Rationale**: IA and BA processes often occur together during enrollment, so a combined checklist improves assessment efficiency

**Authentication Assurance Checklist** (Referenced):

4. **Authentication Assurance Checklist** (AA1-AA10)
   * **Coverage**: All 10 objectives for authentication services
   * **Controls**: AA1.01-AA10.06 (29 controls)
   * **Use for**: Conformance assessment of authenticator and authentication processes
   * **Format**: Markdown table with evidence columns

##### How to Use Downloadable Checklists

**1. Download and Customize**
* Copy the relevant checklist file to your working directory
* Add columns for your tracking needs (e.g., "Owner", "Due Date", "Status")
* Customize evidence descriptions to match your context

**2. Map to Your Documentation**
* For each control, identify which existing documents provide evidence
* Add file references or document section numbers to evidence column
* Note where documentation gaps exist

**3. Track Progress**
* Mark conformance status as you complete each control
* Use checklists in team meetings to review progress
* Update regularly as implementation evolves

**4. Prepare for Assessment**
* Organize your evidence to match checklist structure
* Use completed checklists as assessment submission cover sheet
* Provide checklists to assessors to guide their review

##### Evidence Code Reference

The conformance checklists reference standardized evidence codes (AUDIT codes) that assessors use to categorize documentation. Understanding these codes helps you organize evidence efficiently.

**Common Evidence Codes Across All Standards**:

| Code | Evidence Type | Description | Applicable Standards |
|------|---------------|-------------|---------------------|
| **AUDIT1.1** | Identification Risk Assessment | Risk assessment using [Section 2 methodology](#section-2-assessing-your-identification-risk), showing identification risks, likelihood, consequences, and mitigation strategies | FA, IA, BA, AA (all standards) |
| **AUDIT1.2** | ISO 31000 Risk Assessment | Alternative risk assessment following ISO 31000 standard (either AUDIT1.1 OR AUDIT1.2 required, not both) | FA, IA, BA, AA (all standards) |
| **AUDIT1.4** | Privacy Impact Assessment | Privacy assessment demonstrating compliance with Privacy Act 2020 Information Privacy Principles, particularly IPP2 (purpose collection), IPP3/IPP10 (usage limits), IPP11 (disclosure controls), and IPP13 (identifier restrictions) | FA (Objectives 3, 8, 11) |
| **AUDIT3.2** | Conformance Certificate | Evidence of conformance with other required identification standards (e.g., Facilitation Provider needs AA conformance for authenticators, Credential Provider needs IA/BA conformance for information quality) | Cross-standard dependencies |

**Federation Assurance Specific Evidence**:

| Code | Evidence Type | Description | Applicable Controls |
|------|---------------|-------------|---------------------|
| **AUDIT4.1** | Management Documentation | Facilitation Management or Credential Management document describing procedures, processes, capabilities, logging, monitoring, incident response, and business continuity | FA5 (Credential maintenance), FA9 (Facilitation maintenance) |
| **AUDIT4.2** | Security Documentation | Security management documentation covering confidentiality, integrity, availability measures, authenticity controls, tamper protection, network security, and facility security | FA5 (Credential integrity), FA6 (Facilitation mechanism risk), FA9 (Facilitation maintenance) |

**Information Assurance Specific Evidence**:

| Code | Evidence Type | Description | Applicable Controls |
|------|---------------|-------------|---------------------|
| **AUDIT2.1** | Information Asset Register | Comprehensive inventory of all identity information assets with classification, ownership, sensitivity levels, and protection requirements | IA2.01 (Asset management) |
| **AUDIT2.2** | Authority Source Documentation | Documentation of authoritative sources used for information verification (e.g., government registries, credential providers, official databases) with access procedures and validation methods | IA3.02 (Evidence validation), IA4.01-IA4.02 (Information accuracy) |

**Authentication Assurance Specific Evidence**:

| Code | Evidence Type | Description | Applicable Controls |
|------|---------------|-------------|---------------------|
| **AUDIT5.1** | Authenticator Specifications | Technical specifications for each authenticator type including strength calculations, entropy measurements, factor independence analysis, and assurance level mappings | AA2 (Authenticator strength), AA6 (Multi-factor) |
| **AUDIT5.2** | Authentication Protocol Documentation | Detailed documentation of authentication protocols, session management, replay prevention, and cryptographic implementations | AA5 (Authentication process) |

**Binding Assurance Specific Evidence**:

| Code | Evidence Type | Description | Applicable Controls |
|------|---------------|-------------|---------------------|
| **AUDIT6.1** | Binding Process Documentation | Step-by-step procedures for linking entities to evidence, including presence verification methods, liveness detection (if applicable), and binding strength validations | BA3 (Binding process) |
| **AUDIT6.2** | Evidence Verification Procedures | Detailed procedures for collecting, authenticating, and validating identity evidence including document verification, biometric capture, and authoritative source checks | BA2 (Evidence of identity) |

##### Cross-Standard Evidence Dependencies

Some evidence serves multiple standards simultaneously. Understanding these relationships helps you prepare comprehensive evidence packages efficiently:

**Example 1: Risk Assessment Evidence**
* **Single AUDIT1.1 document** can support:
  * FA1.01 (Credential risk)
  * FA6.01 (Facilitation mechanism risk)
  * IA1.01 (Information risk)
  * BA1.01 (Binding risk)
  * AA1.01 (Authentication risk)
* **Requirement**: Risk assessment must address all relevant aspects (information, binding, authentication, federation) for applicable standards

**Example 2: Conformance Certificate Dependencies**
* **Facilitation Provider** (FA6-FA13) needs:
  * AUDIT3.2 (AA conformance certificate) — demonstrates authenticators meet required levels
* **Credential Provider** (FA1-FA5) needs:
  * AUDIT3.2 (IA conformance certificate) — demonstrates information quality controls
  * AUDIT3.2 (BA conformance certificate) — demonstrates binding controls
  * AUDIT3.2 (AA conformance certificate) — demonstrates authenticator controls

**Example 3: Privacy Documentation**
* **Single AUDIT1.4 (Privacy Impact Assessment)** can support:
  * FA3 controls (Credential privacy-preserving)
  * FA8 controls (Facilitation mechanism privacy)
  * FA11 controls (Presentation privacy)
  * AA9 controls (Authentication privacy)
* **Requirement**: Privacy assessment must cover credential, facilitation, presentation, and authentication privacy aspects

##### Evidence Organization Best Practices

**Create Evidence Repository Structure**:
```
/conformance_evidence/
├── /risk_assessments/
│   ├── identification_risk_assessment_2024.pdf (AUDIT1.1)
│   └── privacy_impact_assessment_2024.pdf (AUDIT1.4)
├── /policies_procedures/
│   ├── information_security_policy.pdf
│   ├── privacy_policy.pdf
│   └── incident_response_procedures.pdf
├── /technical_specifications/
│   ├── system_architecture_diagrams.pdf
│   ├── authentication_mechanisms_spec.pdf (AUDIT5.2)
│   └── cryptographic_implementation.pdf
├── /operational_evidence/
│   ├── audit_logs_sample.pdf
│   ├── training_records.pdf
│   └── incident_reports_2024.pdf
├── /management_documentation/
│   ├── credential_management_document.pdf (AUDIT4.1)
│   └── security_management_document.pdf (AUDIT4.2)
├── /conformance_certificates/
│   └── aa_conformance_statement_2024.pdf (AUDIT3.2)
└── /checklists_completed/
    ├── fa_credential_checklist_completed.md
    ├── fa_facilitation_checklist_completed.md
    └── ia_ba_checklist_completed.md
```

**Evidence Mapping Matrix**:

Create a master mapping document showing which evidence files support which controls:

| Control | Evidence Code | Evidence Files | Location | Last Updated |
|---------|---------------|----------------|----------|--------------|
| FA1.01 | AUDIT1.1 | identification_risk_assessment_2024.pdf | /risk_assessments/ | 2024-06-15 |
| FA1.01 | AUDIT4.1 | credential_management_document.pdf | /management_documentation/ | 2024-08-01 |
| FA6.02 | AUDIT3.2 | aa_conformance_statement_2024.pdf | /conformance_certificates/ | 2024-09-10 |
| IA2.01 | AUDIT2.1 | information_asset_register.xlsx | /operational_evidence/ | 2024-11-01 |

This mapping helps assessors quickly locate evidence and helps you identify documentation gaps.

##### Additional Conformance Resources

**Related Guidance Documents**:

While the checklists cover control requirements, these guidance documents provide detailed implementation advice:

* **[Assessing identification risk](#section-2-assessing-your-identification-risk)** (Section 2) — Detailed risk assessment methodology supporting AUDIT1.1
* **Implementation guidance** for each standard (Sections 4-7) — Control-by-control guidance with examples
* **Conformance process guide** ([Section 1](#section-1-understanding-conformance-with-identification-standards)) — Overview of conformance types, stages, and procedures
* **Using documents as evidence** (referenced in IA4 guidance) — Specialized guidance on document verification
* **Counter fraud techniques** (referenced in IA5.01 guidance) — Techniques for detecting fabricated information and fraudulent credentials

**Templates for Level Documentation**:

Documenting your selected Levels of Assurance requires structured templates:

* **Levels of Assurance Table (IA/BA)** — Template for documenting {IAn, BAn} expressions with risk justification
* **Authentication Factor Level Table** — Template for documenting AAn levels for each authenticator with strength calculations

These templates help you present Level of Assurance decisions in the format assessors expect.

**Contact for Conformance Support**:

For questions about checklists, evidence requirements, or conformance process:

* **Email**: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)
* **Identification Team** — Te Tari Taiwhenua (Department of Internal Affairs)
* **Support includes**:
  * Checklist interpretation guidance
  * Evidence requirement clarification
  * Assessment scheduling
  * Remediation advice

The Identification Team can provide examples of acceptable evidence, clarify ambiguous requirements, and help you structure your evidence packages for efficient assessment.

### 8.4 Evidence Documentation

Demonstrating conformance requires comprehensive evidence that your controls are implemented and operating effectively. This section explains what evidence you need and how to organise it for assessment.

#### What Evidence Do You Need?

Evidence demonstrates that you meet each applicable control requirement. Different types of evidence serve different purposes in the assessment process.

##### Policy and Procedure Documentation

**What to provide**:
* Information security policies
* Privacy and data protection policies
* Identity management procedures
* Incident response procedures
* Access control policies
* Change management procedures
* Business continuity plans

**What assessors look for**:
* Policies are current and approved
* Procedures are detailed and actionable
* Clear roles and responsibilities
* Regular review and update cycles
* Alignment with standard requirements

##### Technical Specifications

**What to provide**:
* System architecture diagrams
* Network topology documentation
* Authentication mechanism specifications
* Cryptographic implementation details
* API documentation
* Database schemas
* Security control configurations

**What assessors look for**:
* Technical controls match policy requirements
* Security measures are properly configured
* Cryptography meets standard requirements
* Architecture supports claimed assurance levels

##### Operational Evidence

**What to provide**:
* Audit logs and monitoring reports
* Incident response records
* Change management records
* Training records and materials
* Service level agreements
* Vendor management documentation
* User guides and training materials

**What assessors look for**:
* Controls operate as documented
* Regular monitoring and review occurs
* Incidents are properly managed
* Staff are trained and competent
* Third parties meet requirements

##### Testing and Validation Results

**What to provide**:
* Penetration testing reports
* Vulnerability assessments
* Security audit reports
* Compliance assessments
* Performance testing results
* Disaster recovery test results
* User acceptance testing

**What assessors look for**:
* Regular testing occurs
* Findings are addressed
* Tests validate control effectiveness
* Results support assurance claims

#### Evidence Organisation Strategies

Organise your evidence to facilitate efficient assessment and demonstrate comprehensive coverage.

##### Control-Based Organisation

Create an evidence repository structured by standard and control:

```
Evidence Repository/
├── Federation_Assurance/
│   ├── FA1.01_Risk_Assessment/
│   │   ├── Risk_Assessment_Document.pdf
│   │   ├── Threat_Analysis.xlsx
│   │   └── Impact_Assessment.docx
│   ├── FA1.02_Authentication_Evaluation/
│   │   └── Authentication_Level_Mapping.pdf
│   └── ...
├── Information_Assurance/
│   ├── IA1.01_Risk_Assessment/
│   └── ...
├── Authentication_Assurance/
│   └── ...
└── Binding_Assurance/
    └── ...
```

##### Document Type Organisation

Alternatively, organise by document type with clear control mapping:

```
Evidence Repository/
├── Policies/
│   ├── Information_Security_Policy.pdf
│   ├── Privacy_Policy.pdf
│   └── Control_Mapping.xlsx
├── Procedures/
│   ├── Identity_Verification_Procedures.pdf
│   └── Incident_Response_Procedures.pdf
├── Technical_Documentation/
│   ├── Architecture_Diagrams/
│   └── Security_Configurations/
└── Audit_Evidence/
    ├── Penetration_Tests/
    └── Audit_Reports/
```

#### Traceability: Linking Evidence to Controls

Maintain clear traceability between your evidence and the controls they support.

##### Evidence Mapping Matrix

Create a matrix showing which evidence supports which controls:

| Control | Evidence Document | Section/Page | Status |
|---------|------------------|--------------|---------|
| FA1.01 | Risk_Assessment_2024.pdf | Section 3, pp. 12-18 | Current |
| FA1.01 | Threat_Model_2024.xlsx | All tabs | Current |
| FA1.02 | Auth_Level_Policy.pdf | Section 2, pp. 5-7 | Current |
| FA2.01 | IA_Conformance_Statement.pdf | Full document | Current |
| FA2.01 | BA_Conformance_Statement.pdf | Full document | Current |
| FA2.01 | AA_Conformance_Statement.pdf | Full document | Current |

##### Cross-Reference Documentation

Within your evidence documents, add references to the controls they address:

* Use headers or footers indicating relevant controls
* Add control references in document margins
* Include executive summaries mapping content to controls
* Create control coverage appendices

#### Common Evidence Gaps and How to Address Them

Identify and remediate these common evidence gaps before assessment:

##### Gap: Missing or Outdated Policies

**Problem**: Policies don't exist or haven't been updated in years

**Solution**:
* Conduct policy gap analysis against standards
* Develop missing policies using standard templates
* Review and update existing policies
* Obtain management approval for all policies
* Implement regular review cycles

##### Gap: Undocumented Procedures

**Problem**: Operations rely on tribal knowledge rather than documented procedures

**Solution**:
* Interview staff to document current practices
* Create standard operating procedures
* Develop quick reference guides
* Implement procedure management system
* Train staff on documented procedures

##### Gap: No Testing Evidence

**Problem**: Security testing is ad-hoc or undocumented

**Solution**:
* Establish regular testing schedule
* Document test plans and procedures
* Retain test results and reports
* Track remediation of findings
* Implement continuous monitoring where possible

##### Gap: Incomplete Audit Trails

**Problem**: Logging is inconsistent or logs aren't retained

**Solution**:
* Review logging requirements for each control
* Configure comprehensive logging
* Implement log aggregation and retention
* Establish log review procedures
* Document log management policies

##### Gap: Third-Party Assurance

**Problem**: Cannot demonstrate vendor compliance

**Solution**:
* Request vendor conformance statements
* Obtain SOC reports or certifications
* Document shared responsibility matrices
* Implement vendor assessment procedures
* Include compliance requirements in contracts

#### Evidence Retention Requirements

Maintain evidence appropriately to support ongoing conformance and re-assessment.

##### Retention Periods

**Assessment Evidence**: Retain for the validity period of your conformance statement plus one year

**Audit Logs**: Retain according to your policy, but minimum 12 months for conformance purposes

**Incident Records**: Retain for 3 years or as required by law

**Change Records**: Retain until superseded plus one re-assessment cycle

**Test Results**: Retain current results plus previous set for comparison

##### Evidence Currency

Keep evidence current through:

* Regular reviews and updates
* Version control with clear dating
* Archiving superseded documents
* Tracking review cycles
* Documenting changes

### 8.5 The Assessment Process in Practice

Understanding what happens during the assessment helps you prepare effectively and respond appropriately. This section walks through the practical aspects of the assessment process.

#### Pre-Assessment Preparation

The success of your assessment largely depends on thorough preparation in the weeks leading up to the formal assessment.

##### Two Weeks Before Assessment

**Finalise evidence packages**:
* Complete evidence gathering
* Organise documentation by control
* Create evidence index
* Review for completeness
* Address any gaps identified

**Prepare your team**:
* Confirm participant availability
* Brief team on assessment process
* Review roles and responsibilities
* Prepare for interviews
* Arrange system access

**Set up demonstration environment**:
* Prepare test accounts
* Configure demonstration scenarios
* Test all demonstrations
* Prepare backup options
* Document any limitations

##### One Week Before Assessment

**Conduct internal readiness review**:
* Walk through evidence packages
* Test demonstration scenarios
* Brief executive stakeholders
* Address last-minute issues
* Confirm logistics

**Submit preliminary documentation**:
* Provide evidence packages to assessor
* Include evidence index and mapping
* Highlight any known issues
* Identify key contacts
* Confirm assessment schedule

#### Scheduling and Coordination

Work with the Identification Team to schedule your assessment at a time that works for all parties.

##### Scheduling Considerations

**Timing factors**:
* Avoid peak business periods
* Allow time for preparation
* Consider team availability
* Plan for remediation time
* Account for decision timelines

**Duration planning**:
* Self-assessment: 1-2 weeks at your pace
* Qualified assessment: 2-3 weeks total
* Audited assessment: 4-6 weeks total
* Factor in remediation time
* Plan for follow-up activities

Contact the Identification Team at [identity@dia.govt.nz](mailto:identity@dia.govt.nz/) to begin scheduling your assessment. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart3-section7))

#### Assessor Review Process

The assessor follows a structured process to evaluate your conformance with the standards.

##### Document Review Phase

**What happens**:
* Assessor reviews submitted evidence
* Initial completeness check
* Detailed control mapping
* Identification of gaps or questions
* Preparation for demonstrations

**Your role**:
* Respond to clarification requests
* Provide additional documentation
* Explain context and rationale
* Address identified gaps
* Prepare for next phase

##### Implementation Review Phase

**What happens**:
* System demonstrations
* Configuration reviews
* Process walkthroughs
* Staff interviews
* Operational verification

**Your role**:
* Demonstrate system operations
* Walk through key processes
* Answer technical questions
* Provide system access
* Explain implementation choices

#### Evidence Presentation

Present your evidence effectively to facilitate assessor understanding and demonstrate comprehensive compliance.

##### Demonstration Best Practices

**Prepare structured demonstrations**:
* Create demonstration scripts
* Use realistic scenarios
* Show end-to-end processes
* Include error handling
* Demonstrate security controls

**Be ready to show**:
* User registration and authentication
* Administrative functions
* Security controls in action
* Audit trail generation
* Incident response procedures

##### Interview Preparation

**Prepare your team for interviews**:
* Review likely questions
* Understand control requirements
* Know your implementation
* Be honest about limitations
* Provide context and rationale

**Common interview topics**:
* Risk assessment methodology
* Control implementation decisions
* Incident response procedures
* Change management processes
* Continuous improvement approach

#### Questions and Clarifications

The assessment process involves ongoing dialogue between you and the assessor.

##### Responding to Assessor Queries

**When assessors ask for clarification**:
* Respond promptly and completely
* Provide specific examples
* Reference documentation
* Explain your reasoning
* Acknowledge any gaps

**If you don't have requested evidence**:
* Explain why it doesn't exist
* Describe compensating controls
* Propose remediation approach
* Provide timeline for creation
* Document as a finding

##### Managing Findings

**When assessors identify issues**:
* Acknowledge the finding
* Understand the requirement
* Assess the impact
* Propose remediation
* Agree on timeline

**Types of findings**:
* **Critical**: Must be addressed for conformance
* **Major**: Should be addressed before statement issuance
* **Minor**: Should be addressed but won't prevent conformance
* **Observations**: Opportunities for improvement

#### Follow-up and Remediation

After the initial assessment, you may need to address findings before conformance can be confirmed.

##### Remediation Planning

**Develop remediation plan**:
* Prioritise critical findings
* Assign responsible parties
* Set realistic timelines
* Identify required resources
* Track progress

**Quick wins vs long-term fixes**:
* Implement quick fixes immediately
* Plan major changes carefully
* Document interim controls
* Communicate progress
* Verify effectiveness

##### Evidence of Remediation

**Demonstrate fixes**:
* Provide updated documentation
* Show configuration changes
* Demonstrate new processes
* Submit test results
* Confirm implementation

#### Final Conformance Determination

The assessment concludes with a formal determination of your conformance status.

##### Assessment Outcomes

**For self-assessment**:
* Internal report of findings
* Gap analysis results
* Remediation roadmap
* Readiness evaluation

**For qualified assessment**:
* Written opinion on conformance readiness
* Detailed findings report
* Recommendations for improvement
* Indicative assurance levels
([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart3-section8))

**For audited assessment**:
* Formal conformance statement (if successful)
* Detailed assessment report
* Specified assurance levels
* Validity period (up to 3 years)
* Publication eligibility
([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart3-section8-det2))

### 8.6 Maintaining Conformance

Conformance is not a one-time achievement but an ongoing commitment. This section explains how to maintain your conformance over time and when re-assessment is required.

#### Conformance Statement Validity

Your conformance statement is issued for a specific period and under specific conditions. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-para1))

##### Maximum Validity Period

**Three-year maximum**: Conformance statements are valid for a maximum of three years from the date of issuance. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-det4-para1))

**Why three years?**
* Technology and threats evolve
* Standards may be updated
* Organisational changes occur
* Controls may degrade over time
* Regular validation ensures continued effectiveness

**Planning for renewal**:
* Set reminders 6 months before expiry
* Begin preparation 3 months before
* Schedule assessment 2 months before
* Allow time for any remediation
* Ensure continuous coverage

The Identification Team will contact you when your statement is approaching expiry to arrange re-conformance assessment.

#### Triggers for Re-Assessment

Several events may require re-assessment before your statement's normal expiry date.

##### Significant System Changes

Re-assess when you make substantial changes to your identification services. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-det5-para1))

**Changes requiring re-assessment**:
* Major architecture redesigns
* New authentication methods
* Additional identity services
* Significant security control changes
* Integration with new systems
* Changes affecting assurance levels

**Changes NOT requiring immediate re-assessment**:
* Minor bug fixes
* Cosmetic user interface updates
* Performance optimisations
* Documentation updates
* Staff changes (unless key roles)

**Managing changes**:
* Document all significant changes
* Assess impact on conformance
* Consult Identification Team if uncertain
* Plan re-assessment if needed
* Maintain change log for next assessment

##### New Functionality

When adding new features or capabilities to your identification services:

**Assess the impact**:
* Does it affect existing controls?
* Does it introduce new risks?
* Does it change assurance levels?
* Does it alter user flows?
* Does it impact privacy?

**If impact is significant**:
* Document the new functionality
* Update risk assessments
* Review control applicability
* Schedule focused re-assessment
* Update conformance statement

##### Security Incidents

Major security incidents may trigger re-assessment requirements:

**Incident types of concern**:
* Unauthorised access to identity data
* Compromise of authentication systems
* Breaches affecting multiple users
* Systemic control failures
* Regulatory compliance breaches

**Post-incident process**:
* Conduct incident investigation
* Identify root causes
* Implement remediation
* Document lessons learned
* Undergo re-assessment if required

##### Standards Updates

The Identification Standards evolve to address new threats and technologies. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-det6-para1))

**When standards change**:
* Review changes against your implementation
* Assess impact on conformance
* Plan necessary updates
* Implement changes within grace period
* Schedule re-assessment if required

**Staying informed**:
* Subscribe to standards updates
* Participate in consultation processes
* Attend standards workshops
* Maintain contact with Identification Team
* Plan proactively for changes

#### Regular Re-Assessment Process

When re-assessment is required, the process is similar to initial assessment but may be streamlined based on what has changed.

##### Re-Assessment at Expiry

When your three-year statement expires:

**If no changes since original assessment**:
* Lighter documentation review
* Focused demonstrations
* Confirmation of continued compliance
* Updated statement issued
* Minimal time investment

**If changes have occurred**:
* Full or partial re-assessment
* Focus on changed areas
* Verify continued compliance
* Update documentation
* New statement issued

##### Triggered Re-Assessment

For re-assessment triggered by changes or incidents:

**Focused assessment**:
* Assess only affected areas
* Review change documentation
* Verify control effectiveness
* Update risk assessments
* Amend conformance statement

**Timeline considerations**:
* Notify Identification Team promptly
* Agree assessment scope
* Schedule assessment quickly
* Implement findings rapidly
* Minimise conformance gaps

#### Continuous Improvement

Maintain and improve your conformance between assessments through ongoing activities.

##### Regular Internal Reviews

**Conduct quarterly reviews**:
* Check control effectiveness
* Review recent changes
* Update documentation
* Address minor issues
* Plan improvements

**Annual comprehensive review**:
* Full internal assessment
* Update risk assessments
* Review all documentation
* Test incident response
* Plan major improvements

##### Evidence Currency

**Keep evidence current**:
* Update policies and procedures
* Refresh technical documentation
* Maintain test results
* Document changes
* Archive old versions

**Regular testing**:
* Quarterly vulnerability assessments
* Annual penetration testing
* Periodic disaster recovery tests
* Regular audit reviews
* Continuous monitoring

##### Monitoring and Metrics

**Track conformance health**:
* Control effectiveness metrics
* Incident trends
* Change frequency
* Documentation currency
* Training completion

**Key performance indicators**:
* Authentication success rates
* Security incident frequency
* Documentation update cycles
* Audit finding closure rates
* User satisfaction scores

#### Complaint Process

If stakeholders raise concerns about your conformance, a formal complaint process exists.

##### Complaint Investigation

If the Identification Team receives a complaint: ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-det7-para1))

**Investigation process**:
* Complaint received and acknowledged
* Initial assessment of validity
* Formal investigation if warranted
* Findings documented
* Remediation requirements identified

**Your involvement**:
* Cooperate with investigation
* Provide requested information
* Implement required changes
* Demonstrate remediation
* Maintain communication

**Potential outcomes**:
* No action required
* Minor remediation needed
* Re-assessment required
* Statement suspended pending fixes
* Statement revoked (severe cases)

### 8.7 Conformance Statement and Publication

Upon successful assessment, you receive formal recognition of your conformance. This section explains the conformance statement and how to leverage it.

#### What the Conformance Statement Includes

Your conformance statement is a formal document that validates your implementation of the Identification Standards. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart3-section8-det2))

##### Statement Contents

**Organisation details**:
* Legal entity name
* Trading names if different
* Organisation identifier
* Contact information
* Authorised representative

**Service description**:
* Identification services assessed
* Service boundaries and scope
* User populations served
* Use cases supported
* Exclusions or limitations

**Standards conformance**:
* Standards conformed with (FA, IA, AA, BA)
* Version of standards assessed against
* Controls implemented
* Any exemptions or compensating controls
* Special conditions

**Assurance levels**:
* Level of Information Assurance (IA Low/Medium/High)
* Level of Binding Assurance (BA Low/Medium/High)
* Level of Authentication Assurance (AA Low/Medium/High)
* Level expression {IAn, BAn, AAn}
* Scope of levels (which services/functions)

**Validity details**:
* Issue date
* Expiry date (maximum 3 years)
* Assessment type (qualified or audited)
* Assessor details
* Statement identifier

#### How to Publish Your Conformance

With your permission, your conformance can be made public to build trust and enable verification.

##### Public Register

**Benefits of public listing**:
* Searchable by partners and customers
* Independent verification available
* Demonstrates transparency
* Builds market confidence
* Simplifies due diligence

**What is published**:
* Organisation name
* Services covered
* Standards conformed with
* Assurance levels achieved
* Validity period

**What is NOT published**:
* Detailed assessment reports
* Technical implementation details
* Security configurations
* Contact details (unless requested)
* Commercial information

##### Using Your Conformance Statement

**In procurement processes**:
* Include statement in tender responses
* Reference public register listing
* Highlight assurance levels achieved
* Demonstrate ongoing compliance
* Differentiate from competitors

**For partner integration**:
* Share statement during onboarding
* Provide assurance level details
* Clarify scope of conformance
* Establish trust quickly
* Reduce assessment burden

**In marketing materials**:
* Reference conformance achievement
* Use appropriate trust marks
* Link to public register
* Highlight security commitment
* Build customer confidence

#### Updating Conformance Statements

Conformance statements may need updating during their validity period.

##### Administrative Updates

**When details change**:
* Organisation name changes
* Contact information updates
* Service name changes
* Minor scope clarifications
* Representative changes

**Update process**:
* Notify Identification Team
* Provide supporting documentation
* Receive updated statement
* Update public register
* Inform stakeholders

##### Scope Changes

**When scope expands**:
* New services added
* Additional standards adopted
* Higher assurance levels achieved
* Broader user population
* Extended use cases

**Assessment requirements**:
* Assess new scope elements
* Verify continued conformance
* Update documentation
* Receive amended statement
* Communicate changes

**When scope reduces**:
* Services discontinued
* Standards no longer applicable
* Reduced assurance levels
* Narrower scope
* Excluded functionality

#### Communicating Conformance to Stakeholders

Effectively communicate your conformance achievement to maximise its value.

##### Internal Communication

**Inform your organisation**:
* Announce achievement to staff
* Explain what it means
* Highlight team contributions
* Share improvement benefits
* Celebrate success

**Update stakeholders**:
* Brief executive leadership
* Inform board if appropriate
* Update risk committees
* Notify internal audit
* Advise legal and compliance

##### External Communication

**Inform partners and customers**:
* Send conformance notifications
* Update service documentation
* Revise contracts if needed
* Modify SLAs to reflect
* Update integration guides

**Market communication**:
* Press release if significant
* Website updates
* Social media announcements
* Industry forum participation
* Case study development

##### Maintaining Trust

**Ongoing communication**:
* Regular status updates
* Proactive incident notification
* Transparent change communication
* Continuous improvement updates
* Renewal notifications

**If conformance lapses**:
* Immediate stakeholder notification
* Clear remediation plan
* Timeline for renewal
* Interim risk management
* Regular progress updates

---

### Summary

Demonstrating conformance with the Identification Standards is both an achievement and an ongoing commitment. This section has provided comprehensive guidance on:

**Preparing for conformance** — Understanding when you need conformance, assembling your team, addressing key topics before starting, and avoiding common pitfalls

**Understanding assessment** — Why conformance matters, the three types of assessment available, and the three-stage assessment process

**Meeting requirements** — Comprehensive checklists covering all 109 controls across the four identification standards (42 FA + 14 IA + 38 AA + 15 BA controls)

**Documenting evidence** — What evidence you need, how to organise it, maintaining traceability, and addressing common gaps

**The assessment experience** — What happens during assessment, how to present evidence, managing findings, and achieving conformance

**Maintaining conformance** — Understanding validity periods, triggers for re-assessment, continuous improvement, and complaint processes

**Leveraging your achievement** — Understanding your conformance statement, publication options, and effective stakeholder communication

Remember that conformance is not just about meeting requirements — it's about demonstrating your commitment to secure, privacy-preserving, and interoperable identity management. Use these standards to genuinely improve your identification services and build trust with your stakeholders.

For assistance with conformance assessment, contact the Identification Team at [identity@dia.govt.nz](mailto:identity@dia.govt.nz/).



## Section 9: Reference Materials

### 9.1 Identification Terminology

#### Understanding Our Terminology

The terms used in these standards have undergone a process to simplify and remove ambiguity often associated with identification management ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#para1)). Where possible, we use dictionary meanings. If these prove insufficient, we adopt stable terms from international sources. Only when neither option suits do we create bespoke definitions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#para2)).

Dictionary definitions come from the [Collins Dictionary](https://www.collinsdictionary.com/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#para5)). External standards referenced include ISO 31073:2022 for risk management terms, ITU-T X.1252 for context definitions, and NIST SP 800-63-3 Digital Identity Guidelines for authenticator concepts.

#### Agreed Terms

These terms have been agreed through practice and consultation on specific topics ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para1)).

##### A

**account**
An instance of entity information in a context ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr1-td2)).
*Source: New definition*
*Note: A common term for the set of entity information relating to one entity to which an authenticator can be registered and from which credential subject information can be taken to establish a credential.*
*Used in: Sections 4-7 (Standards)*

**accountable**
Responsible for some action; answerable ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr2)).
*Source: Expanded Dictionary meaning*
*Note: For roles such as Credential Provider and Relying Party, it is the primary publicly accessible party.*
*Used in: Section 4 (Federation), Section 8 (Conformance)*

**affected party**
A party that could be influenced; acted upon ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr3)).
*Source: Expanded Dictionary meaning*
*Note: For identification risk, affected parties include:*
* *Entitled individual — for example, an entitled individual applies for a service and is deemed ineligible because their identity has been used previously by someone else*
* *Service provider — for example, an organization's reputation suffers from fraud publicity*
* *Wider community — for example, false identification documents enable fraud against other organizations*
*Used in: Section 2 (Risk Assessment)*

**agent**
A person, firm, etc. empowered to act for another ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr4)).
*Source: Dictionary*
*Used in: Section 7 (Binding)*

**anonymous**
Not easily distinguished from others or from one another because of a lack of individual features or character ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr5)).
*Source: Dictionary*
*Used in: Section 6 (Authentication)*

**assurance**
A statement, assertion, etc. intended to inspire confidence or give encouragement ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr6)).
*Source: Dictionary*
*Used throughout all sections*

**attribute**
A characteristic or quality of a person or thing ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr7)).
*Source: Dictionary*
*Used in: Section 5 (Information Assurance)*

**authentication**
Process for establishing an authenticator is genuine or as represented ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr8)).
*Source: Expanded Dictionary meaning*
*Used in: Section 6 (Authentication Assurance)*

**authenticator**
Things known and/or possessed and controlled by an entity that are used to be recognized when they return to an organization ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr9)).
*Source: Based on [NIST SP 800-63-3](https://pages.nist.gov/800-63-3/) Digital Identity Guidelines*
*Used in: Sections 3, 6 (Assurance Levels, Authentication)*

**authenticator holder**
The entity to which an authenticator was initially bound; the rightful holder ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr10-td2)).
*Source: New definition*
*Used in: Section 6 (Authentication)*

**authoritative**
Possessing or supported by authority; official ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr11-td2)).
*Source: Dictionary*
*Note: Indigenous peoples, society and industry communities can nominate a party as authoritative. Such parties may be subject to legal controls.*
*Used in: Section 5 (Information Assurance)*

##### B

**binding**
The action of a person or thing that binds ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr12-td2)).
*Source: Dictionary*
*Used in: Section 7 (Binding Assurance)*

##### C

**challenge**
To order a person to halt and be identified or to give a password ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr13-td2)).
*Source: Dictionary*
*Note: A 'challenger' issues a challenge and a 'responder' replies.*
*Used in: Section 6 (Authentication)*

**conform/conformance**
To comply in actions, behaviour, etc. with accepted standards or norms ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr14-td2)).
*Source: Dictionary*
*Used in: Section 8 (Demonstrating Conformance)*

**consequence**
Outcome of an event affecting objectives ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr15-td2)).
*Source: [ISO 31073:2022](https://www.iso.org/standard/79637.html)*
*Notes:*
* *A consequence can have positive or negative, direct or indirect, effects on objectives*
* *Consequences can be expressed qualitatively or quantitatively*
* *Any consequences can escalate through cascading and cumulative effects*
*Used in: Section 2 (Risk Assessment)*

**context**
Environment with defined boundary conditions in which entities exist and interact ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr16-td2)).
*Source: [ITU-T X.1252](https://www.itu.int/rec/T-REC-X.1252)*
*Used throughout all sections*

**contiguous**
Immediately preceding or following in time ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr17-td2)).
*Source: Dictionary — modified by adding "immediately"*
*Note: When applied to authentication, multiple factors are tested in such adjacent steps that they are considered part of a single process.*
*Used in: Section 6 (Authentication)*

**control (risk)**
Measure that maintains and/or modifies risk ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr18-td2)).
*Source: [ISO 31073:2022](https://www.iso.org/standard/79637.html) — modified*
*Notes:*
* *Risk controls include any process, policy, device, practice, or other conditions/actions which maintain and/or modify risk*
* *Risk controls do not always exert the intended or assumed modifying effect*
* *When using the Assessing Identification Risk guidance, these processes are not included as risk controls*
*Used in: Sections 2, 4-7 (Risk Assessment, Standards)*

**control (verb)**
To command, direct, or rule ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr19-td2)).
*Source: Dictionary*
*Note: Also indicates the ability for an authenticator holder to retain use of their authenticator.*
*Used in: Section 6 (Authentication)*

**correlate/correlation**
To place or be placed in a mutual, complementary, or reciprocal relationship ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr20)).
*Source: Dictionary*
*Used in: Section 4 (Federation)*

**corroborate/corroborating**
To confirm or support facts, opinions, etc., especially by providing fresh evidence ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr21)).
*Source: Dictionary*
*Used in: Section 5 (Information Assurance)*

**credential**
An artifact created as the result of a series of processes that bind an entity with information and an authenticator, on which other parties rely ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr22-td2)).
*Source: New definition*
*Note: At minimum, a credential includes an authenticator and information to enable presentation.*
*Used in: Section 4 (Federation)*

**credential provider**
The party accountable for the establishment and presentation facilitation of a credential ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr23-td2)).
*Source: New definition*
*Note: A Credential Provider may employ other parties in carrying out their function.*
*Used in: Section 4 (Federation)*

##### D

**delegate (verb)**
To give or commit duties, powers, etc. to another as agent or representative; depute ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr24)).
*Source: Dictionary*
*Used in: Section 7 (Binding)*

**delegate (noun)**
A person chosen or elected to act for or represent another or others ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr25-td2)).
*Source: Dictionary — modified to remove reference to conference or meeting*
*Used in: Section 7 (Binding)*

**derived value**
Value obtained by reasoning; deduction or inference ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr26)).
*Source: Expanded Dictionary meaning*
*Used in: Section 5 (Information Assurance)*

##### E

**enrol/enrolment**
To become or cause to become a member; enlist; register ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr27)).
*Source: Dictionary*
*Used throughout all sections*

**entity**
Something that has real or distinct existence from other things ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr28)).
*Source: Dictionary*
*Used throughout all sections*

**evidence**
To give proof of or evidence for ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr29)).
*Source: Dictionary*
*Used in: Sections 5, 7 (Information and Binding Assurance)*

##### F

**facilitate/facilitation**
To make easier; assist the progress of ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr30)).
*Source: Dictionary*
*Used in: Section 4 (Federation)*

**facilitation provider (FP)**
The party accountable for the establishment and functioning of a facilitation mechanism ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr31-td2)).
*Source: New definition*
*Note: A facilitation mechanism facilitates the presentation of one or more Credentials to a Relying Party.*
*Used in: Section 4 (Federation)*

**federate/federated/federation**
United by common agreement under an authority ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr32)).
*Source: Dictionary — modified to remove central government*
*Used in: Section 4 (Federation)*

**forgery**
The act of reproducing something for a deceitful or fraudulent purpose ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr33)).
*Source: Dictionary*
*Used in: Section 2 (Risk Assessment)*

##### I

**identification**
The act of identifying or the state of being identified ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr34)).
*Source: Dictionary*
*Used throughout all sections*

**identifier**
Information that is enough to uniquely represent an entity in a given context ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr35)).
*Source: New definition*
*Used in: Section 5 (Information Assurance)*

**identity**
The characteristics and qualities of being a specific person or thing; individuality ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr36)).
*Source: Dictionary — amalgamation of definition texts*
*Note: See also evolving definition below*
*Used throughout, though usage should be minimized*

**identity theft**
The theft or assumption of a pre-existing identity (or significant part thereof) with or without consent, and whether, in the case of an individual, the person is living or deceased ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr37-td2)).
*Source: Australian Centre for Policing Research*
*Note: When identity theft occurs, someone pretends to be or impersonates another by using their information or authenticator.*
*Used in: Section 2 (Risk Assessment)*

##### L

**level of risk**
Magnitude of a risk or combination of risks, expressed in terms of the combination of consequences and their likelihood ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr38)).
*Source: [ISO 31073:2022](https://www.iso.org/standard/79637.html)*
*Used in: Section 2 (Risk Assessment)*

**likelihood**
Chance of something happening ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr39-td2)).
*Source: [ISO 31073:2022](https://www.iso.org/standard/79637.html)*
*Notes:*
* *"Likelihood" refers to the chance of something happening, whether determined objectively or subjectively, qualitatively or quantitatively*
* *In English, "probability" is often narrowly interpreted as mathematical, while "likelihood" has broader interpretation*
*Used in: Section 2 (Risk Assessment)*

##### M

**mechanism**
A process or technique, especially of execution ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr40)).
*Source: Dictionary*
*Used in: Section 4 (Federation)*

##### O

**one-time password (OTP)**
A password that is valid for only one login session or transaction ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr41-td2)).
*Source: Wikipedia*
*Notes:*
* *Also known as one-time PIN or dynamic password*
* *Generation can be time-based OTP (TOTP) or event-based OTP/hash-based message authentication codes (HOTP)*
*Used in: Section 6 (Authentication)*

**orphan/orphaned**
Entity information that is not bound to an entity or authenticator ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr42)).
*Source: New definition*
*Used in: Section 7 (Binding)*

##### P

**party**
An entity who participates or is concerned in an action, proceeding, plan, etc. ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr43)).
*Source: Dictionary — modified to include non-persons*
*Used throughout all sections*

**present/presentation**
To offer or hand over for action or settlement ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr44)).
*Source: Dictionary*
*Used in: Section 4 (Federation)*

**pseudonymous**
Using a pseudonym ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr45-td2)).
*Source: Dictionary*
*Note: A pseudonym is an identifier that may relate to an individual entity but does not allow the entity to be identifiable outside the context.*
*Used in: Section 6 (Authentication)*

##### R

**relying party (RP)**
The accountable party who relies on presented credential(s) in order to make decisions ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr46-td2)).
*Source: New definition*
*Note: A Relying Party may employ other parties in carrying out their function.*
*Used throughout all sections*

**replication**
The act of repeating, duplicating, copying, or reproducing ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr47)).
*Source: Dictionary*
*Used in: Section 6 (Authentication)*

**risk**
Effect of uncertainty on objectives ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr48-td2)).
*Source: [ISO 31073:2022](https://www.iso.org/standard/79637.html)*
*Notes:*
* *An effect is a deviation from the expected—it can be positive, negative or both*
* *Objectives can have different aspects and categories and can be applied at different levels*
* *Risk is usually expressed in terms of risk sources, potential events, consequences and likelihood*
*Used in: Section 2 (Risk Assessment)*

**role**
Proper or customary function ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr49)).
*Source: Dictionary*
*Used throughout all sections*

##### S

**self-sovereign**
An entity having sole ownership over the ability to control their accounts and information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr50)).
*Source: Based on searchsecurity.techtarget.com*
*Used in: Section 4 (Federation)*

**service**
A system or method of providing people with the use of something ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr51-td2)).
*Source: Dictionary*
*Notes:*
* *Today service has broader application than utilities—includes finance, employment and compliance services*
* *A service may contain one or more transactions*
*Used throughout all sections*

**session**
An unbroken interactive information interchange between two or more entities ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr52)).
*Source: Wikipedia (computer science) — modified*
*Used in: Section 6 (Authentication)*

**spoofing**
Presenting a recorded image or other biometric data sample, or an artificially derived biometric characteristic, in order to impersonate an individual ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr53)).
*Source: [ISO/IEC TR 24714-1:2008](https://www.iso.org/standard/41447.html)*
*Used in: Section 6 (Authentication)*

**subject**
Entity that is the focus of entity information ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr54)).
*Source: New definition*
*Used in: Section 5 (Information Assurance)*

**synchronise/synchronous**
To occur or recur or cause to occur or recur at the same time or in unison ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr55)).
*Source: Dictionary*
*Used in: Section 6 (Authentication)*

##### T

**transaction**
One or more exchanges between an individual and an organization in a process related to a specific outcome ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr56-td2)).
*Source: New definition*
*Notes:*
* *A single transaction may constitute a step in a segmented process or result in the completion of an end-to-end process*
* *A service is usually made up of several transactions*
*Used throughout all sections*

#### Evolving Terms

Terms in this section are still being developed, used inconsistently, or insufficiently defined. Once they have consistent context and use, they move to the agreed terms section ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart2-para1)).

**identity (evolving definition)**
One or more attributes that allow an entity record to be unique from all others in the context ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart2-para2-tb1-tr1-td2)).
*Source: New definition*
*Note: Due to the contextual nature of attributes that make up an identity and its poor interaction with other words, avoid using "identity" as a descriptor wherever possible.*

### 9.2 Templates and Tools

#### Available Resources

Use these templates and tools to gather evidence for conformance assessment and implement the Identification Standards effectively ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#h1-subtitle)).

#### Conformance Assessment Checklists

These checklists help you collate evidence for each relevant control ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)):

| Template Name | Purpose | Download Link | When to Use |
|---|---|---|---|
| **Information & Binding Assurance Checklist** | Document evidence for IA and BA standards | [DOCX, 48KB](../../files/Conformance-Checklist-Information-Binding-Assurance.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5-para3-1)) | Preparing for IA/BA conformance assessment |
| **Authentication Assurance Checklist** | Document evidence for AA standard | [DOCX, 46KB](../../files/Conformance-Checklist-Authentication-Assurance-v2.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)) | Preparing for AA conformance assessment |
| **Credential Establishment Checklist** | Document evidence for credential processes | [DOCX, 45KB](../../files/Conformance-Checklist-Credential-Establishment-v2.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)) | Implementing federation standard |
| **Facilitation Mechanisms Checklist** | Document evidence for facilitation controls | [DOCX, 49KB](../../files/Conformance-Checklist-Facilitation-Mechanisms-v2.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)) | Implementing federation facilitation |

#### Levels of Assurance Documentation

Documenting conformance with controls that have Levels of Assurance requires understanding the multi-level approach. Use these templates to document your assurance levels ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5-para4)):

| Template Name | Purpose | Download Link | When to Use |
|---|---|---|---|
| **Levels of Assurance Table — Information & Binding** | Map controls to assurance levels for IA/BA | [DOCX, 48KB](../../files/Levels-of-Assurance-Table.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)) | Planning assurance level implementation |
| **Authentication Factor Level Table** | Map authenticator types to AA levels | [DOCX, 43KB](../../files/Authentication-Factor-Level-Table.docx/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section5)) | Selecting appropriate authenticators |

#### Risk Assessment Tools

Risk assessment determines which Levels of Assurance to apply for certain controls ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section3-para1)).

**Risk Assessment Workbook**
The Identification Team developed a workbook to help you undertake identification risk assessment and determine optimal assurance levels ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-binding-assurance-standard/2024/en/#part2-subpart1-section1-para2)).

To obtain a copy: Email [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)

**Risk Assessment Guidance**
While you can use any risk assessment process, specific guidance is available at:
[Assessing identification risk](https://docref.digital.govt.nz/nz/identification-management/assessing-identification-risk/2025/en/) ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part3-subpart2-section3-para2))

#### How to Use These Tools Effectively

**For Initial Implementation**:
1. Start with the Risk Assessment Workbook to determine your required assurance levels
2. Use the Levels of Assurance Tables to map controls to your selected levels
3. Apply the relevant conformance checklists to gather evidence

**For Conformance Assessment**:
1. Complete all applicable checklists before assessment
2. Ensure evidence addresses each control at your declared level
3. Use checklists to identify gaps in your implementation

**For Ongoing Maintenance**:
1. Update checklists when processes change
2. Review risk assessments annually or when threats evolve
3. Keep evidence current for re-conformance requirements

### 9.3 Authenticator Type Reference

#### Three Authentication Factors

Authenticators classify into three different authentication factors ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authenticator-types/2021/en/#part2-section2-para1)):

#### Factor 1: Something You Are — Biometric Recognition

Biometric authenticators use challenges based on characteristics intrinsically linked to a person—either biological (like fingerprints) or behavioral (like typing patterns). Automated authentication based on this factor is called biometric recognition ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authenticator-types/2021/en/#part5-para1)).

**Key Characteristics**:
* Substantively unique to individual entities
* More reliable for authenticating specific entities than knowledge or possession factors
* Probabilistic rather than binary responses ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart3-section36-para1))

**Common Biometric Types**:
* Fingerprint recognition
* Facial recognition
* Iris scanning
* Voice recognition
* Behavioral patterns (typing, gait)

**Assurance Level Considerations**:
* **Lower levels**: Accept that a small proportion of false positives may occur ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart3-section36))
* **Higher levels**: Require very low false positive rate and combination with another authentication factor ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart3-section36-para5))

**Practical Considerations**:
* Tend to be expensive, especially with full liveness testing
* Resistant to loss and cannot be easily lent
* Most controversial authenticator type ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authenticator-types/2021/en/#part5-det12-para7))

#### Factor 2: Something You Know — Knowledge-Based

Knowledge authenticators rely on information only the legitimate user should know.

**Common Knowledge Types**:
* Passwords
* PINs
* Passphrases
* Security questions
* Patterns

**Threats to Knowledge Factors**:
* Guessing or brute force attacks
* Social engineering
* Shoulder surfing
* Phishing
* Credential stuffing

**Best Practices**:
* Enforce minimum complexity requirements
* Implement rate limiting for attempts
* Require regular updates for high-risk contexts
* Avoid predictable or discoverable information

#### Factor 3: Something You Have — Possession-Based

Possession authenticators require the user to have physical or logical control of an object or device.

**Common Possession Types**:
* Hardware tokens
* Smart cards
* Mobile devices
* Software certificates
* SMS/Email OTP delivery

**Threats to Possession Factors** ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part5-subpart2-section30)):
* Replication or forgery of physical documents or devices
* Replication of codes (static or dynamic) used for challenges
* Replication of location-based values

**Protection Mechanisms**:
* Two-factor authentication at higher levels mitigates physical acquisition threats
* Dynamic codes prevent replay attacks
* Cryptographic protection prevents cloning

#### Multi-Factor Authentication

**Two-Factor Combinations**:
Combine different factor types for stronger authentication. Common combinations:
* Knowledge + Possession (password + OTP)
* Knowledge + Biometric (PIN + fingerprint)
* Possession + Biometric (smart card + facial recognition)

**Level 4 Requirements**:
At level 4, combine a knowledge factor with a biometric factor. This mitigates both manipulated disclosure and active authenticator sharing ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-authentication-assurance-standard/2024/en/#part3-section20-para3)).

**Contiguous Testing**:
When implementing multi-factor authentication, test factors in immediately adjacent steps so they're considered part of a single process ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart1-para2-tb1-tr17)).

#### Authenticator Selection by Assurance Level

**Level of Authentication Assurance 1 (LoAA1)**:
* Single-factor acceptable
* Basic password or PIN sufficient
* Minimal complexity requirements

**Level of Authentication Assurance 2 (LoAA2)**:
* Single-factor with enhanced controls
* Stronger passwords or OTP
* Additional protection mechanisms

**Level of Authentication Assurance 3 (LoAA3)**:
Achieve through either ([DocRef](https://docref.digital.govt.nz/nz/identification-management/authentication-assurance-standard/2024/en/#part6-para5-3)):
* Good biometric factor, or
* Combining two different factor types

**Level of Authentication Assurance 4 (LoAA4)**:
* Two-factor required
* Must include biometric factor
* Knowledge factor as second factor

#### Selecting the Right Authenticator

Consider these factors when selecting authenticators ([DocRef](https://docref.digital.govt.nz/nz/identification-management/implementing-the-federation-assurance-standard/2025/en/#part3-subpart2-section23-para3)):

**User Capability**:
* Technical sophistication of user base
* Accessibility requirements
* Device availability
* Cost considerations for users

**Implementation Factors**:
* Deployment and maintenance costs
* Integration complexity
* Support requirements
* Fallback options needed

**Security Requirements**:
* Risk level of protected resources
* Threat environment
* Regulatory requirements
* Interoperability needs

For detailed authenticator implementation guidance, see Section 6 (Authentication Assurance Standard).

### 9.4 Historical Version Information

#### Standards Evolution

The Identification Standards change from time to time to remain relevant. When changes occur, they may require re-conformance before statement expiry. The Identification Team consults conforming parties well in advance when this happens ([DocRef](https://docref.digital.govt.nz/nz/identification-management/conforming-with-the-identification-standards/2025/en/#part4-det6-para1)).

Less significant changes and improvements may be addressed through updated guidance without requiring re-conformance ([DocRef](https://docref.digital.govt.nz/nz/identification-management/overview-of-the-identification-standards/2024/en/#part3-para3)).

#### Current Version Information

**Federation Assurance Standard**:
Version 3 (current) — minor clarifications and control refinement ([DocRef](https://docref.digital.govt.nz/nz/identification-management/federation-assurance-standard/2025/en/#part1-subpart1-para2))

**Information Assurance Standard**:
Current version effective from specified date in standard

**Authentication Assurance Standard**:
Current version effective from specified date in standard

**Binding Assurance Standard**:
Current version effective from specified date in standard

#### Version Transition

**For Organizations with Existing Conformance**:
* The Identification Team advises when standards changes affect existing conformance statements
* Consultation occurs well in advance of changes requiring re-conformance
* Grace periods provided for compliance with new requirements
* Phased implementation supported where practical

**For New Implementers**:
* Always use the current version of standards
* Review release notes for recent clarifications or control refinements
* Check guidance documents for implementation updates
* Contact the Identification Team if unsure about version requirements

#### Monitoring Standards Evolution

Standards evolve in response to ([DocRef](https://docref.digital.govt.nz/nz/dia-distfr/2/en/#part5-rule13-para8-b)):
* Changes in risks, threats, and operating environment
* Technological advances
* International standards alignment
* User feedback and implementation experience
* Regulatory changes

#### Accessing Historical Versions

For access to previous versions of standards or transition guidance:
* Contact: [identity@dia.govt.nz](mailto:identity@dia.govt.nz/)
* Visit: [Digital Identity Services Trust Framework](https://www.digital.govt.nz/standards-and-guidance/identification-management/)

#### DISTF Rules Updates

The Digital Identity Services Trust Framework Rules (DISTFR) also undergo periodic updates ([DocRef](https://docref.digital.govt.nz/nz/dia-distfr/2/en/#ap1-para1-tb1-tr2-td3)):
* Version 2 updated standards and policies
* Added and clarified definitions
* Minor edits to wording and grammar

### 9.5 Electronic Identity Verification Act (EIVA)

The Electronic Identity Verification Act provides New Zealand's legislative framework for electronic identity verification services. EIVA and the Identification Management Standards serve different but complementary purposes. EIVA establishes legal requirements specifically for electronic identity verification services, while the Identification Management Standards provide technical and process assurance requirements for identification management broadly. Organizations may need to consider both frameworks depending on their services—conformance with the Identification Management Standards does not automatically satisfy EIVA obligations, nor does EIVA compliance necessarily meet all identification management standards. If you provide electronic identity verification services in New Zealand, review EIVA requirements separately at [legislation.govt.nz](https://www.legislation.govt.nz/act/public/2012/0123/latest/DLM3136810.html).

---

*Last updated 22 May 2025* ([DocRef](https://docref.digital.govt.nz/nz/identification-management/identification-terminology/2025/en/#subpart2-para3))