Skip to content
All writing

Architecture

Security requirements that cannot be tested are not finished

A security requirement becomes useful when a team can observe the behavior, test the boundary and know who owns failure.

2 min read

Listen to this articleComplete narrated version of this article
A protected product boundary separating allowed behavior from rejected behavior.

Store tokens securely sounds responsible. It is not yet a requirement a team can finish.

Which tokens? Against which attacker? What behavior is forbidden? What must happen after logout, device restore, biometric change or refresh failure? Who can prove the release still behaves that way?

Until those questions have observable answers, security remains a direction rather than a product boundary.

Write the attacker and the protected behavior

Do not begin with the library. Begin with what the attacker can do and what the product must prevent or contain.

An acceptance criterion might say that a copied application database cannot reveal an active refresh token, or that a logged-out device cannot reuse cached authenticated content. Both statements can be tested. Use secure storage cannot.

Failure behavior belongs in the requirement

Security mechanisms fail in production. Attestation is unavailable. A key is invalidated. The network cannot reach the refresh service. A migration meets data written by an older version.

The requirement must say whether the product blocks, degrades, retries, clears state or asks the user to authenticate again. If the failure mode is unspecified, the implementation will invent it under pressure.

Collect evidence at the boundary

A passing unit test may prove that a wrapper called an API. It does not prove that sensitive data stayed out of logs, backups, screenshots or analytics payloads.

Choose evidence that reaches the boundary you claim to protect. That may include an integration test, a device inspection, a proxy capture, a release configuration check or a documented manual verification.

Assign an owner and an expiry condition

Threats, platform behavior and dependencies change. A control without an owner becomes a historical belief.

Record who reviews the requirement, which event forces a new review and which evidence the release must retain. The result is not more security theatre. It is a behavior the product team can operate.

Security next step

Turn one requirement into observable behavior

Use the free guide to define the protected boundary, acceptance criteria, failure behavior and release evidence.

Share this essay