Sensitive actions and administrator security

Prerequisites and authority

Use an individual staff account with the action permission and required organization module/license. Viewing a menu does not establish permission to mutate records.

Protect sensitive actions

Sensitive actions can affect customer access, financial history, staff authority or router credentials. Read the target and consequence before accepting a confirmation or secondary authentication challenge.

Use an individual account, a strong password and the supported security controls. Keep recovery material separate from routine operational access. Do not share a one-time security code with another operator or place it in an incident report.

For each protected action:

1. Confirm the intended record and scope.
2. Check the reason and related records.
3. Complete the required challenge on your own session.
4. Apply the action once.
5. Inspect its result and audit event.

Treat customer deletion, administrator deactivation or password reset, role deletion, router deletion and router-account password reset as sensitive actions. Require the appropriate permissions and complete any step-up challenge requested by the application. Do not infer that every action has the same confirmation policy merely because another action requested 2FA.

Use Login Sessions to investigate unfamiliar access and the supported revocation workflow to remove it. Changing a password may not revoke every existing session unless the release explicitly does so. Check that result.

When a security challenge fails, stop and investigate configuration or account recovery. Do not bypass the interface with direct database changes.

Related guides

Related guides: Staff accounts, roles and permissions, Administrative session and audit investigation, System operations and task controls, Roles and permission matrix.