FAQ

By design. The umbrella setting module_security is seeded on and locked (can_disable = false), so the safety tools — unlocking accounts, ending sessions, closing offsite windows — are always available. You can still hide two of the three tools individually with the module_offsite_access and module_access sub-toggles. See Administration → Enablement.

No — it's the tooling on top of the protection. The actual protection (authentication guards, the request middleware pipeline, the Roles/permissions RBAC editor, and the audit log) lives in ERPat core and runs whether or not you ever open these screens. This module gives you the admin levers those controls need. See the boundary table on Home.

Yes. The three tools were relocated from core into this module with their permission keys unchanged, and the four tables already ship in the base install, so no data migration was needed. Existing grants keep resolving.

Check three things: (1) the grant's date window covers today; (2) you granted it to the right person (the save creates one row per selected user); (3) an office-IP restriction is actually being enforced — an offsite grant is an exception to the core IP whitelist, so if no restriction is configured there's nothing to relax. Also confirm the grant wasn't revoked.

Many — one grant row per staff member resolved from your selection. Editing a grant, by contrast, changes a single row. Revoke each row individually when the need ends (or set a short end date so they lapse on their own).

It needs both the offsite_access permission and the module_offsite_access sub-toggle switched on. Check the toggle in Manage Modules and the permission in Roles.

Security → Locked Accounts, find the person on the Browse tab, and choose Clear Attempts from the row actions. That resets the failed-attempt counter and re-enables login immediately. Use Reset Password too if they've forgotten it.

On the Active Sessions tab, find the user and choose Logout All Devices. That terminates every live session at once. To end just one specific session, use View Sessions and terminate the individual entry.

The Locked Accounts page opens for holders of either the locked_accounts permission or the core staff_support permit — so a support role can rescue lockouts without being granted the other Security tools.

ERPat generates them automatically when you save a new device — an API key (UUID) and a hashed API secret. View the key via the key icon on the device row; rotate the secret with Generate new secret. The secret is stored hashed and is never shown or logged in clear text.

Rotate the secret immediately (Generate new secret) or delete the device. Rotation is recorded as a critical audit event and invalidates the old secret, so update the physical device with the new value afterwards.

The staff members allowed through that device — stored on the device record. The device row shows a count of passes; open it to see the members list.

It needs the access_logs permission and the module_access sub-toggle on. That one permission governs the whole page — Logs, Devices, and Categories.

Yes — every grant/revoke, unlock, session termination, and device add/rotate/delete writes a row to the tenant's own system audit log under the Security category. See the full event list on Reference → Audit-log events.

No. Creating a device or rotating its secret logs the event and which device, but never the secret value itself.