Two factor authentication protects a brokerage account by requiring two different kinds of proof when you sign in. A stolen password alone is then insufficient to complete that sign-in. Protect your email first, then cover the accounts that hold client information or let someone act on your behalf.
Use a phishing-resistant method where the service supports it. Keep an approved backup method so a lost phone does not lock the whole brokerage out.
What Two Factor Authentication is
Two-factor authentication, or 2FA, uses exactly two authentication factors. Multi-factor authentication, or MFA, uses two or more. The factors come from different categories.
- Something you know, such as a password.
- Something you have, such as an enrolled phone or physical security key.
- Something you are, such as a fingerprint used to unlock an authenticator.
A password plus an authenticator code combines knowledge with possession. Two passwords both rely on knowledge, so they do not add a different factor. The cyber.gov.au guidance on implementing MFA explains these categories.
MFA does not always mean typing a code into a second screen. A passkey can combine possession of a device with a local PIN or biometric check. Whether a particular passkey implementation meets an MFA requirement depends on how it verifies the user.
Which 2FA Methods Are Strongest
Phishing-resistant passkeys and compatible security keys give stronger protection against fake sign-in pages than codes you type. Authenticator codes remain useful when those methods are unavailable. SMS is a fallback where the account’s rules permit it.
| Method | How you use it | Main limit |
|---|---|---|
| SMS code | Enter a code sent to your enrolled phone number after the password. | Attackers can target the phone number or trick you into giving them the code. |
| Authenticator app | Enter a code generated by the app, or approve a sign-in request. | Codes and ordinary push approvals can still be phished or approved by mistake. |
| Passkey | Unlock an enrolled device or credential with the supported PIN or biometric check. | Device management and recovery still need planning, including who can use a synced credential. |
| Security key | Use a physical key supported by the service, with user verification where required. | The service must support it, and you need a separate recovery method if the key is lost. |
Choose passkeys or security keys that support phishing-resistant authentication. A physical token that only displays a code does not gain that protection simply by being hardware. With phishing-resistant authentication, the credential is bound to the real service instead of producing a code you can hand to a fake website.
The government’s passkey guidance explains how passkeys replace an account password. Lock the devices holding them and protect any account that synchronises them.
Yes, SMS is better than a password alone when it is the available second step. The UK National Cyber Security Centre’s setup guidance supports enabling available protection instead of leaving an account unprotected. SMS still cannot satisfy a policy that requires a stronger method. Use the method your aggregator or lender requires, and prefer phishing-resistant protection for brokerage email and administrator access.
Never approve a sign-in request you did not initiate. If prompts arrive unexpectedly, deny them and report the event to the person managing the account.
Set Up 2FA on Brokerage Accounts
Set up MFA on each person’s own account and require it through the service’s administrative controls where available. Registering an authenticator is only one part of the job. The sign-in policy must also require the protection.
Before changing settings, identify the account administrator and arrange a recovery method they control. Keep another authorised administrator able to sign in during the rollout. Use a device you control and start from the service’s normal website instead of a link in an unexpected email.
Microsoft 365
For a Microsoft 365 work account, use the security settings for your work identity. A personal Microsoft account with the same-looking email address can have different settings.
- Sign in to Microsoft’s Security info page with the work account.
- Select Add sign-in method. Choose Microsoft Authenticator if your organisation permits it, then follow the setup prompts.
- In the phone app, add a Work or school account and scan the QR code shown by the setup page. Keep that QR code private.
- Complete the test requested by Microsoft. Confirm that the new method appears in Security info, then add another approved method for recovery.
- Sign out and test a fresh sign-in. Confirm that you can complete the required verification and reach the work account.
Microsoft’s Authenticator setup instructions cover this registration path. The administrator must separately apply the organisation’s MFA policy. Microsoft documents security defaults and Conditional Access in its Microsoft 365 administrator guide.
If the method is missing from the menu, the administrator’s allowed-method policy can be the reason. Use a permitted method or have the administrator change the policy. Do not create a shared account to bypass it.
Google Accounts and Google Workspace
Turn on protection for the Google account you actually use for brokerage work. Google Workspace can restrict the methods available to staff.
- Open your Google Account settings and select Security & sign-in.
- Under How you sign in to Google, select Turn on 2-Step Verification.
- Follow the prompts to enrol an allowed method. Use a passkey or security key where available, or an approved alternative.
- Set up a separate recovery option. If the account supports backup codes, store them securely away from the phone they replace.
- Confirm that 2-Step Verification is on. Test a fresh sign-in and confirm that you can reach the correct work account.
Google’s 2-Step Verification instructions explain the user settings. A passkey sign-in can complete verification without another code screen. An existing trusted session can also behave differently from a new sign-in, so use the account’s security status as well as the test.
For Google Workspace, the administrator manages rollout under Security, then Authentication, then 2-step verification in the Admin console. Allow staff to enrol, confirm their recovery arrangements and then apply enforcement to the intended users. Google’s Workspace deployment guide explains the distinction between allowing enrolment and enforcing it.
CRM, Aggregator Platforms, Lender Portals and Track My Trail
Protect each route into client information, including accounts outside your email provider. A customer relationship management system, or CRM, may have its own sign-in even when you use a work email address.
- List the CRM, aggregator platform and lender portals each staff member uses. Include their administrator accounts and the identity used for each sign-in.
- Open each account’s security or sign-in settings. Enable the supported MFA method, or have its administrator enrol the user where the provider manages setup.
- Complete the service’s enrolment test and save its approved recovery method. Repeat this for each individual account.
- Test the normal sign-in route and any separate direct-login route. Confirm that the required protection applies to both.
Track My Trail signs you in only through a Google, Microsoft or Facebook account. Turn on two-factor sign-in for the account you use for Track My Trail. That provider’s verification and suspicious-sign-in checks protect the sign-in to Track My Trail too.
If you cannot find an MFA setting, establish whether the platform uses your work identity or manages a separate account. Ask the platform administrator to confirm the enrolment route and required method. Record the result for each account so a protected email login does not hide an unprotected portal.
When Staff Change Phones or Leave
Register and test a replacement authentication method before removing the old one. Offboarding also requires removing access and active sessions, even when the departing person returns their phone.
For a planned phone change, sign in while the old method still works. Add the new phone or credential in the account’s security settings and complete a test sign-in. Then remove the old registration and revoke the old device’s sessions where appropriate. Do not assume restoring a phone backup transfers every work authentication registration.
If the phone is lost, use an enrolled backup method or the administrator’s identity-checked recovery process. Google’s lost-phone guidance lists recovery options including backup codes and another enrolled credential. Never ask a colleague to approve your sign-in under their identity.
To reset MFA, an authorised administrator must verify who is requesting the change and use the service’s recovery or re-registration process. An unexpected request to replace a factor needs the same scrutiny as an unexpected password reset.
Avoid turning off MFA to move phones. If an authorised change requires temporary removal, establish the replacement and recovery route first. Restore the required protection immediately and verify the saved account settings. Organisational rules can prevent a user from disabling MFA themselves.
When a staff member leaves, the administrator must:
- Block the person’s work sign-in and remove their access to each separately managed portal.
- Revoke active sessions and refresh tokens using the controls each service provides. Microsoft’s access-revocation guidance explains why existing sessions need attention.
- Transfer business ownership and recovery contacts before removing credentials that the brokerage still needs.
- Remove the former staff member’s enrolled devices and authentication methods from business-controlled accounts. Rotate shared credentials or recovery material they could retain.
- Confirm that another authorised staff member can access the required business records and that the departing user’s access is blocked.
Keep required client records under the brokerage’s retention process. Closing a user’s access is different from deleting their mailbox or files.
Single Sign-On and Password Managers
Single sign-on, or SSO, lets a work identity authenticate you to connected applications. A password manager stores credentials and fills them into separate sign-in forms. MFA protects access alongside either arrangement.
With SSO, require MFA at the identity provider and confirm that connected applications enforce the intended sign-in route. Microsoft’s SSO explanation describes how the identity provider confirms the user to an application. A separate local-login option still needs protection if it remains available.
A password manager helps a small team use different passwords for services that still need them. Protect the manager itself with MFA and give each staff member their own account. Use business-controlled sharing for credentials that genuinely must be shared.
The government’s password-manager guidance explains using unique passwords without memorising every one. If a vault holds both an account password and its authentication code, access to the vault can expose both. Keep a separate phishing-resistant factor for accounts whose loss would give someone control of the brokerage’s email or user administration.
Assign one person to maintain the account list, recovery arrangements and departure checks. Start with the administrator and email accounts, then work through every CRM and portal until each sign-in has an owner and the required protection.
