Topic starter
25/06/2026 12:44 am
TL;DR: In hybrid environments, build-your-own JIT access often becomes a patchwork of scripts, microservices, connectors, and role logic that slows delivery, increases maintenance, and can leave privilege gaps, according to Apono. The real issue is not whether JIT works, but whether teams can sustain least privilege, auditability, and coverage at cloud scale.
Editorial analysis by NHI Mgmt Group, based on content published by Apono: “Build vs. Buy Access Control: Why Apono Is the Smarter Choice for Cloud & Security Teams”.
By the numbers:
- Over 95% of identities hold excessive privileges, which is the condition that makes JIT access harder to operate safely in hybrid environments.
- 88% of breaches start from compromised identities, showing why privilege reduction and access timing matter in cloud programmes.
Key questions
Q: What breaks when hybrid cloud JIT access is built as a custom workflow?
A: Custom JIT workflows tend to break at the seams between provisioning logic, integrations, and revocation.
Q: Why does excessive privilege make JIT access harder to govern in cloud environments?
A: Because JIT only reduces risk if standing access is already well understood and tightly scoped.
Q: What are the signs that an internal JIT platform is becoming unmanageable?
A: Common signs include growing connector work, repeated role rewrites, fragmented logs, and access paths that only work for a narrow set of applications.
Practitioner guidance
- Map JIT scope to the full identity fabric Document which human, NHI, SaaS, and workload identities are actually covered by your current access model, then identify where custom logic stops short of real hybrid coverage.
- Test revocation and expiry under change Run failure tests for API changes, new services, and permission drift to see whether temporary access still expires cleanly when the environment changes.
- Separate access workflow from secret storage Ensure the JIT system never caches credentials locally and instead pulls secrets from controlled stores with clear revocation paths.
Bottom line: Homegrown JIT access often fails not because the idea is wrong, but because the control becomes inseparable from the custom code that maintains it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
25/06/2026 9:45 am
Build-versus-buy is really a governance question about who owns the access control lifecycle. In hybrid cloud, the hard part is not issuing a temporary grant once. It is maintaining policy logic, integration coverage, logging, and revocation discipline across changing environments. When teams build this in-house, they inherit the full lifecycle burden, not just the workflow.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
A question worth separating out:
Q: How do teams decide whether to build or buy JIT access for hybrid cloud?
A: Teams should compare not only initial delivery effort but also lifecycle ownership, auditability, integration breadth, and coverage beyond the first use case. If the organisation cannot sustain role updates, logging, patching, and revocation across environments, buying a platform is usually the more governable option.
👉 Read our full editorial: JIT access in hybrid cloud: the build-versus-buy trade-off