Get free passkey whitepaper for Australian organizations.

Get for Free

The Australian government has taken a great step towards improving cyber security by implementing passkeys for myGov, the country's primary e-government portal.

With myGov hosting critical services such as Centrelink, the Australian Tax Office, and Medicare, it is an attractive target for cybercriminals. Australians have already lost $3.1 billion to scams this year alone, highlighting the need to improve authentication, as a major attack vector, in general. Recent data breaches, like those affecting Latitude (14 million customers), Optus (9.8 million customers), and Medibank (9.7 million customers), have demonstrated the severe impact of cyberattacks on both individuals and organizations (more examples of data breaches can be found here).

To protect against these threats, the Australian government's national cyber security strategy has emphasized the adoption of passkeys as a key component. Passkeys are the only viable way to achieve phishing-resistance MFA for consumers.

In this article, we analyze myGov’s rollout of passkeys, examining the technical implementation, product flows, and the strategic thinking behind this move. Our goal is to provide a comprehensive overview that educates software developers and product managers to implement passkeys based on industry best practices and avoid mistakes that myGov has made in their passkeys implementation.

In our detailed analysis of myGov’s passkey implementation, several key findings highlight both strengths and areas for improvement. Here’s a concise summary of our observations:

Our Findings of myGov’s Passkey Implementation

• No Upsell to Passkeys After Login with Password and SMS OTP: myGov does not offer a transition to passkeys after logging in with a password and SMS OTP. This means users are not prompted to upgrade to passkey authentication even though their devices might be passkey ready.
• SMS OTP Stays the #1 MFA Method Even Though a Passkey Might be Created: If a user logs in with a password and has a passkey available, the system still sends an SMS OTP instead of offering a passkey login. This keeps the login process not resistant against phishing attempts, even though it is an MFA process.
• Email Address and Mobile Number are Verified During Account Creation: During the creation of new accounts, myGov collects and verifies email addresses and phone numbers. This is best practice, so that email and / or SMS OTP can be used as fallback methods if passkeys are not available.
• Separate Passkey Button Instead of Identifier-First Passkeys: A separate and “dumb” passkey button is provided on the sign-in page instead of using a smart identifier-first approach for using passkeys, which leads to lower adoption and take-rates for passkeys.
• Correct WebAuthn Server Settings for Passkeys: The WebAuthn server settings and ceremony flags in the PublicKeyCredentialCreationOptions and PublicKeyCredentialRequestOptions are correctly implemented, ensuring that passkeys are used in the best way possible.
• Correct Error Handling in Safari Clamshell Mode: There is a correct error thrown for User Verification in Safari’s clamshell mode meaning that no security is lowered in clamshell mode.
• Passkey Button is Below the Fold: The passkey button is placed below the fold, which leads to lower passkey adoption and take-rates.
• Lack of Conditional UI (Passkey Autofill): The native app and web app does not support Conditional UI (passkey autofill), which reduces user convenience and the adoption tremendously.
• Good Email Notification Strategy: What we liked pretty much was the fact that for every important action, like passkey creation or password turn off, a new transactional email is sent to the user.

Overall Assessment

• Solid Technical Passkey Implementation: The technical implementation of passkeys in myGov is solid, with correct WebAuthn server settings and no bugs during our testing.
• Passkey Adoption Rates Expected to be Low: We expect low passkey creation adoption as the passkey creation is only available on the settings page, with no pro-active engagement to increase passkeys adoption (e.g. via popups or communication in emails).
• Passkey Login Rates to be Low: The passkey login rate is expected to be very low due to the lack of conditional UI, the passkey button strategy (which is even below the fold) and lack of passkey promotion in general.

In the following sections, we will go deeper into each of these points, exploring the implications and offering recommendations for improving passkey adoption and user experience in myGov.

The table provides a good overview of myGov’s passkey implementation of certain passkeys features. Features marked with a ⭐ are considered the top features of their category and are crucial for a great and secure passkey experience.

Subscribe to our Passkeys Substack for the latest news, insights and strategies.

Subscribe

This section analyzes the product flows of myGov’s passkeys across a variety of platforms, including web apps, as well as native Android and iOS apps. The availability of passkeys extends across all major operating systems - iOS, Android, macOS, and Windows.

The following parts analyze sign-up, passkey creation, passkey management, and login processes within myGov’s passkey integration.

Become part of our Passkeys Community for updates and support.

Join

A pure passkey-only sign-up on myGov is currently not (yet) possible. Instead, users must confirm their email via OTP and then provide a password. After completing these steps, they can add a passkey to their account.

Navigate to the Create a myGov account page where the sign-up flow starts. We decided to create an account via email (not via Digital Identity).

Please note that I left out some steps in the screenshots and only proceeded with the most important ones.

Afterwards, we provide an email address:

After clicking on Next, an email OTP is sent out and we’re forwarded to the next page to enter the OTP to finish the account verification.

Next, we need to provide a mobile number which will receive an SMS OTP. Though, there is the option to skip this step and add a mobile number later.

After entering the SMS OTP, we’re forwarded to the Create password page. This means an entirely passwordless account creation is not (yet) possible (however, as you’ll see later you can remove this password). Thus, this password creation step could be omitted in the future.

Moreover, the password requirements are pretty complex and not user-friendly at all. Also, you have to re-enter the password.

After finding a suitable password and clicking on Next, we now need to provide three select three questions and provide corresponding answers. This is quite and outdated process and not really secure, as often the answers to these questions can be found in public social media profiles of users. Moreover, many of these questions are pretty complex and I have to admit that I didn’t know the answer for most of the suggested questions.

If the account is successfully created, you should see this screen:

In parallel, the following email is sent out confirming that the account creation was successful. What is notable is that passkeys are not stated as a valid option after username and password provision, which shows further room for optimization:

The sign up does not really work natively in the native Android / iOS app, as instead you are forwarded to a WebView where the same steps as in the web app which was described above have to be completed.

As we have seen that passkeys cannot be created in the account creation process, we need to create them via the account settings.

For the following screenshots, we’re using a Windows 11 device and the Chrome browser.

The process of creating a passkey begins by navigating to the My account section in the top right corner and then click on Account settings. You should see the following page:

Next, click on Manage in the Passkeys section on the bottom.

As part of step-up authentication, we’re prompted to provide our password again, even though we’re already authenticated. After providing our password, we see this screen:

What’s interesting here is the artificial limit on the number of passkeys that can be created which is only three. If you’re using different devices or want to use hardware security keys (often you need a backup hardware security key in case the first one breaks or is lost) in parallel to synced passkeys, the limit of three might be quickly reached.

We click on the Create passkey button. This guides us to this page, where a link to additional passkey information is provided. However, on the page itself not much about passkey benefits or characteristics is stated and also the user is not told what will happen after they click on Next.

After clicking on the Next button, the passkey creation ceremony starts.

We scan our fingerprint in the Windows Hello dialogue and see the following success message:

From the success message in the modal, we can see the that Relying Party ID is “login.my.gov.au” and the WebAuthn user.id is set to the username (here “FP637225”).

Afterwards, we’re redirected back to the Settings: Passkeys page, where we see the new passkey in the list on the bottom, with a pre-defined name (here “Windows Hello Hardware Authent”), timestamps for creation and last used date, as well as the type, which is Non-synced in this case.

Interesting and great for account security is the option to Turn off password, and instead use passkeys (or Digital Identity) to login.

In parallel, a success email is sent out:

If you already have created three passkeys and try to create a fourth passkey, the following popup emerges:

Let’s have a look at the passkey management capabilities. Therefore, we stay in this Settings: Passkeys page to analyze the different passkey management options.

The passkey list contains a helper icon with a question mark that provides more insights about the type of passkeys:

• Non-synced: “A non-synced passkey is saved on a physical security token or device, not in a password manager. It can only be used on that device and can’t be shared across devices”

• Synced: “A synced passkey is saved to a password manager and is available to all devices using that password manager. For example, an iPhone or iPad signed in to the same Apple ID can use the same passkey”

That’s a pretty pragmatic and user-friendly way of describing the two different types of passkeys. However, the second sentence of non-synced passkeys is a bit misleading in case of hardware security keys (e.g. YubiKeys) which can be used across devices (myGov support hardware security keys).

To rename a passkey, we click on the Edit button, so that we can better distinguish them:

When trying to create multiple passkeys from the same passkey provider, we see that excludeCredentials is properly implemented and the creation of multiple passkeys on the same authenticator is prevented to avoid duplication of passkey creation.

If we cancel the passkey creation modal, we’ll get another rather cryptic error message, that doesn’t really tell the user why the error message popped up:

Now, we try to delete a passkey from the list of existing passkeys:

We decided to delete the third passkey “YubiKey 5 Series with NFC”. Thus, we click on Remove which leads us to this page:

We confirm by clicking again on Remove. Upon successful passkey deletion, the following message is displayed on top in the Settings: Passkeys page:

Simultaneously, an email with a notification is sent out:

As we’ve seen before, a notable feature within the passkey management settings is the option to Turn off passwords, what we do now by clicking on the corresponding button.

We click on Turn off again.

A success message will be displayed:

If we click on Turn on password, then we’ll see this screen:

So, we click Turn on and passwords are working again. On the bottom of the page, you’ll see an option to also update the password which is a voluntary step. The feature to turn on passwords indicates that passwords are still stored in myGov’s database but cannot be used as login method anymore.

This implies that theoretically the passwords could still be breached and stolen from myGov’s databases.

In case you tried to log in with email and password if passwords are turned off, you would see the following error message on top of the login page:

The weird thing is to enter Settings:Passkeys, even when passwords are turned off, you would still need to provide the old password as part of the step up authentication. This means, that even if you turned off passkeys for login, you shouldn’t delete the password entirely from your password manager.

Let’s take a deeper look at the login process.

If you open the login page, the Sign in with passkey button is located on the very bottom of the page. For most users, it feels unusual to click a button on the bottom of the page, when there is a Username / email and password input field on top of the page. This will result in a relatively low passkey adoption and usage rate if the implementation stays like this.

The main issue with the Sign in with passkey button is that if you don’t have a passkey or it’s not available on the current device, it’s pretty complex to understand what’s happening (especially for non-expert users.

Many users that click on the Sign with passkey button will probably cancel the passkey authentication process in the popup and will see the following, rather cryptic error message with no explanation for the root cause:

Assuming you want to login with username / email and password, you would provide these and automatically an SMS OTP would be sent out, even though you might have a passkey available on this device which could be used as another authentication factor. For myGov, this incurs unnecessary costs for the SMS and for the user a non-phishing-resistant second factor is used instead of phishing-resistant passkeys. This shows that the system’s authentication intelligence has still room for improvement.

If we click on the Sign in with passkey button, the passkey login modal pops up:

Here, we used the passkey stored in Windows Hello. Alternatively, we could also use a different passkey via Cross-Device Authentication by clicking on Use a different passkey.

In the following, you’ll see the login process for the native Android app in the screenshots (iOS works the same way). The overview screen for the login looks as follows:

To sign in with a passkey, we click on the Sign in with passkey button which triggers the passkey authentication ceremony. Once we have successfully used our fingerprint scan (on iOS Face ID or Touch ID), we can define a local PIN for quick access:

To speed things up, we can replace the local PIN with local biometrics we can use instead:

To login with a password, a WebView is opened where you can first decide between login with Digital Identity or with myGov sign in details (meaning email and password, which is not 100% clear in our opinion):

We click on Use myGov sign in details and see the following screen, where we provide our email address and password:

After clicking on the Sign in button, an SMS OTP is sent out and should be filled (even though a passkey might be available on this device as phishing-resistant second factor):

After entering the correct SMS OTP, we are logged in.

If you want to login on a macOS device using Safari in clamshell mode, an error is thrown as User Verification is set to true:

Conditional UI login is neither implemented in the web app nor in the native iOS / Android apps. This would also be a very user-friendly way to optimize the passkey take-rate.

Let’s have a brief look at the technical implementation details of myGov’s passkey implementation.

At first, we analyzed myGov’s PublicKeyCredentialCreationOptions. Our review revealed that myGov requires the use of resident keys. It shows clearly that passkeys are favored and hardware security keys which only deal with non-resident keys. However, as described in this blog post, quite often the authenticator itself decides if it wants to use resident or non-resident keys.

Also userVerification is required which shows that users should actively authenticate and attestation direct provides more insights into the used authenticators, mainly the AAGUID.

The Relying Party ID is set to “login.my.gov.au” and so is the Relying Party name. The user.id, user.name and user.displayName are set to rather random and technical values.

{
    "attestation":"direct",
    "authenticatorSelection":{
        "residentKey":"required",
        "userVerification":"required"
    },
    "challenge":"nLkO9f6IoltM3nkWPw107467WjIKl1Lsn__SV2sI0",
    "excludeCredentials":[
        {
            "id":"Qdt0EkiY2xIPybn8PNw",
            "transports":[
                "usb",
                "nfc",
                "ble",
                "hybrid",
                "internal"
            ],
            "type":"public-key"
        },
        {
            "id":"uuS2GvhXxYIgD6PuKdrHguSCTAd8lS-Oy85hLiwg",
            "transports":[
                "usb",
                "nfc",
                "ble",
                "hybrid",
                "internal"
            ],
            "type":"public-key"
        }
    ],
    "pubKeyCredParams":[
        {
            "alg":-7,
            "type":"public-key"
        },
        {
            "alg":-257,
            "type":"public-key"
        }
    ],
    "rp":{
        "id":"login.my.gov.au",
        "name":"login.my.gov.au"
    },
    "user":{
        "displayName":"FP637225",
        "id":"LOLdIYSv-PWStbffAxWw",
        "name":"FP637225"
    }
}

In the analysis of PublicKeyCredentialRequestOptions, the noteworthy element is the use of allowCredentials. Even though passkeys are created for an account, the allowCredentials array remains empty making the CDA use of passkeys from other devices possible.

{
    "allowCredentials": [],
    "challenge": "qxiXKi1T55HUnGg0OAckAMWh9e8UOMktzKOVbJc",
    "rpId": "login.my.gov.au",
    "userVerification": "required"
}

• Get Recognition as Digital Leader: myGov's integration of passkeys marks a big advancement in user-friendly cyber security for public services. By adopting passkeys, myGov sets a precedent for other public and private organizations in Australia. This bold move places myGov at the forefront of cyber security practices, showcasing their dedication to protecting sensitive information while enhancing user experience.
• Ensure Future-Readiness By Adhering To Essential Eight Framework: by Australia's evolving cyber security legislation, such as the updated Essential 8 framework. This framework emphasizes the importance of phishing-resistant MFA, pushing organizations towards more secure authentication methods.
• Avoid Data Breaches My Disabling Passwords and Offering Phishing-Resistant MFA: As passwords can be entirely disabled (a very bold move!), password-based phishing attacks can be avoided and if passkeys become the standard login method for many users, these users are protected from phishing threats.
• Save Millions Per Year on SMS OTP Costs: If passkeys become the preferred MFA method, then we expect a high decline in SMS OTP costs, which we estimate to be in the millions per year for myGov.
• Decrease MFA Recovery Costs: Recovering MFA protected user accounts is among the most user-unfriendly and cost-intensive processes. By pushing for (synced) passkeys, we expect the number of MFA recovery support cases to drop significantly, which could eventually be materialized in further savings for personnel and increase user satisfaction.

Why Are Passkeys Important For Australian Organizations?

Passkeys for Australian Government & Enterprises

The Australian Cyber Security Strategy and Essential Eight framework require organizations to implement phishing-resistant MFA (via passkeys). Our whitepaper provides an overview and shows how to implement passkeys efficiently and what the business impact is.

Download the whitepaper

Work email *

Name *

Company *

Job title *

Get whitepaper

If you have questions, feel free to  

contact us

Even though myGov has shown great courage by being among the first Australian companies (especially in the public sector) to implement passkeys, there is much room for improvement. By following the following recommendations, we expect a much better passkeys UX which will result in boosted adoption and take-rates for passkeys:

• Recommendation 1: Offer passkeys as upsell in the sign-up process
  Passkeys should be actively offered after email OTP, mobile number OTP and / or password setting. This process can be optimized depending on the factors that the user provides and verifies. However, educating users about passkeys and making sure that they can create passkeys from their first interactions with myGov will be a boost for the adoption and usage of passkeys (actively switching to passkeys in the account settings will only be done by a small portion of users).
• Recommendation 2: Use passkeys as Default MFA login method (instead of password + SMS OTP)
  Even if users start to provide their email address / username and then the password, the subsequent MFA method should be passkey-first. This means that the passkey login should be started instead of having SMS OTP as default MFA method (assuming of course that passkeys are available for this user on the current device, which requires a certain level of passkey intelligence).
• Recommendation 3: Go identifier-first passkey approach instead of separate passkey login button
  Having a “Sign in with passkeys” button is the easy way as is does not interfere with the current existing login process. However, our data analysis and experience in working in the field of passkey-based solutions has shown that only very few users actively click on this button, especially if the button is below the fold. Thus, we recommend using an identifier-first approach (only show the username / email address field), get the user to start the login process and then determine individually the best and most secure login method (all while keeping a passkey-first mindset in place).
• Recommendation 4: Implement Conditional UI for native and web apps
  One of the biggest boosters for the usage of passkeys and biggest savors of SMS OTP costs in MFA login processes is the usage of Conditional UI, as the users will be pushed to use passkeys and log in in the most user-friendly way (it’s basically only one click and the user is logged in). More seamless logins are not possible, and this approach will not make your users think, while keeping them MFA-protected. Therefore, this is one of the recommendations which could have with reasonable implementation effort huge impact on passkey usage rate.

If myGov continues to refine its approach by implementing the recommendations, we anticipate that other public organizations in Australia (and around the globe) will follow suit, adopting passkeys as a standard security measure.

In conclusion, myGov's implementation of passkeys represents a forward-thinking approach to improve cyber security in the public sector. While the current implementation shows strong technical foundations, there are several areas where UX can be significantly improved. Promoting passkeys in the sign-up process, making the login process more passkey-focused and adding Conditional UI should help boost user adoption and trust.

As myGov continues to refine its passkey system, it not only secures its own platform but also sets a benchmark for other organizations in Australia. Moreover, the future-readiness is secured as passkey align with the national cyber security strategy and the Essential Eight framework.

We continue to monitor the implementation of passkeys at myGov and keep you posted about any changes.