Notifications
Clear all
Topic starter
01/08/2026 8:54 pm
TL;DR: Security teams that treat controls as a product, not an edict, are more likely to earn adoption and reduce friction, according to Abstract Security’s C2 Corner article. The central shift is moving from force-based enforcement to evidence-led controls that users can understand, choose, and work with.
NHIMG editorial — based on content published by Abstract Security: C2 Corner, Security as a Product
Questions worth separating out
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.
Q: Why do security controls fail when they are treated like mandates?
A: Mandates create compliance on paper but often produce workarounds in practice.
Q: What do organisations get wrong about user friction in security controls?
A: Organisations often mistake user friction for security strength.
Practitioner guidance
- Define controls as products with measurable user value Document the risk being reduced, the user pain being removed, and the success metric before rollout.
- 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.
- 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.
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.
👉 Read Abstract Security's article on security as a product, not an edict →
Security as a product: what changes when teams design for adoption?
Explore further
01/08/2026 9:03 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Security as a product: why adoption beats edicts in practice
