CDR Minimum Baseline Authentication: The Proposed April 2028 OTP Uplift

ByRegReportingDesk

Consultation Draft 374, the Data Standards Body’s draft standards for CDR minimum baseline authentication, opened for consultation on 29 October 2026, the date on Treasury’s consultation listing and the DSB site. The draft would lift the one-time password (OTP) range in the Consumer Data Right Data Standards from 4 to 6 digits to 6 to 10 digits, require cryptographically secure OTP generation, and require data holders to send OTPs only to channels pre-registered to the consumer and verified as theirs. The new obligations share one date, 30 April 2028.

Data holders carry most of the build; the DSB’s cost model covers ADIs, non-bank lenders and energy data holders. Accredited data recipients pick up a new Redirect to Web section and the error information data holders would have to return when authentication fails. None of this binds yet. The proposal rests on rule 8.11(1)(c)(i) of the CDR Rules, which requires the Data Standards Chair to make standards on authenticating CDR consumers that meet, in the Chair’s opinion, best practice security requirements.

Related reading: RBA A2A Payments Vision: A Readiness Guide for Australian PSPs

CDR minimum baseline authentication dates, from consultation opening to April 2028

  • 29 October 2026: consultation opens, per Treasury’s consultation listing and the DSB site; the timeline on the Treasury consultation page itself shows 28 October 2026.
  • 26 November 2026, 5:00 PM AEDT: submissions close.
  • April 2027: intended release; clause 1.1 commences each amendment on a “[the Release date]” placeholder the DSB expects to fall in April 2027.
  • 10 May 2027: the existing Redirect to App obligation date in the current standards, which CD374 leaves in place.
  • 29 April 2028: last day on which Redirect to Web with OTP remains the mandated fallback.
  • 30 April 2028: obligation date for the new OTP credential requirements, the Redirect to Web section, the revised fallback rule and four revised or added common authentication rows, comprising one replacement and three additions.

Commencement and obligation are separate events. An April 2027 release is an intended timetable, not a completed regulatory event. If the Chair adopts and publishes the proposed amendments, their commencement and obligation dates will be determined by the final text and its Future Dated Obligations schedule. Note 3 to clause 1.2 lets data holders and data recipients implement early unless a standard says otherwise.

OTP credential requirements: length, randomness and the delivery channel

Clause 3.1 rewrites the One Time Password Credential Requirements section of the Security Profile. The current text applies “Where a data holder supports the ‘Redirect to Web with OTP’ flow”; the draft applies “Where a data holder supports an OTP flow”, and the explanatory document says the section would cover any OTP flow. Two existing bullets become three:

Requirement Current standards (v1.36.0) CD374 draft (from 30 April 2028)
Trigger Data holder supports Redirect to Web with OTP Data holder supports an OTP flow
Length MUST be numeric, 4 to 6 digits MUST be numeric, 6 to 10 digits
Generation At the data holder’s discretion; SHOULD include pseudo-randomness appropriate to the use case MUST use a cryptographically secure mechanism so an attacker cannot feasibly predict valid OTPs
Delivery Existing requirements already govern OTP delivery through established customer channels, alignment with preferred channels and controls against interception; no equivalent pre-registration-and-verification requirement is identified among the existing bullets MUST deliver only to a channel securely pre-registered to the end user and verified to be under their control

The length, generation and delivery changes are informed by the 2022 Independent Health Check of the CDR Information Security Profile, commissioned by the Chair. Recommendation 5 asked for at least 6 digits, a floor the DSB also attributes to NIST SP 800-63B-4. Recommendation 8 asked for appropriate randomness; the DSB gives CSPRNGs and time-based OTPs as current examples. Recommendation 3 had proposed consumer permission before using a channel not set up for authentication, which the draft replaces with pre-registration plus verification, leaving the method to the data holder.

The delivery bullet turns on registration and verification. On my reading, a mobile number or email address that simply sits on the customer record does not meet it by itself: the text requires secure pre-registration to the end user and verification that the channel is under their control, and the Health Check concern behind it was OTPs reaching channels shared with other people. Because the current text caps OTPs at 6 digits, a 6-digit code from a cryptographically secure generator is, on my reading, the one length valid under both versions.

Redirect to Web takes over from Redirect to Web with OTP as the fallback

Today, where Redirect to App cannot be used for CDR authentication and Decoupled Authentication is not supported, data holders MUST continue to support the Redirect to Web with OTP flow. Clause 4.1 splits that rule in time. On and before 29 April 2028 the current wording stays; on and from 30 April 2028 the same condition triggers a duty to support the “Redirect to Web” flow, with the OTP qualifier gone. The DSB’s stated aim is a broader range of fallback mechanisms from that date; Redirect to Web with OTP stays until then so the future dated obligations set by Decision 369, the Redirect to App decision, are not disturbed.

Clause 4.2 inserts a Redirect to Web section into the Authentication Schedule with mirrored text for data holders and data recipients: each MUST implement Redirect to Web in line with the consumer experience and security profile standards, and each MAY do so before 30 April 2028. The explanatory document calls this a restatement, meant to keep Redirect to Web available on an ongoing basis so it can work as a fallback.

Removing “with OTP” from the fallback leaves OTPs available. The DSB says data holders are not expected to change their systems to remain compliant, and that more secure mechanisms become a voluntary option. A data holder that keeps OTP inside Redirect to Web stays compliant on the fallback point, and its OTPs then fall under clause 3.1 in full.

One drafting point is worth testing. The new Future Dated Obligations row reads “Data holders implementing Redirect to App MUST support the ‘Redirect to Web’ flow on and from 30 April 2028”, while clause 4.1 keys the duty to Redirect to App being unavailable and Decoupled Authentication being unsupported. For a data holder with no app, the two formulations do not obviously line up.

Error messaging and redirection, the change data recipients build for

Clause 5.3 inserts an “Authentication: Error messaging and redirection” row into the Common Authentication Standards with two modalities. A data holder MAY show the consumer an error message with guidance, and that message MUST NOT disclose information that could compromise security. Separately, the draft says that where an authentication flow cannot be completed successfully, the data holder MUST include error information in the redirect to the data recipient, in accordance with the error response specifications in section 4.1.2.1 of the OAuth 2.0 Authorization Framework (RFC 6749) or section 3.1.2.6 of OpenID Connect Core 1.0. The draft states no further condition, but on my reading the cited specifications carry exceptions that stay in place: RFC 6749 section 4.1.2.1 prohibits automatic redirection to a missing, invalid or mismatching redirect URI, or where the client identifier is missing or invalid, and OpenID Connect Core section 3.1.2.6 also prohibits redirection to an invalid URI and specifies an HTTP 400 response without error response parameters where the response mode is unsupported.

RFC 6749 draws the error parameter from seven codes, such as access_denied and temporarily_unavailable, with optional error_description and error_uri fields; OpenID Connect Core adds codes such as login_required.

The DSB says some data holders may need to update authorisation endpoint behaviour, and sees error handling as the likely cost driver for accredited data recipients, whose overall impact it calls limited.

Digital onboarding, accessible authentication and user identifiers

The other three Part 5 rows are mostly permissions. Clause 5.1 replaces the App Install row with “Authentication: Digital onboarding”: data holders MAY invite consumers using Redirect to Web flows to create an online account or install the data holder’s app, and the invitation MUST NOT introduce unwarranted friction.

Clause 5.2 adds “Authentication: Accessible authentication”: data holders SHOULD ensure compliance with relevant accessibility standards, in particular WCAG Success Criteria 3.3.8 (level AA in WCAG 2.2) and 3.3.9 (level AAA). The DSB ties this to the longer OTP, since authentication should not depend on memorising random digits, and expects the most direct impact on data holders that restrict copy and paste or use input fields assistive technologies cannot work with.

Clause 5.4 adds “Authentication: User identifier”: data holders MAY support identifiers familiar to the consumer, such as a mobile number or email address, and the identifier MUST uniquely identify a customer and MUST NOT be a shared or group identifier.

The clause 2.1 row says data holders “MUST implement” all four rows on and from 30 April 2028. That wording leaves the MAY and SHOULD inside the rows as they are. On my reading, the proposed error information requirement would become mandatory on the obligation date specified in the final standards.

User identifier uniqueness is already required by the current Security Profile: where a data holder requests an identifier for authentication, it MUST request one that can uniquely identify the customer. CD374 would add an express prohibition on shared or group identifiers in the new consumer-experience row. Onboarding invitations and familiar alternative identifiers would remain optional, while accessibility would remain a SHOULD recommendation.

What the DSB expects CD374 to cost

Cohort DSB definition Indicative one-off cost per entity
Small ADI Fewer than one million account holders $46,000
Medium ADI Between one and five million account holders $115,000
Large ADI More than five million account holders $229,000
Non-bank lender Non-bank lenders $58,000
Energy data holder Energy providers $58,000
ADR Accredited data recipient $26,000

The model assumes current compliance and implementation of every requirement and recommendation in the amended text, and excludes ongoing operational, maintenance, monitoring and compliance costs. The DSB states the figures are not a minimum, maximum or expected cost for every entity, and expects the OTP length change to affect a small number of data holders, since 6-digit OTPs are already increasingly common.

Frequently Asked Questions

Do the OTP rules reach an OTP used outside Redirect to Web?

The draft trigger is “Where a data holder supports an OTP flow”, so on that wording an OTP step anywhere in a data holder’s CDR authentication would need the new controls. The draft does not define “OTP flow”; a submission can ask the DSB to settle where the boundary sits.

If data recipients MUST implement Redirect to Web, why does the DSB see no direct Part 4 impact on them?

Redirect to Web with OTP is already the mandated fallback, so on my reading the MUST confirms a journey recipients already handle. A recipient that has tested only Redirect to App would want to confirm its web redirect path still works.

Key Takeaways

  • Data holders: inventory OTP use across CDR authentication and assess the proposed length, generation and delivery controls alongside the existing Security Profile requirements for user identification, OTP expiry, restriction to CDR authentication, interception risk and enumeration controls. Confirm the final scope and obligation date before implementation.
  • Data holders with no app: check how the revised fallback rule and its Future Dated Obligations row apply, and raise any mismatch in a submission.
  • Data recipients: decide ahead of the proposed 30 April 2028 obligation date how each RFC 6749 and OpenID Connect error code will translate into consumer guidance.

Sources and References

Preparing a CD374 submission before 26 November

The consultation asks five questions. The explanatory document asks for submissions through the online form on the Treasury consultation page by 5:00 PM AEDT on 26 November 2026, with Word format recommended and PDF accepted; the Treasury page itself lists the 26 November closing date without a time.

Disclaimer: The information on RegReportingDesk.com is for educational and informational purposes only. It does not constitute legal, regulatory, tax, or compliance advice. Always consult your compliance officer, legal counsel, or the relevant supervisory authority for guidance specific to your institution.

Similar Posts