How are authentication methods chosen for different user risks?

Authentication methods should be selected by matching the strength and characteristics of the sign-in control to the consequences of account compromise. The decision normally considers what the user can reach, how attractive the account is to an attacker, the sensitivity of the data involved, the trustworthiness of the device and location, and how reliably the method can be managed throughout its lifecycle.

Risk is assessed by looking at the complete access scenario, rather than by assigning one method to every employee. A standard user accessing routine business applications presents a different risk from an administrator changing security settings, a finance user approving payments, or a supplier accessing a restricted system. The same person may therefore use different authentication requirements for different applications or actions.

• Account privilege: Accounts that can create users, alter configurations, access backups or change security controls require greater assurance than accounts with limited permissions.
• Information sensitivity: Personal data, financial records, confidential intellectual property and operational systems may justify stronger authentication than general collaboration tools.
• Likelihood of attack: Publicly exposed services, frequently targeted roles and accounts used for remote access may face more attempted compromise.
• Device and session context: A managed device with current security controls may provide more confidence than an unknown or unmanaged device.
• Operational impact: Authentication requirements should reflect the harm that could result from misuse, while allowing legitimate work to continue safely.

Passwords alone are generally suitable only for lower-consequence situations where additional safeguards reduce the remaining exposure. Passwords can be guessed, reused after a separate breach, captured by phishing or exposed through poor storage practices. Where they remain in use, organisations should require individual accounts, strong password handling, protection against repeated guessing and a process for dealing with compromised credentials. Password managers can help users create and store unique passwords, but they do not remove the need for stronger controls on important accounts.

An additional factor increases assurance by requiring something beyond the password. Authenticator applications that generate time-based codes are commonly used because they are relatively straightforward to deploy and do not depend on text messages reaching a particular phone. Push approvals can be convenient, but they need controls against repeated fraudulent prompts, such as number matching, clear sign-in information and user reporting routes. Text-message codes provide some protection against password-only compromise, but they are more exposed to risks such as phone-number takeover, message interception and social engineering. They should not normally be the preferred control for highly privileged or highly sensitive access where a stronger option is practical.

Phishing-resistant methods are more appropriate where stolen credentials could cause significant harm. Security keys and passkey-based methods use cryptographic credentials that are bound to the legitimate sign-in process, making them substantially harder for an attacker to capture through a deceptive website. They are particularly relevant to administrators, users handling sensitive information, remote access users and individuals who can approve consequential transactions. Device-based certificates can also support strong authentication where the organisation manages the relevant devices and certificate lifecycle carefully.

Biometrics may improve convenience and help confirm that the authorised person is using a device, but they should be understood correctly. In most business implementations, a fingerprint or facial match unlocks a cryptographic credential stored on the device; it is not usually transmitted as the primary secret to each application. Organisations still need a secure alternative for enrolment, device replacement and recovery, and must consider privacy, accessibility and the possibility that a user cannot use the biometric method in every situation.

Risk-based authentication adds context to the initial sign-in decision. Signals can include a new device, an unfamiliar location, an unusual travel pattern, an anonymised network, a change in behaviour or an attempt to access an application that the user does not normally use. A low-risk session may proceed with the user’s normal method, while a higher-risk event can trigger step-up verification, restrict the session or require a security team review. These signals should support a defined policy rather than become an unexplained automated verdict, because legitimate travel, changed working patterns and shared business locations can produce misleading alerts.

Authentication strength should also reflect the action being performed. A user who has already signed in may still need to authenticate again before exporting sensitive data, changing a payment destination, adding an administrator or modifying a security policy. This is known as reauthentication or transaction-level verification. It limits the damage caused by an unattended session or a session that has been taken over after the original sign-in.

Selection is only part of the decision. Each method should be reviewed for:

• Enrolment: how the organisation confirms a person’s identity before issuing the credential or registering a device;
• Recovery: how access is restored if a device is lost, a credential is forgotten or a user is locked out, without creating an easier route for an attacker;
• Revocation: how credentials, sessions and trusted devices are disabled when a user leaves, changes role or reports compromise;
• Resilience: whether the method remains usable during device failure, connectivity problems or loss of a secondary factor;
• Accessibility: whether all legitimate users can use the method without unsafe workarounds;
• Auditability: whether sign-in events, challenges, failures and policy decisions are recorded sufficiently for investigation.

Organisations should document an authentication policy that maps user groups and access types to an assurance level. For example, ordinary application access might require a password with an authenticator-based factor, while administrative access could require a phishing-resistant credential from a managed device and renewed verification for sensitive changes. Exceptions should have a named owner, a reason, an expiry or review date, and compensating controls. Permanent exceptions gradually become an unexamined weakness.

The chosen methods should be tested against real user journeys, including onboarding, role changes, lost devices, contractor access and account recovery. Monitoring should then examine failed attempts, unusual factor changes, repeated recovery requests and authentication from unexpected contexts. This helps confirm that the control is not merely present, but is operating as intended.

For small and medium-sized organisations, a proportionate approach is usually more sustainable than deploying a different process for every individual. Establishing a small number of risk tiers, standardising the strongest practical method for privileged access and reviewing exceptions regularly can provide a clear basis for secure access decisions. S2 Technology Group can help businesses assess these requirements as part of wider identity and access security planning, alongside user access, devices and cloud systems.