ZTNA

14:59 · recent

1. Request. Maya requests Portal A180 using D180’s 14:59 report. Her identity and read-only DrawingDesk permission are unchanged. The broker trusts the identity/device association and posture record, not a client claim. Sam’s selected policy is Maya, D180, A180 and a report age from zero through five minutes. Both reports claim the same acceptable posture; only their timestamp differs. O180 and the app’s read-only grant remain. No admission or app operation exists yet.
2. Admit path. The recent report meets Sam’s selected rule. The broker records S180 for A180 only; no document request has run. At trusted 15:00 UTC the policy engine compares the selected report and exact identity/device/portal scope. Its administrator/enforcement configuration creates a server-held admission only on success, ending at 15:10 exclusive. This is the control-plane batch, not a tunnel handshake or file delivery. A grant for A180 cannot admit A181. Report recency is a configured condition, not proof of a safe device.
3. Use app. The portal admits Maya’s requests. DrawingDesk independently returns O180 for reading and refuses editing; the original stays unchanged. Independent HTTP requests pass through the modeled enforcement gate before the application. With S180, the gate validates server-held subject/device/target binding and trusted time; DrawingDesk then checks its own action/object grant: GET 200 with O180, PUT 403 without a change. Without S180, both return 403 at the gate and the application receives neither. An application refusal is different from a portal refusal. Identity, app grant and original remain.
4. Test scope. Independent checks refuse another portal and a new A180 request at the 15:10 expiry. An allowed connection did not widen Maya’s app permissions. The admitted path separately tests an A181 request with the A180 admission and an A180 request at the exact 15:10 exclusive end: both gate refusals, no application delivery. The stale path has no admission and tests fresh selected/other-portal refusals; it does not claim to prove expiry of a grant it never received. Nora’s separately authorized read of O180 still works. These checks do not demonstrate continuous teardown, every bypass route or outage handling.

14:30 · stale

1. Request. Maya requests Portal A180 using D180’s 14:30 report. Her identity and read-only DrawingDesk permission are unchanged. The broker trusts the identity/device association and posture record, not a client claim. Sam’s selected policy is Maya, D180, A180 and a report age from zero through five minutes. Both reports claim the same acceptable posture; only their timestamp differs. O180 and the app’s read-only grant remain. No admission or app operation exists yet.
2. Admit path. The thirty-minute-old report fails Sam’s selected freshness rule. No S180 is issued; Maya’s identity remains valid. At trusted 15:00 UTC the policy engine compares the selected report and exact identity/device/portal scope. Its administrator/enforcement configuration creates a server-held admission only on success, ending at 15:10 exclusive. This is the control-plane batch, not a tunnel handshake or file delivery. A grant for A180 cannot admit A181. Report recency is a configured condition, not proof of a safe device.
3. Use app. The enforcement point refuses Maya’s read and edit attempts because admission is absent. Neither reaches DrawingDesk. Independent HTTP requests pass through the modeled enforcement gate before the application. With S180, the gate validates server-held subject/device/target binding and trusted time; DrawingDesk then checks its own action/object grant: GET 200 with O180, PUT 403 without a change. Without S180, both return 403 at the gate and the application receives neither. An application refusal is different from a portal refusal. Identity, app grant and original remain.
4. Test scope. Fresh checks refuse A180 and the other portal without admission. DrawingDesk’s original and read-only permission still remain. The admitted path separately tests an A181 request with the A180 admission and an A180 request at the exact 15:10 exclusive end: both gate refusals, no application delivery. The stale path has no admission and tests fresh selected/other-portal refusals; it does not claim to prove expiry of a grant it never received. Nora’s separately authorized read of O180 still works. These checks do not demonstrate continuous teardown, every bypass route or outage handling.

This is an HTTP/SQL model of selected broker and enforcement decisions, not a ZTNA product or tunnel. Identity, device-report integrity, protected channels and synchronized service time are assumed. A recent report is not proof of current device safety. Expiry tests new requests; ongoing connection teardown, direct-path closure, other policies and outages are not demonstrated. S180 is a label, not a credential.

Flow references: NIST SP 800-207: policy decision, enforcement and individual resources · NIST SP 800-215: cloud controls, ZTNA and combined networking/security