Jobs to be done

Expanded Definition

Jobs to be done is a way of describing the underlying outcome a person is trying to accomplish, rather than focusing only on the product, role, or feature they use. For security teams, that shift matters because controls often fail when they are designed around policy language instead of the operational work people must complete. The concept is not a formal security standard, and usage in the industry is still evolving, but it is increasingly useful for explaining why users bypass friction-heavy controls and why workflow-aligned safeguards are more effective.

In identity and security programmes, jobs to be done helps teams distinguish between the task itself and the mechanism used to complete it. A developer may need to deploy code, an analyst may need to investigate an alert, and a finance user may need to approve a payment. The security objective is not to block the job, but to make the secure path the easiest path. That aligns well with the intent of the NIST Cybersecurity Framework 2.0, which encourages risk-informed outcomes rather than control theatre.

The most common misapplication is treating jobs to be done as a UX slogan, which occurs when teams collect user complaints but do not map the actual business outcome, decision point, and risk exposure.

Examples and Use Cases

Implementing jobs to be done rigorously often introduces design complexity, requiring organisations to weigh smoother user execution against tighter security enforcement and more detailed workflow analysis.

• A security team redesigns privileged access so an engineer can complete an urgent production fix without creating permanent standing access.
• A fraud operations group maps the analyst job as “confirm or reject a suspicious transaction” and then places verification steps only where they support that decision.
• A platform team examines why users share credentials, discovering the job is “get access quickly during a deadline,” not “avoid authentication.”
• An NHI programme treats service accounts as job-aligned identities, assigning secrets, certificates, and permissions only for the action the workload must perform.
• An AI product team defines the job of an agent as “triage and route incidents,” then constrains tool access so execution authority matches that narrow purpose.

For security architects, the value is in exposing where the real friction sits. The strongest designs often come from pairing the jobs lens with policy and control models such as NIST Cybersecurity Framework 2.0 and mapping the work path before adding enforcement points. That is especially useful when defining self-service access, approval workflows, or automated agent actions.

Why It Matters for Security Teams

Jobs to be done matters because security failures often begin when teams optimise for abstract compliance instead of the real work users need to complete. When a control interrupts a legitimate business outcome, people look for shortcuts, and those shortcuts become the attack surface. That is why the concept is valuable in identity security, NHI governance, and agentic AI security: each depends on aligning authority, access, and execution with a clearly understood job. If the job is vague, permissions drift, secrets proliferate, and automation is granted broader reach than it needs.

For NHI and AI agent contexts, the question becomes whether an identity exists to complete a bounded task or to act as a general-purpose privilege holder. The closer the design stays to a specific job, the easier it is to limit blast radius, review behavior, and revoke access when the work ends. Organizations typically encounter the cost of ignoring this only after a bypass, outage, or misuse event, at which point jobs to be done becomes operationally unavoidable to untangle the real workflow from the broken control.

Related resources from NHI Mgmt Group

• What should be done with inactive NHIs?
• What breaks when certificate discovery is only done once in a while?
• What breaks when JWT verification is done only in middleware?
• What breaks when AI agents are monitored like ordinary automated jobs?