Start with the threat model
List what could go wrong before choosing a library: screenshots can be shared, tokens can be replayed, staff accounts can be over-privileged, and logs can collect more personal data than intended.
Turn those risks into testable controls. Expiry, single-use rules, rate limits and role checks should be enforced by the server rather than trusted to the scanning device.
Use opaque, short-lived tokens
Avoid embedding a name, email address or permission set in the visible QR payload. An opaque random token limits disclosure and lets the server revoke access without changing the physical code format.
Sign or securely store token state, compare it safely, and record the reason for rejection. Error messages shown to visitors can stay simple while authorised support staff receive a traceable diagnostic.
Design the audit trail for support
An audit trail should answer who attempted what, when, against which policy version and with what result. It should not become an excuse to retain unnecessary personal data indefinitely.
Define retention, access and export rules early. Good operational tooling turns failed scans into actionable categories instead of an undifferentiated error count.
Plan for unreliable connections
Offline access decisions are a policy choice, not merely a caching technique. If revocation must take effect immediately, the system needs online authorisation or a tightly bounded offline window.
Make the degraded state visible and document recovery steps. Supportable systems fail clearly and protect the user from unknowingly relying on stale permissions.
Related projects
See how these ideas shape the QR Facility Access Management System case study.