What the mobile token is, and why it exists
Every NAB Connect login pairs something you know (your password) with something you have. For years that second thing was a physical token: a small device that displays a changing numeric code. The mobile token moves that job into the NAB Connect app on your phone. The app generates the same kind of one-time, short-lived codes, tied to your personal profile, and you use them the same way — at login when prompted, and again to confirm certain sensitive actions like authorising a payment.
The security logic is unchanged. A code is valid briefly and once; it is generated from a secret registered to you, not transmitted by SMS, which is why the mobile token is meaningfully stronger than text-message codes — there is no message to intercept, divert or SIM-swap. Whoever holds your password but not your phone still cannot get in; whoever holds your phone but not your password is equally stuck, provided your phone itself is locked. That last clause matters, and this guide will return to it: the mobile token quietly makes your phone's own lock screen part of your business's banking security.
Whether you use the mobile token or a physical one is usually decided by your business's setup — some organisations standardise on one, some issue physical tokens to some roles and the app to others. If you have a choice, the comparison section below lays out the genuine trade-offs. Either way, the token is registered to you: codes from a colleague's token or app will never work for your login, and yours will never work for theirs. If you are setting up access for the first time, our first-time login guide shows where token registration fits in the sequence.
A mobile token code: six digits, generated on your phone, alive for a short window and dead after one use.
Activating the mobile token, step by step
Activation links the app on your specific phone to your personal NAB Connect profile. Do it on your own phone, on a connection you trust, with your User ID and password handy and your administrator aware — in many setups an administrator enables the mobile token option on your profile before the app will let you register it.
- Confirm your profile allows it
Ask your administrator whether the mobile token is enabled for your user, or whether your business issues physical tokens instead. Discovering at step four that your setup expects a plastic device wastes everyone's afternoon.
- Install the genuine app
Download the NAB Connect app from your phone's official app store, checking the publisher is the bank and the app name matches. Never install a banking app from a link in a message or a third-party store — counterfeit apps exist precisely for this moment. Our app login guide covers safe installation in more detail.
- Sign in to the app with your NAB Connect credentials
Use the same User ID and password as the desktop login — our guides to your User ID and password help if either is shaky. The app may ask for a code from your existing token during this first registration if you already have one; that is the old factor vouching for the new one.
- Enable the token feature and complete registration
Follow the in-app token setup sequence to the end — do not abandon it halfway, because a half-registered token is a classic source of "codes don't work" reports. Registration binds the app's code generator to your profile; from this point, this phone is a security device.
- Set a strong phone lock and app protections
Before you generate a single banking code: a proper PIN or biometric lock on the phone itself, automatic locking after a short idle period, and any in-app security options switched on. An unlocked phone with an active token is one factor pretending to be two.
- Test with an actual login
Sign out everywhere, then do a complete desktop login using a code from the app. Only when that full chain works — User ID, password, app code — is activation genuinely finished. Test now, not at the next payment deadline.
Activation is only complete when a full test login with an app code succeeds.
Using the mobile token day to day: logins and approvals
At login. The desktop sign-in asks for a token code after your User ID and password. Open the app, let it generate a fresh code, and type it in promptly. The discipline is in the timing: generate the code when the prompt is on screen, not in advance "to save time", because codes expire on a short cycle and an early-generated code is the leading cause of mysterious rejections. If a code is rejected, do not retype the same digits harder — wait for or generate the next fresh code and enter that. Our complete login guide sets this within the full routine.
For approvals. Sensitive actions — authorising payments is the everyday example — can demand a token code even though you are already signed in. This step-up check is deliberate: it proves the person approving is, at that moment, in possession of the registered phone, not merely someone who found an unattended signed-in session. When an approval asks for a code, pause and do the approver's real work first: read the payment — payee, amount, date — before reaching for the phone. The code confirms a decision; it should never be a substitute for making one. If you are the person who prepared the payment as well, the re-read matters doubly.
Habits that keep codes working. Keep your phone's date and time set automatically by the network — code generators depend on accurate time, and a manually skewed clock is a quiet saboteur. Keep the app updated, because token functions are exactly the parts that security updates touch. And never generate codes on demand for anyone else, or enter a code because someone on the phone says the bank needs it: codes go into the login screen and the approval screen, and nowhere else in the universe.
When the app and the desktop disagree. Occasionally the app will be signed in happily while the desktop session has timed out, or vice versa. They are related but separate sessions. Treat each on its own terms: sign in again where you were signed out, generate a fresh code for the new prompt, and carry on — no setting needs adjusting because two sessions behaved independently.
Replacing a lost, broken or upgraded phone — the correct order
Because the mobile token lives on a specific device, changing phones is a security event, not an IT errand. The order of operations matters, and it differs depending on whether the old phone is in your hand or gone.
If you still have the old phone (planned upgrade). This is the easy path. Tell your administrator in advance, install the genuine app on the new phone, and follow the registration process — in many setups the existing token or your administrator's action vouches for the move. Complete a test login with the new phone before wiping or trading in the old one. Only once the new phone demonstrably works should the old app's access be removed; then wipe or factory-reset the old device if it is leaving your control. Never leave a live token registered on a phone that now belongs to a shop, a sibling or a stranger.
If the phone is lost or stolen. Speed matters more than sequence here.
- Contact your administrator immediately
Tell them the registered phone is gone so the token can be suspended or deregistered from your profile. After hours, the bank's official contact channels are the fallback. Treat this with the same urgency as a lost physical token or a lost office key — because functionally, that is what it is.
- Use your phone account's remote tools
Locate, lock and if necessary erase the device through your Apple or Google account from another device. A locked phone buys time; an erased phone ends the story. Also change the password of the email account on the phone if you cannot lock it, since email access can be a stepping stone to other resets.
- Arrange interim access
If you must keep working, your administrator can advise on alternatives — a physical token, for instance — rather than improvisation. What you must never do is register your token on a colleague's phone or borrow their codes "for a few days". Shared factors are not factors.
- Register the replacement phone and test
When the new phone arrives, run the full activation from the earlier section, finish with a complete test login, and confirm with your administrator that the old registration is dead. Then update your records: which phone holds your token is a fact your business's register should reflect.
If the phone is broken but in your possession. You hold the hardware, so the risk is lower, but the registration is still trapped inside it. Administrator first, deregister what can be deregistered, register the replacement, test, and only then send the broken device for repair or recycling — ideally after a factory reset if it powers on at all.
Mobile token vs physical token: an honest comparison
| Factor | Mobile token (in the app) | Physical token |
|---|---|---|
| What you carry | Your phone — already with you | A separate small device — one more thing to track |
| If it is lost | Phone lock protects it; remote erase available; admin deregisters | No lock on the device itself; codes visible to whoever holds it — but useless without your password; admin deregisters |
| Failure modes | Flat battery, broken phone, app problems, phone replacement process | Device battery dies after years, device lost or left at home/office |
| Time accuracy | Depends on the phone's clock being automatic | Internal clock can drift over years until codes stop matching |
| Sharing temptation | Low — nobody lends their phone casually | Higher — "just take my token" is a sentence said in real offices, and should not be |
| Best for | People who live on their phone and travel between sites | People who want banking security independent of a personal phone, or shared-desk environments |
Two objects, one job: producing a code that proves the registered person is present.
Neither is "the secure one" in the abstract — both deliver a genuine second factor, and both fail in human hands when codes are shared or devices are lent. Choose the one whose failure modes your working life tolerates best, and if your business offers a choice per role, approvers who travel usually thrive with the mobile token while desk-based staff often prefer the physical device's simplicity.
When mobile token codes are rejected
Work this list in order; it resolves the overwhelming majority of cases.
- Stale code. You generated it, got distracted, entered it late. Generate a fresh one and enter it immediately. This is the cause so often it deserves its own line in every guide on this site.
- Wrong code source. A code from a personal banking app, a different bank's app, or a colleague's token. Codes are personal and service-specific; confirm you are reading the NAB Connect app's current code.
- Phone clock drift. If your phone's time is set manually and has wandered, generated codes will not match the server's expectation. Switch date and time to automatic and try a fresh code.
- Outdated app. Update the app from the official store, restart it, and retry. Token functions are security-critical and old versions age badly.
- Re-registration needed. After phone changes, major updates or long disuse, the registration itself may need to be refreshed by your administrator. If fresh codes consistently fail despite the steps above, stop burning login attempts — repeated failures risk a lockout — and escalate with specifics: what the app shows, when it last worked, what changed.
And the meta-rule from our password reset guide applies here too: failed attempts are a finite resource. Two careful failures are information; five are a lockout in progress.
One diagnostic habit separates quick fixes from long sagas: change one thing at a time and write down what the app showed before and after. "Codes rejected since Tuesday, phone updated Monday night, clock was on manual" is a story your administrator can solve in one exchange. "Codes don't work" starts a correspondence. Businesses run better when their people report symptoms like technicians — what changed, when it last worked, exactly what the screen said — and token problems, being equal parts device, app and account, reward that precision more than most. Keep the notes in the same place you keep your administrator's contact details, and the next incident, whenever it comes, starts halfway to solved.
Everyday scenarios the token has to survive
The flat battery at the worst moment. It is 4:55pm, a payment needs your approval, and your phone is at 2%. Sequence matters: open the app first and generate what you need before experimenting with anything else, plug the phone in immediately, and complete the approval in one calm pass rather than three panicked ones. If the phone dies mid-approval, nothing is half-sent — an approval either completes with its code or it does not — so recharge, sign in again, and check the payment's status before assuming anything about it. And take the hint: approvers who are single points of failure for payroll should keep a charger where they work. The sophisticated version of this conversation is the understudy conversation — a second trained approver — which your administrator would love you to start.
No reception, no Wi-Fi. Token codes are generated on the phone from its registration and clock, so a code can usually be produced in a coverage dead zone and typed into a desktop that does have a connection. What you cannot do offline is sign in to the app itself or receive new work. If you regularly travel through dead zones with approvals pending, clear the queue before you leave coverage rather than relying on a generated code surviving the journey — codes are short-lived by design, so generate them at the moment of use, wherever you are.
The shared-desk shuffle. In offices where desks and computers are shared, the phone-based token has a quiet advantage: the second factor walks away in your pocket when you do, unlike a physical token left in a shared drawer. It only works if the habit is complete — your phone with you, the desktop signed out, every time. The technology assumes the routine; the routine is yours.
The new-phone Friday. Phones get replaced at weekends and tokens get forgotten until Monday's first login. If you are planning a phone change, run the replacement process from the previous section during the working week while your administrator is reachable and the old phone still works. The fifteen minutes of foresight converts the classic Monday lockout story into a non-event — and if you are reading this on a Monday with a dead old phone, the same section is written for you too, in the order you need it.
Related guides
Mobile token questions
Is the mobile token as safe as a physical token?
Yes, when the phone itself is properly locked. Both generate the same kind of one-time, short-lived codes tied to your profile. The mobile token's extra consideration is that your phone's lock screen becomes part of the security chain — a well-locked phone is a strong token, an unlocked phone left on a desk is a weakened one.
Can I have the mobile token on two phones at once?
Treat the answer as no for planning purposes: your token is registered to a specific device, and moving it means registering the new phone and retiring the old one. Running your business banking factor on multiple personal devices widens the risk without any real convenience gain. Your administrator can confirm your business's exact arrangement.
My codes keep getting rejected even though I type them correctly. What breaks?
Usually one of three things: the code expired before you submitted it, your phone's clock has drifted from automatic time, or the app registration needs refreshing. Generate a fresh code and enter it instantly; check the time setting; update the app. If all three are right and codes still fail, stop attempting and escalate to your administrator before a lockout joins the problem.
I lost my phone overseas. What is the very first thing to do?
Get word to your administrator — by any channel, from any device — so the token registration can be suspended, and use your phone account's remote locate/lock/erase tools as soon as you can get online. Time zones and holidays do not change the priority: a registered token on a missing phone is treated like a lost key, anywhere on Earth.
Does the mobile token work without internet on my phone?
Code generation itself is time-based and generally works without a connection, since it derives codes from the registration and the clock rather than fetching them. Anything in the app beyond code generation — signing in, viewing accounts, approving in-app — does need connectivity. If in doubt while travelling, test your setup before you depend on it.
A caller said they were from the bank and needed me to generate a code and read it to them. Is that ever legitimate?
Never. Codes prove your presence to the system at the login or approval screen; no person ever needs one spoken aloud. That request is the signature move of a takeover attempt. End the call, and report it to the bank through the number on its official website and to your administrator.