Business banking MFA and device security: protect the second factor as carefully as the password

Multi-factor authentication makes business banking safer because a stolen password alone should not be enough to access the account. The protection weakens if the second factor is shared, left on an unlocked phone or recoverable through a compromised email account, so the device and recovery process need their own controls.

Use a second factor independent from the password

Banks can use mobile-app approval, hardware tokens, security keys or one-time codes. The purpose is to require something beyond the user's password.

A second password stored in the same browser is not meaningful multi-factor protection.

Protect the mobile device used for approval

Require screen lock, operating-system updates and remote wipe on company phones used for banking. Avoid rooted or unsupported devices.

If personal phones are permitted, define minimum security and the process for removing banking access when the employee leaves.

Teach users not to approve unexpected prompts

Attackers with a stolen password can trigger repeated push notifications hoping the user approves one through fatigue.

Users should deny unrecognised prompts and report them immediately rather than assuming the bank app is malfunctioning.

SMS codes can be exposed to SIM-swap or phone compromise

Where stronger app or hardware authentication is available, higher-risk finance users can benefit from methods less dependent on mobile-network control.

Keep mobile-provider account security strong as well. A bank's MFA can be undermined if an attacker takes over the phone number.

Do not share hardware tokens or approval phones

Shared devices weaken auditability because the bank cannot reliably know which employee approved the payment.

Assign tokens to named users and store emergency devices securely with controlled checkout records.

Secure the process for replacing lost devices

Account recovery can be the weakest link. Banks can require administrator approval, identity checks or telephone verification before a new device is enrolled.

Review administrator accounts and recovery email addresses regularly. An attacker who controls the reset channel can bypass strong daily authentication.

Worked example: a finance manager receives ten unexpected banking-app approval prompts late at night. The correct response is to deny them, contact the bank through an official number and change credentials. Approving one to stop the alerts can give an attacker the second factor needed to access the account.

Keep device replacement records. When a phone is upgraded, confirm the old banking token is revoked rather than leaving two active devices indefinitely.

Use stronger authentication for administrators and high-limit approvers than for view-only users where the bank supports role-based security. Risk should influence the authentication design.

Worked example: a CFO uses one company phone for bank approvals and loses it during travel. The response should include remote device lock, bank-token revocation and confirmation that no backup approval device was also stored in the same bag. Replacing the handset alone is not enough if the old banking session remains valid.

Keep a register of which bank users use app approval, hardware token or SMS. This helps security prioritise stronger methods for users with the highest payment authority.

Use mobile-device management for company-owned approval phones where practical. Enforced updates, encryption and remote wipe reduce reliance on each employee remembering to configure security correctly.

Test recovery controls with the bank before an emergency. Finance should know what identity documents, administrators or telephone checks are required to enrol a replacement device so payroll is not delayed after a lost token.

Protect backup codes and recovery keys offline. Storing them in the same password manager or device used for daily banking can collapse two security factors into one compromise.

For hardware tokens, keep serial numbers and assigned users in the access register. Lost devices should be revoked at the bank even if nobody has seen suspicious transactions yet.

Separate bank-approval devices from general shared office tablets where possible. A dedicated or tightly managed device has fewer installed apps, browser sessions and users, reducing the number of ways banking authentication can be exposed.

Review device posture after operating-system changes. A banking app can remain installed on a device that is no longer receiving security patches, so annual hardware replacement policy can be part of financial access control rather than only IT asset management.

Do not approve banking prompts while on unsolicited phone calls claiming to be from the bank. Genuine fraud teams should not require a user to approve a payment or login to prove identity. Staff should end the call and contact the bank through a known official number.

For travel, plan how high-limit approvers will authenticate abroad. Roaming, lost phones and unfamiliar networks can disrupt access, so approved backup methods should exist before a critical payment deadline.