What does control A.3.23 require?
Secure authentication technologies and procedures related to PII processing shall be implemented based on information access restrictions.
This control sits within the Shared security controls annex (A.3) and establishes that access to systems processing PII must be protected by robust authentication mechanisms. The phrase “based on information access restrictions” is important: the strength and type of authentication should be proportionate to the sensitivity of the PII and the level of access being granted. A system handling special category data warrants stronger authentication than one processing basic contact details.
What does the Annex B implementation guidance say?
Annex B (section B.3.23) provides the following guidance:
- Secure log-on procedures for customer accounts — Where required by the customer, the organisation should provide the capability for secure log-on procedures for any user accounts under the customer’s control
The processor-focused guidance highlights an important contractual dimension: processors must be able to provide secure authentication capabilities that meet their customers’ (controllers’) requirements. This may include multi-factor authentication, single sign-on integration, IP allowlisting or other authentication controls specified in the data processing agreement.
How does this map to GDPR?
Control A.3.23 maps to the following GDPR article:
- Article 5(1)(f) — The integrity and confidentiality principle, requiring appropriate security of personal data including protection against unauthorised access
Weak or absent authentication is a direct path to unauthorised access to personal data, making this control fundamental to Article 5(1)(f) compliance.
For the full GDPR-to-ISO 27701 mapping, see GDPR Compliance Guide.
What changed from ISO 27701:2019?
For a step-by-step approach, see the Transition from 2019 to 2025.
In the 2019 edition, this requirement was covered by Clause 6.6.4.2 (secure log-on procedures). The 2025 edition broadens the scope from log-on procedures specifically to secure authentication technologies and procedures more generally as A.3.23. This reflects the evolution of authentication beyond traditional username and password log-on to include biometrics, hardware tokens, passwordless authentication and adaptive risk-based authentication. See the Annex F correspondence table for the full mapping.
Start your free trial
Want to explore?
Sign up for your free trial today and get hands on with all the compliance features that ISMS.online has to offer
What evidence do auditors expect?
When assessing compliance with A.3.23, auditors will typically look for:
- Authentication policy — A documented policy specifying authentication requirements for different system types and PII sensitivity levels, including password complexity rules, MFA requirements and session management controls
- MFA deployment — Evidence that multi-factor authentication is implemented for systems processing PII, particularly for remote access, privileged accounts and customer-facing portals
- Access control matrix — A mapping between system roles, PII access levels and required authentication strength
- Log-on procedure configuration — Technical evidence of secure log-on configuration including account lockout thresholds, failed attempt logging and session timeout settings
- Customer-facing authentication capabilities — For processors, evidence that secure authentication options are available to customers as described in the data processing agreement
What are the related controls?
| Control | Relationship |
|---|---|
| A.3.8 Identity management | Authentication verifies the identities managed under A.3.8 Identity Management |
| A.3.9 Access rights | Authentication strength should be proportionate to the access rights being protected |
| A.3.22 User endpoint devices | Endpoint devices should enforce secure authentication before granting PII access |
| A.3.25 Logging | Authentication events (successful and failed) should be logged and monitored |
| A.3.26 Use of cryptography | Cryptographic mechanisms underpin many authentication technologies |
Who does this control apply to?
A.3.23 is a shared control that applies to both PII controllers and PII processors. Controllers must implement secure authentication for their own systems processing PII. Processors have the additional obligation to provide secure authentication capabilities for customer-controlled accounts where required by the customer, making authentication a contractual as well as a technical requirement.
Manage all your compliance, all in one place
ISMS.online supports over 100 standards and regulations, giving you a single platform for all your compliance needs.
Why choose ISMS.online for authentication management?
ISMS.online provides practical tools for implementing and managing secure authentication:
- Access control framework — Define and document authentication requirements per system, role and PII sensitivity level in a central, auditable location
- Policy management — Publish authentication policies with version control and staff acknowledgement tracking
- Risk assessments — Assess authentication-related risks with pre-built threat scenarios for credential theft, brute force attacks and session hijacking
- Compliance tracking — Monitor which systems meet your authentication baseline and which have outstanding actions
- Evidence management — Store and organise authentication configuration evidence, MFA deployment records and audit reports for easy retrieval during assessments
FAQs
Is multi-factor authentication mandatory?
The control does not explicitly mandate MFA, but it requires authentication to be implemented “based on information access restrictions” — meaning the authentication strength must be proportionate to the risk. For systems processing sensitive PII, remote access and privileged accounts, MFA is widely considered the minimum acceptable standard. Auditors will expect a risk-based justification for any systems processing PII that do not use MFA.
What authentication methods are considered secure?
Secure authentication methods include multi-factor authentication (combining something you know, something you have and something you are), hardware security keys (e.g. FIDO2/WebAuthn), biometric authentication, certificate-based authentication and adaptive risk-based authentication. Password-only authentication is increasingly considered insufficient for systems processing PII, particularly for remote access. Passwordless approaches using hardware tokens or biometrics are gaining acceptance as a more secure and user-friendly alternative.
What are the processor-specific obligations?
Processors must provide secure log-on capabilities for customer-controlled accounts where required by the customer. This means processors should be able to offer MFA, SSO integration, IP allowlisting or other authentication features that controllers need to meet their own compliance obligations. These capabilities should be documented in the data processing agreement and made available without additional barriers.
