Notifications
Clear all
Topic starter
09/07/2026 3:22 pm
TL;DR: Most authorization proof-of-concepts fail quietly because teams scope them poorly, measure the wrong things, or never define success before starting, according to Cerbos and Sapphire Ventures’ survey of Global 2,000 IT executives. A good POC is short, tied to one real service, and judged on business rules, latency, auditability, and migration fit rather than demo polish.
NHIMG editorial — based on content published by Cerbos: Practical guide to running an authorization POC
By the numbers:
- 78% said that fewer than half of their POCs result in production deployments.
Questions worth separating out
Q: How should teams scope an authorization proof of concept?
A: Scope the POC to one real service with real users, real roles, and real authorization complexity.
Q: Why do authorization POCs fail even when the technology works?
A: They fail when teams measure the wrong things or never agree on success criteria before starting.
Q: How do you know if an authorization POC is actually working?
A: You know it is working when you can show evidence for every success criterion, including policy expressiveness, latency under realistic load, audit completeness, and developer usability.
Practitioner guidance
- Scope the POC to one real service Choose a service with real users, at least three permission roles, and genuine conditional access logic.
- Define success criteria before configuration starts Write down the exact business rules, latency targets, audit requirements, and developer ramp-up expectations you will use to decide pass or fail.
- Measure the baseline before changing anything Capture current permission-change time, audit preparation effort, and onboarding friction so the POC can prove improvement rather than rely on opinion.
What's in the full article
Cerbos' full guide covers the operational detail this post intentionally leaves for the source:
- A step-by-step way to choose a single representative service for the POC without creating unnecessary production risk.
- Specific criteria for judging whether policy language, audit output, and deployment model are ready for broader rollout.
- A practical breakdown of baseline metrics to capture before the POC so the before-and-after comparison is defensible.
- Examples of how teams can structure the review meeting so engineering, security, and compliance all weigh in.
👉 Read Cerbos' guide to running a successful authorization POC →
Authorization POCs: what makes a proof of concept actually pass?
Explore further
09/07/2026 3:40 pm
Authorization POCs are really governance tests, not technology demos. The article makes clear that the core failure mode is not whether a policy engine can execute, but whether the organisation can prove it solves a real access-control problem under real constraints. That means the POC is already part of the identity governance process, because it determines whether future authorization decisions will be observable, reviewable, and operationally sustainable. Practitioners should treat the POC outcome as a control decision, not a procurement opinion.
A few things that frame the scale:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 52% of respondents see AI security decision-making power shifting toward platform and infrastructure teams rather than the executive suite.
A question worth separating out:
Q: Who should review an authorization POC before approval?
A: Security, compliance, product, and engineering should all review it. Engineering validates the integration, security validates the decision logs and control strength, compliance checks evidence quality, and product confirms that the policy behavior matches the intended business rules.
👉 Read our full editorial: Authorization POC success depends on scope, metrics, and timeline
