Customer security goes beyond the login screen

List who may view, create, change and delete each record. Authentication establishes identity; authorisation controls allowed actions. Enforce relevant permissions on the server for each request. Hiding a button does not protect an endpoint or another customer’s records. Give administrative roles only the access needed for their actual responsibilities.

Use established authentication components, secure password handling and appropriate controls against repeated login attempts. Consider multi-factor authentication for privileged users. Recovery needs token expiry, single use and clear session handling. Avoid unnecessarily revealing whether an account exists. Review the recovery path as carefully as the normal login journey.

Use separate test customers and administrative roles. Check that changing an identifier cannot expose somebody else’s order, file or message. Include expired sessions, staff removal and role changes. Keep secrets out of client bundles and logs, and restrict production access to the people who actually need it.

Record useful security events without passwords or sensitive tokens. Decide who reviews alerts and how compromised sessions can be revoked. Keep dependencies maintained and review permissions after changes. Layered controls and verification reduce risk, but finishing a checklist cannot guarantee that a product contains no vulnerabilities.

Two customers may each have a valid login but should not see one another’s orders. Test requests with the other customer’s record identifier and confirm that the server checks ownership or an explicit role permission. The same principle applies to downloads and administrative exports.

Test this with approved test accounts. Do not probe other organisations or use real customer records as a substitute for a controlled security test.

Document what happens when a password is reset, a phone is lost or a staff member leaves. Decide which sessions are revoked and who can restore access. Protect recovery tokens and avoid logging them.

• Check expiry and single-use behaviour.
• Review privileged access separately.
• Keep security notifications understandable.
• Record important access changes without exposing secrets.

Request an access matrix, a record of verified security checks and ownership of monitoring and updates. Distinguish issues that were fixed from limitations that remain. Agree on an incident reporting channel and a process for removing compromised access.

Do not use a checklist or a scan as a guarantee that no vulnerability exists. Security evidence should explain scope, findings and the next review rather than create a false sense of completeness.