Zero trust policy writing still depends on contextual access control

At a glance

What this is: This is a StrongDM analysis of the Kipling Method for zero trust policy writing, arguing that contextual access control is required to decide not just who gets access, but whether that access should continue.

Why it matters: IAM, PAM and NHI teams need policy logic that can account for context, because zero trust breaks down when access decisions stop at authentication and ignore session, device and activity signals.

Context

Zero trust policy writing fails when it treats authentication as the end of the access decision. The article argues that policy must incorporate context such as who is requesting access, what they want to do, where they are connecting from, when the request occurs, why access is needed and how the resource is being reached.

For identity programmes, that means access control is no longer a static allow or deny rule. It becomes a continuous governance exercise across human users, privileged access paths and machine-mediated access flows, with session conditions and device posture shaping enforcement.

Key questions

Q: What breaks when zero trust policy only checks who someone is?

A: Policy breaks at the authorisation layer because identity proof does not tell you whether access is appropriate for the current session, device or task. Zero trust needs context to decide if access should continue, not just whether it started. Without that, privileged sessions and sensitive resources remain overexposed after authentication.

Q: Why do contextual signals matter more for privileged access?

A: Privileged access increases blast radius, so time, location, device posture and activity all affect whether access is still acceptable. Contextual signals reduce the chance that an elevated session continues after the situation changes. They are especially important for production systems and regulated environments where a broad session can create outsized risk.

Q: How do organisations know if zero trust controls are actually working?

A: They know the controls are working when they can inventory privileged identities, prove access is time-bound, and show that rotation and revocation happen on schedule. A healthy programme also has few manual exceptions and low workflow friction, because recurring bypasses are a sign that policy and operations are out of sync.

Q: What is the difference between authentication and contextual authorisation?

A: Authentication confirms who the principal is. Contextual authorisation decides whether that principal should access a specific resource under the current conditions, including time, location, device trust and purpose. Zero trust depends on keeping those decisions separate, because a valid identity does not automatically justify ongoing access.

Technical breakdown

How the Kipling Method shapes zero trust policy logic

The Kipling Method turns access policy into a contextual decision model. Rather than relying only on identity proof at login, it evaluates six dimensions: who, what, when, where, why and how. That gives policy writers a way to encode intent, device trust, location constraints, time windows and asset sensitivity into the access decision. In practice, this is how zero trust moves from a perimeter replacement slogan to an enforceable policy language. It also creates a clearer bridge between access governance and real-world operating conditions, because the policy reflects why access exists, not just whether a principal can authenticate.

Practical implication: encode contextual attributes into access policy rather than treating authentication as the full control.

Why continuous verification matters after access starts

Zero trust only works if access remains conditional after the session begins. The article describes a model where trust is re-evaluated continuously, so a session can be terminated when the user, device or activity no longer meets policy conditions. That matters because many attacks succeed after initial access, when the principal shifts to actions that were not visible at authentication time. Continuous verification therefore closes the gap between initial trust and ongoing trust, which is where privileged misuse often hides. For practitioners, this is the difference between a one-time check and a governed session.

Practical implication: design policy enforcement to reassess access during the session, not just at sign-in.

Why context is especially important for privileged access

Privileged access magnifies every weakness in the policy model. The article ties contextual trust to sensitive systems, including regulated data stores and production environments, where the question is not only whether access is allowed, but whether it is appropriate right now. Contextual factors such as device trust, location trust, time trust, classification trust and activity trust help separate legitimate administrative work from risky behaviour. That is especially relevant in PAM because privileged access tends to create larger blast radius when it is overbroad or overly persistent. Context is therefore a control input, not an optional enhancement.

Practical implication: apply stronger contextual checks to privileged sessions and regulated resources than to ordinary user access.

NHI Mgmt Group analysis

Contextual access control is the real operating system of zero trust. The article is correct that identity proof alone does not answer the policy question. Zero trust becomes meaningful only when access decisions incorporate session context, resource sensitivity and request purpose, not simply a successful login. For IAM and PAM teams, the practical conclusion is that policy logic must move closer to the moment of use.

The Kipling model exposes a governance gap between authentication and authorisation. Many programmes still treat those as adjacent controls, but the article shows they are separate decisions. Authentication says who is present; contextual authorisation decides whether the access remains appropriate. That distinction matters most where standing access would otherwise survive unchanged across long sessions or privileged workflows. Practitioners should treat that separation as a design assumption, not a tuning option.

Zero trust policy writing should be measured by the quality of its context inputs, not its slogans. A policy that asks who and what but omits when, where, why and how is still an incomplete decision model. The article usefully reinforces that access governance is only as strong as the signals available to it. Teams should evaluate whether their policy engine can actually consume device trust, location, time and activity data before claiming zero trust maturity.

StrongDM's framing reinforces a named concept: contextual access control debt. Policy models that stop at identity verification accumulate debt when they cannot express time, place, purpose and device conditions. That debt shows up later as over-permissive access, manual exceptions and weak enforcement around production resources. The implication for practitioners is that zero trust maturity depends on closing that policy expression gap, not on adding another approval step.

Access management has become the enforcement layer for zero trust, not just the front door. The article's emphasis on continuous session assessment reflects where modern governance is heading. Session control, JIT logic and device posture are converging into one policy surface. For identity teams, that means zero trust architecture has to be operationalised as live access governance rather than a static design principle.

From our research library:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Read next: Zero Trust Identity Guide

What this signals

Contextual access control debt: policy models that cannot express time, place, purpose and device conditions eventually force teams into manual exceptions and overbroad access. Zero trust maturity depends on closing that policy expression gap before it becomes operational drift.

Access control decisions are becoming session-based rather than login-based, which means IAM and PAM teams need to prove their policy engines can consume live context. That shifts the programme from identity verification alone to continuous governance of access conditions.

For practitioners

• Map policy decisions to the six Kipling questions Translate who, what, when, where, why and how into explicit access rules for your highest-risk systems so policy can be evaluated consistently.
• Add session-level re-evaluation to privileged access Require access to remain conditional after login, with termination when device trust, activity or location no longer matches policy.
• Use context to narrow production access Apply stronger constraints for regulated environments, including time windows, location controls and approved device posture.
• Instrument activity trust for sensitive workflows Log and evaluate the actions performed during a session so policy can distinguish legitimate administration from risky behaviour.

Key takeaways

• Zero trust policy writing fails when access decisions stop at authentication and do not reflect session context, device posture or activity.
• The strongest zero trust designs turn who, what, when, where, why and how into enforceable policy inputs rather than narrative guidance.
• For practitioners, the key test is whether access can be reassessed and constrained after the session starts, especially for privileged and regulated resources.

Key terms

• Contextual Access Control: Contextual access control changes access decisions based on factors such as device posture, application risk, location, or data sensitivity. In cloud security, it helps move access policy from static entitlements toward decisions that reflect the actual conditions of use.
• Session Re-evaluation: Session re-evaluation is the practice of checking identity, device, and context again after access begins. It matters because a valid login does not guarantee the session remains appropriate, especially in regulated environments where risk can change while work is in progress.
• Contextual trust: The idea that an agent must decide which inputs, messages, or documents are safe to act on. In agentic environments this becomes a governance issue because content, not just identity, can influence execution, and unsafe context can steer a valid identity into unsafe behaviour.
• Zero Trust Policy Enforcement: Zero Trust policy enforcement applies least privilege controls to workload interactions based on observed behavior and explicit rules. Instead of trusting a network location or workload by default, it limits what each process, pod, or service may do. This reduces blast radius and helps contain attacks inside dynamic cloud environments.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.