Authentication, Authorization, and Audit — Securing Preview Environments for External Reviewers

Why Preview Environments Need a Different Security Model

Production security assumes persistent users with accounts, roles, and sessions. Preview environments break that assumption. The people who need access — clients, compliance officers, external partners — don’t have accounts in your identity provider. They aren’t employees. They might review one build and never return, or they might review every release for a year. The security model has to handle both cases without requiring IT onboarding for every reviewer.

At the same time, preview environments aren’t throwaway sandboxes. They run real code, connect to real services, and the decisions made against them — approved, rejected, needs changes — carry real consequences. A client’s sign-off on a preview is a contractual event. A compliance officer’s approval may be a regulatory artifact. The security model needs to be strong enough that those decisions hold up under scrutiny, and lightweight enough that stakeholders actually complete the review instead of asking the developer to screenshare.

The framework for getting this right is the same one that governs any secure system: authentication (who is this person), authorization (what can they access), and audit (what did they do).

Authentication: Verifying Identity Without Creating Accounts

The core challenge is proving who the reviewer is without making them create credentials in your system. Three mechanisms handle this at different assurance levels.

Magic links send a single-use, time-limited URL to an email address. The reviewer clicks it and is authenticated — no password, no setup. Identity confidence is tied to email ownership: if the link was sent to [email protected] and someone used it, you have reasonable assurance it was someone with access to that inbox. Magic links get near-universal participation because there’s zero friction. The tradeoff is that email forwarding, shared inboxes, and compromised accounts all weaken the identity guarantee.

TOTP tokens require the reviewer to enter a six-digit code from an authenticator app. This proves possession of a specific enrolled device, not just access to an email account. The friction is moderate — the reviewer needs an authenticator app and a one-time enrollment step. For recurring reviewers, that setup cost is negligible. For one-off reviewers, it’s a barrier.

PIV/CAC certificates use a hardware smart card with a cryptographic certificate issued by a trusted authority. The reviewer inserts their card, enters a PIN, and the system verifies their identity against the certificate chain. This is the strongest identity guarantee available — it proves a specific credentialed individual is physically present. PIV/CAC is standard in U.S. federal agencies and defense contractors where identity assurance is a regulatory requirement.

Each method maps to a different assurance level. NIST 800-63 formalizes this spectrum, but the practical question is simpler: if someone disputes whether they approved a build, how strong is your proof that they did?

Authorization: Scoping What Each Reviewer Can See and Do

Authentication confirms identity. Authorization determines what that identity is allowed to do. For preview environments, authorization has two dimensions: which environments a reviewer can access, and what actions they can take within them.

Not every reviewer should see every preview. A client reviewing a frontend redesign doesn’t need access to the internal admin panel. A compliance officer checking an audit trail feature doesn’t need to see unrelated work in progress. Scoping access per reviewer prevents information leakage and keeps the review focused.

Actions matter too. Some reviewers should only observe — view the environment, follow a checklist, leave comments. Others need approval authority — the ability to formally sign off or reject a build. Authorization controls determine whether a reviewer is a participant or a decision-maker, and that distinction matters when the audit trail is used as evidence.

Time-based scoping adds a third constraint. Preview environments are ephemeral. Access should expire when the environment does, or sooner. A link that works indefinitely is a link that can be reused after the review context has changed. Time-limited access tokens ensure that reviewer access is bounded to the review window.

Audit: Recording What Happened and Proving It Later

Authentication and authorization are prerequisites. Audit is the payoff. When a stakeholder reviews a preview and approves it, the audit trail needs to answer four questions: who approved it, when they approved it, what they were reviewing, and how their identity was verified.

In regulated industries — healthcare, finance, government contracting — these records aren’t optional. FedRAMP requires evidence of authorized access. SOC 2 requires audit logs of system interactions. FDA 21 CFR Part 11 requires electronic signatures with identity verification. The audit trail from a preview review is only as strong as the authentication method that produced it. A magic link log entry says “someone with access to this email.” A PIV log entry says “this credentialed individual, verified by certificate authority X.”

PreviewProof structures this by logging every authentication event, checklist interaction, and approval decision into a unified audit record — regardless of whether the reviewer authenticated via magic link, TOTP, or PIV. The authentication method is recorded alongside the decision so that teams can match the identity assurance level to their compliance requirements.

Even without regulatory pressure, audit trails solve operational problems. When a post-mortem asks who reviewed a broken release, or a client disputes whether they approved a design change, the difference between “we think someone looked at it” and “here’s the signed record” is the difference between a process and a guess.