The consequences of a credential change.
Changing a password or authenticator can change who controls an account. On a payments platform, that deserves a stronger check than the presence of a signed-in session. The person making the change must provide the proof required for that action.
We enforce that decision on the server. A settings screen cannot control every route by which a request reaches the application, so its underlying endpoints need their own protection.
Fresh proof, enforced at the operation.
Our CairnPay change dated 27 July 2026 requires the current password before a password change. When two-factor authentication is enabled, it also requires a fresh authenticator code. The server request hook blocks direct mutations to protected password and authenticator endpoints.
These checks put account control at the point where credentials change. A request cannot rely on the interface having checked something earlier or on a session alone to authorize a protected mutation.
Test what the server refuses.
Integration and end-to-end coverage exercises email step-up and rejection of password changes without fresh proof. It also covers authenticator enrolment, replay handling and single-use backup codes. Request-hook tests check that direct credential mutations are denied.
A successful settings flow shows that the owner can make an authorized change. The rejection cases establish the other half of the requirement: the server must refuse the operation when the required evidence is missing.