Sign-in protection & audit trail
Account lockout
Section titled “Account lockout”Five failed password attempts lock an account for fifteen minutes.
There is a second sign-in surface with different behaviour, and the difference is deliberate:
Two-step verification (2FA)
Section titled “Two-step verification (2FA)”Available per user. Anyone with a CIQRA sign-in can enable two-step verification on their own account.
There is no store-level policy that makes it mandatory for a whole team. A store owner cannot currently require 2FA of every staff member; each person switches it on for themselves. That policy does not exist in 1.0, and we would rather write that plainly than let “2FA supported” imply enforcement.
What is recorded
Section titled “What is recorded”The honest answer has two halves, and both belong in the same sentence: CIQRA’s own operator console records sign-in activity in full, and the merchant admin does not.
| Surface | Recorded |
|---|---|
| CIQRA operator console | Yes — failed sign-in (unknown address), failed sign-in (wrong password), blocked sign-in (suspended), successful sign-in, and sign-out, each with the actor and the originating IP address |
| Merchant admin | No — sign-in and sign-out on the merchant-facing admin do not produce audit events |
The second row is a deliberate exclusion, not an omission. The identity and token paths are kept out of the audit middleware on purpose, so that the component which records events never sits in the path that handles credentials.
What this page does not say
Section titled “What this page does not say”- It does not claim tenant-level enforced 2FA. It does not exist.
- It does not claim merchant-admin sign-in auditing. It is excluded by design, and naming the design does not turn the gap into a feature.