Users And Role-Based Access Control

The Access Control page on SHA is where you manage who can sign in and what they are allowed to see and change. Access is role-based: you create roles, give each role a set of permissions, and assign each user a role. Users inherit whatever their assigned role grants - nothing is granted per user directly.

Permissions are grouped by product area, and each area offers read access, write access, or both. Read lets a user view that part of the GUI; write lets them make changes there. This applies to the Access Control page itself: a user whose role includes only read access to user management sees the full page - users, roles, and the complete permission matrix - but every control that would change something is disabled.

Users sign in with an email address and password. There is no second-factor (MFA) option for GUI sign-in. Some sensitive operations elsewhere in the product ask the signed-in user to re-enter their password before proceeding, but this is a confirmation step, not a second factor.

One role ships with the product: the administrator role, which holds every permission. The account created during initial appliance setup is assigned this role. There are no built-in operator or viewer roles - for narrower duties, create a custom role and enable only the permissions that job needs.

New roles start with an empty permission set. After creating a role, open its permission matrix and switch on the read and write permissions it should carry; each toggle saves as you flip it. Deleting a custom role is permanent and cannot be undone.

The administrator role's permission matrix is fully editable, just like a custom role's. Treat it with the same care you would give a production firewall rule: removing user-management rights from the only role that has them locks everyone out of the Access Control page.

Each area below appears as a row in the permission matrix, with read and write toggles where both apply.

Create a user by entering an email address, a password, an optional full name, and the role the account should hold. New accounts are active immediately. Sendense does not enforce a password policy - any non-empty password is accepted - so apply your organization's password standards when choosing passwords. Passwords are stored only as one-way hashes and cannot be read back.

You can later change a user's full name, reset their password, change their assigned role, and change their status. An email address cannot be changed after the account is created; to move someone to a new address, create a new account and delete the old one.

To revoke someone's access, set their status to Disabled. Any status other than Active blocks new sign-ins; use Disabled for deliberate revocation, since Locked is normally applied automatically after repeated failed sign-ins and clears itself when the lock expires. Deleting a user also ends their access, but deletion is permanent - there is no undo and no recycle bin - so prefer Disabled when there is any chance the account will be needed again, including for audit review.

Signed-in users hold a short-lived session credential that renews automatically in the background. Its lifetime defaults to 15 minutes and can be adjusted in appliance settings. Because a session carries the permissions it was issued with, changes you make on the Access Control page are not instant for users who are already signed in.

Role and permission changes take effect at the user's next session refresh or sign-in - by default within about 15 minutes. Disabling or deleting a user prevents their session from renewing, but a session credential that was already issued remains valid until it expires - again, up to about 15 minutes by default. Plan for this window when removing access from someone urgently.

Five consecutive failed sign-in attempts lock an account for 15 minutes; the account unlocks automatically afterward, and the lock is visible as a Locked status badge on the user's row.

Every sign-in, failed sign-in attempt, and sign-out is recorded in the security audit trail, along with every change made on the Access Control page: users created, updated, or deleted, passwords changed, roles assigned, and role permissions edited. Each record captures who performed the action, what it affected, and the source address it came from.

The audit trail is readable through the reporting surface by any user whose role includes the audit read permission, giving you an independent record of access changes even after the accounts involved are gone.