By Quokka Advisory
Access design needs to survive a role change, a lost device and an unavailable identity service. Work through those conditions while designing the service, with the people who will support it. They need to understand how to remove access and how to recover when the normal path fails.
At Quokka, we consider identity alongside the network and platform controls that make the decision enforceable. Multi-factor authentication is part of that design. Application permissions, session behaviour and recovery need the same attention through implementation.
Use a specific transaction to review the design. Reading a payroll record, exporting employee data or changing payment details gives the team a concrete action to trace across its access layers.
Establish the authentication evidence
Prioritise phishing-resistant methods for privileged and sensitive access. Examples include FIDO2 or WebAuthn authenticators with user verification and suitable public key infrastructure smart cards with PIN activation.
NIST SP 800-63B-4 explains the distinction between authenticator properties. A biometric match alone does not provide MFA; it can activate a physical cryptographic authenticator. Manually entered one-time codes do not provide phishing resistance.
Document enrolment, authenticator replacement and account recovery alongside normal sign-in. Test whether someone can use a weaker recovery route to regain access without the intended assurance. Assign an owner to exceptions and review their continued need.
Check permission where the action is understood
An identity-aware gateway may know the person, their device and the target application. The application has more specific information about the requested object and business action.
Enforce those permissions in trusted server-side logic. OWASP's authorisation guidance recommends checking permissions on every request, including requests that bypass the normal user interface.
Build a permission matrix that names the role, object and action. For example, a payroll operator might read assigned records while a separate role approves a payment batch. The approved business process should determine the allocation, including any separation of duties the organisation requires.
Test an unauthorised role, a different user's record and an altered object identifier. For systems serving multiple customers or business units, include attempts to cross the relevant data boundary. Retain the expected outcome and the result for each test.
Give sessions an explicit policy
Decide how long a session can remain active and which events require a new access decision. Consider changed privileges, stale device information, suspected compromise and a request for a more sensitive action.
NIST SP 800-207 allows a sufficiently recent trust evaluation. The design can reuse valid authentication evidence while checking whether the requested action remains permitted. Set interactive reauthentication requirements according to the resource and risk.
Identify systems that cache entitlements or rely on tokens that remain valid after an account change. Those behaviours affect the time it takes to remove access. Choose expiry, re-evaluation and revocation mechanisms that meet the agreed requirement, and verify their effect at the resource.
Measure whether revocation reaches the resource
Use a controlled test account with an active session. Remove its entitlement and observe both a new request and the existing session. Record the elapsed time until the enforcement point denies the relevant action.
Repeat the test for the routes in scope, including direct APIs and administrative interfaces. A disabled account in a directory is useful evidence, but the acceptance test needs to show what the resource permits after that change.
Decide how the service should behave when its identity or policy dependency fails. Test the approved restriction, continuity or recovery procedure with operations staff. Record who may authorise emergency access and how the organisation reviews its use.
Retain enough evidence to explain the decision
Keep the subject, resource, requested action, outcome and policy reason where the systems support them. Protect the records and exclude passwords, access tokens and unnecessary sensitive data, following the logging guidance relevant to the application.
The result should let a reviewer trace one request and answer who had access, why the organisation allowed it and what would cause that access to end.
Download the Quokka Zero Trust Architecture Implementation Guide for implementation actions, suggested owners and acceptance evidence across identity, applications, data and operations.