Practical guides

Manage accounts, permissions and access recovery

Account security covers creation, permitted actions, recovery and closure. A successful sign-in screen does not show that a former collaborator has lost access or that recovery is properly controlled.

Go to the method

Access over time

Define the actions actually required

List actions by role: read an enquiry, draft a page, publish, export or administer. Separate responsibilities where the context permits. Ask each participant to validate normal tasks and actions they should not be able to perform.

Maintain an inventory of team and integration accounts with an owner and purpose. Secrets do not belong in this shared document. The inventory should establish who can act without turning a project spreadsheet into a password store.

Review sign-in and sensitive actions

OWASP covers authentication and associated controls, including attempts, protected transport, recovery and reauthentication for sensitive operations. Use a maintained solution and assess additional protection according to the risk.

Prepare acceptance tests using an authorised account, a restricted role and an expired session. Test a sensitive operation through its direct address as well as its menu. Hiding a button alone does not enforce server-side permissions.

Rehearse recovery using test data

In a test environment, simulate loss of a sign-in method, an expired link and a repeated attempt. Check messages, the recipient and the end of the procedure. Support needs a written method for exceptional cases.

Decide how earlier sessions are revoked and how other access is reviewed after recovery. Do not ask someone to send a secret through an ordinary form as proof of ownership. Review the procedure with the solution’s security owner.

Plan onboarding, departures and handover

Assign owners for creating, reviewing and closing access. A departure may affect the site, hosting, domain, connected services and authorised devices. Emergency access needs control, awareness among authorised staff and a test that does not expose it publicly.

Keep a record of granted and removed permissions and the review date. Repeat representative tasks after a role or software change. This method helps find omissions but does not replace a security assessment suited to the service.

Primary documentation : OWASP — Authentication Cheat Sheet.

Acceptance matrix to adapt to your project

These proposed checks use synthetic cases. Decide the required behaviour with the team, record the result and assign unresolved gaps before release.

Test cases, expected outcomes and useful evidence
CaseExpected outcomeEvidence to retain
Restricted accountThe protected operation remains refused even through its direct address.Account role, attempted request and observed refusal in the test environment.
Expired recoveryAn old link cannot restore access and a new request remains possible.Steps and displayed message, without retaining an actual recovery token.
Contributor leavesAffected access and sessions are revoked under the agreed procedure.Checked tools and outcomes using synthetic accounts with known permissions.
Administrator unavailableThe designated person can understand the planned recovery route.Documented recovery exercise in the test environment, including unresolved gaps.

Frequently asked questions

Is multifactor authentication enough?

It can strengthen sign-in, but permissions, sessions, recovery, integrations and departures still need review. Also test what a restricted account can actually read or change.

What should the next administrator receive?

A list of services, owners, roles, recovery procedures and completed tests. Transfer secrets using the organisation’s secure mechanism, separately from editorial documentation or the project brief.