Authentication and Authorisation in Digital Channels

Identity assurance, sessions, entitlements and secure recovery

Different questions require different evidence

Identity proofing establishes relevant identity evidence. Authentication demonstrates control of an accepted authenticator. Authorisation decides whether the actor may perform a particular action on a resource. None alone proves that a customer understood the payment purpose or was not being deceived.

Define assurance and permissions for the actual product and action. Viewing a balance, adding a delegate and approving payroll can require different controls. A valid login does not automatically confer authority over every account or resource.

Factors and passkeys

Knowledge, possession and inherence describe different factor types. A fingerprint is not a secret in the same sense as a password. In common platform-authenticator designs, a local biometric or PIN unlocks use of a private key; that does not justify saying every biometric implementation always keeps data on the device.

NIST SP 800-63B-4 provides scoped digital-authentication guidance, including authenticator assurance and phishing resistance. WebAuthn/FIDO credentials use public-key authentication bound to the relying-party context. Passkeys may be device-bound or syncable; passkey is not a synonym for a key that always syncs.

Sync and account recovery need appropriate assessment. Compromise of a cloud account does not automatically reveal every protected private key in all implementations. Attestation, backup state and device binding also vary; do not promise that every bank receives separate trusted attestation for each device using a synced credential.

Sessions are a separate security object

A successful passkey login does not automatically derive the subsequent session token from the private key or make session replay cryptographically impossible. Cookie and token protection, transport security, expiry, refresh behaviour and any sender-constraining mechanisms need their actual design and threat model.

Use relevant server-side checks and controlled lifetimes. A changed IP or approximate geolocation is a signal, not certain proof of physical travel or compromise. Legitimate networks, proxies and shared devices can change the observed context. Re-authentication is useful but does not guarantee an attacker with compromised authenticators cannot proceed.

Define logout, credential change and incident revocation scope. Stateless access tokens can remain usable until expiry unless checked against relevant state or another revocation mechanism. Set and test acceptable enforcement behaviour for each action; do not treat instantaneous worldwide revocation as a built-in property of every architecture.

Enforce resource and action permissions

Check account ownership or mandate, action, amount, channel and relevant restrictions at the enforcement point. The UI hiding a button is insufficient. Administrative rights, preparation, approval and viewing are distinct. Approval obligations and dual control depend on the actual mandate and framework.

Record important entitlement and policy versions, decision facts and references. Changes should be effective for relevant subsequent actions, with cache propagation and uncertainty handled appropriately. No universal fraud-score threshold or fixed seconds target can be supplied for all institutions.

Recovery and emergency access

Recovery can replace an authenticator and therefore needs strong controls, evidence and usable legitimate routes. Using several channels controlled by the same compromised account may not provide independent assurance. Avoid relying only on suspiciously changed contact details.

Emergency access remains an authorised exceptional process, not an unlimited bypass of legal powers or every account restriction. Apply proportionate least privilege, justification, time bounds, approval and review under the institution's policy. A court order or deceased-customer case does not automatically permit all operators to bypass controls.

Fictional example: revoked signatory

A firm removes a signatory's payment authority. The signatory still has an authenticated session but attempts approval after the change is effective. The payment service checks the current relevant authority and declines or refers under its policy rather than trusting the old session's existence.

The case retains the mandate change, enforcement decision and attempted instruction. Authentication remained valid; authority for that action did not.

Takeaway

Authentication, sessions and action authority need separate controls and evidence. Recovery and emergency processes should preserve those boundaries rather than silently defeating them.