Security as a product: why adoption beats edicts in practice

At a glance

What this is: This is an opinion and how-to article arguing that security programmes should be designed like products, with clear value, user empathy, and measurable outcomes.

Why it matters: It matters because IAM, PAM, and broader security teams only reduce risk when controls fit how people actually work, especially where identity, access, and adoption intersect.

👉 Read Abstract Security's article on security as a product, not an edict

Context

Security teams often fail when they frame controls as mandates rather than services people can understand and use. In practice, adoption depends on whether the control removes friction, explains the risk clearly, and gives users a workable path forward. That product-oriented framing is especially relevant in identity and access programmes, where policy compliance, user experience, and operational reality have to line up.

The article’s core argument sits in the governance gap between control intent and actual use. When teams build for the people who must operate the control, they are more likely to achieve durable risk reduction across IAM, PAM, and adjacent security workflows. That same principle applies to identity-heavy programmes such as access review, secrets management, and zero-trust access design.

Key questions

Q: How should security teams design controls that people will actually use?

A: They should start with the risk, then design the control around the user journey that already exists. The goal is to reduce harm without creating so much friction that people route around it. That means using plain language, testing with real operators, and measuring adoption after rollout, not just technical deployment.

Q: Why do security controls fail when they are treated like mandates?

A: Mandates create compliance on paper but often produce workarounds in practice. When users do not understand the value of a control, they look for faster paths, informal exceptions, or shadow processes. Security teams get better outcomes when they explain the risk, show the benefit, and make the secure path easier than the unsafe one.

Q: What do organisations get wrong about user friction in security controls?

A: Organisations often mistake user friction for security strength. A control that slows employees but does not meaningfully reduce privilege reuse, lateral movement, or session abuse may create operational pain without reducing risk. Teams should judge controls by their effect on attacker options, not only by their inconvenience to legitimate users.

Q: How do IAM teams know whether access governance is working?

A: IAM teams should look for fast revocation after role change or departure, accurate entitlement data, and low numbers of orphaned or over-provisioned accounts. If access creation is easy but removal is slow, governance is incomplete. The strongest signal is whether access still matches business need after the identity changes.

Technical breakdown

Why product thinking changes security control adoption

A product-first security programme starts by treating the control as something users and operators must willingly adopt, not merely tolerate. That means defining the problem in plain English, making the value visible, and reducing the operational pain that often drives shadow workarounds. In identity programmes, the same logic applies to approvals, access workflows, and step-up controls: if the process is slower than the business task, people will route around it. The article’s point is not that security becomes optional, but that usability becomes part of the control surface.

Practical implication: measure adoption and friction as control outcomes, not just policy coverage.

Jobs to be done in IAM and access workflows

Jobs to be done is a useful lens because it asks what the business is hiring the security programme to accomplish. For IAM and PAM teams, that could mean enabling access quickly while preserving least privilege, or helping engineers complete a task without creating permanent exceptions. This shifts the conversation from control ownership to task completion, which is a more realistic way to design access governance. The article uses this idea to show that security succeeds when it aligns with the work being protected, not when it sits outside it as a separate approval layer.

Practical implication: map each access control to a concrete business job before deciding how strict it should be.

Participatory design reduces resistance to security controls

Participatory design means involving the people affected by a control in shaping how it works, what exceptions exist, and where an alternative path is needed. In security operations, that does not mean handing over authority. It means gathering real user input early enough to avoid building controls that create unnecessary exception handling or bypass behaviour. This is particularly relevant to identity security, where access friction can trigger risky workarounds such as shared accounts, informal approvals, or unmanaged secrets. The article shows that collaboration can improve both trust and implementation quality.

Practical implication: include end users and operators in control design before rollout, not after complaints start.

NHI Mgmt Group analysis

Security programmes fail when they optimise for enforcement instead of adoption. Controls that people cannot understand, trust, or use cleanly tend to generate workarounds, exceptions, and hidden risk. That is true across IAM, PAM, and endpoint control layers, where the operational burden of the control can become the real source of exposure. The better test is whether the control changes behaviour in a durable way, not whether it was technically deployed.

Identity governance is strongest when it behaves like a service, not a decree. Access reviews, approval flows, and privileged access controls all become more effective when their purpose is legible to the business. This is where product thinking matters for identity teams, because governance only works at scale when the people affected can see the risk, understand the path, and complete the task without inventing their own process. Practitioners should treat adoption as a governance metric.

Product design is now part of security architecture. In a mature programme, control quality is not only measured by detection or enforcement depth, but also by whether the programme earns consistent use. That is especially relevant in identity environments where friction can create unmanaged credentials, informal exceptions, or poor stewardship of access. The naming concept here is adoption-driven control design: if a security control is not adopted, it does not reduce risk in practice. Practitioners should design for measurable uptake, not just policy intent.

Collaboration is the mechanism that turns security from resistance into utility. The article’s participatory design and jobs-to-be-done framing are not soft skills add-ons. They are implementation methods that reduce policy drift and improve operational alignment across identity, endpoint, and access workflows. That matters because control effectiveness depends on how well the business can absorb it. Security leaders should therefore treat user participation as a control assurance input, not a communication afterthought.

What this signals

Adoption-driven control design: security teams should now treat user uptake as a first-class design criterion, not a communications metric. In identity programmes, that means access review, privileged access, and exception handling must be usable enough to survive real operating pressure. The control that people avoid is the control that quietly loses.

The wider signal for practitioners is that security architecture and human workflow are converging. Where a programme depends on friction to enforce policy, it will eventually accumulate exceptions, shadow approvals, and informal recovery paths. Teams can anchor this thinking in the NIST Cybersecurity Framework 2.0 and the NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access control and auditability are concerned.

For identity leaders, the practical implication is to build controls that remain effective after the novelty wears off. That means measuring whether users still choose the secure path when they are under deadline, under pressure, or trying to complete a task quickly. If the programme cannot hold up under those conditions, the design still needs work.

For practitioners

• Define controls as products with measurable user value Document the risk being reduced, the user pain being removed, and the success metric before rollout. If a control cannot be explained in plain English to the people it affects, it is likely to meet resistance or be bypassed.
• Map each control to a real business job Use jobs-to-be-done workshops to identify what the business is trying to accomplish and where security is helping or blocking that outcome. Rework approvals, exceptions, and access paths around those tasks instead of around internal team boundaries.
• Build feedback loops into rollout and operations Collect feedback from users and operators during implementation, then use that data to adjust the control, its documentation, and its exception path. This reduces workaround culture and helps security teams learn where friction is creating shadow process.
• Treat adoption as an operational control metric Track whether people actually use the control, whether exceptions are increasing, and whether the control is forcing manual compensations elsewhere. Adoption data should sit alongside compliance and detection data in programme reporting.

Key takeaways

• Security controls fail more often from poor adoption than from weak intent.
• Identity governance improves when controls are designed around real tasks and measured for use.
• Teams that reduce friction without weakening control are more likely to earn durable security behaviour.

Key terms

• Adoption-driven control design: A security design approach that treats user uptake as part of control effectiveness. The control is only considered successful if the intended audience can understand it, use it, and continue using it under real operating pressure without creating risky workarounds.
• Jobs to be done: A product and service design lens that asks what outcome the user is trying to achieve and what help they need to achieve it. In security, it reframes controls as tools for completing business work safely rather than obstacles that exist apart from the work.
• Participatory design: A design method that involves affected users in shaping how a system works. In security programmes, it helps teams identify friction, exception patterns, and operational constraints early, before those issues turn into shadow processes or control bypasses.
• Security product thinking: An approach that frames security as something delivered to internal users with a clear value proposition, usable workflows, and measurable outcomes. It shifts the emphasis from forcing compliance to creating controls that are accepted because they solve a visible business problem.

What's in the full article

Abstract Security's full article covers the operational detail this post intentionally leaves for the source:

• The article expands the internal example of removable-media blocking into a practical control-design story with user exception handling.
• It explains how jobs to be done and participatory design can be applied to security programme change without losing governance intent.
• It provides the author's lived ZTNA implementation example, including the user feedback that shaped the rollout.
• It includes the companion editorial note from Abstract Security on why reducing friction matters to defenders.

👉 Abstract Security's full post covers the control-design examples, user adoption lesson, and ZTNA rollout perspective.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in the context of real-world operational control. It helps security practitioners connect identity risk to practical programme design.