Notifications
Clear all
Topic starter
06/09/2026 3:45 pm
TL;DR: Platform engineering is being adopted to reduce fragmented tooling, manual workflows, and governance gaps across software delivery, while improving standardisation, self-service, and release consistency, according to Arxan Technologies. The identity and security lesson is that policy-driven workflows only help when access, RBAC, and runtime governance are encoded into the platform rather than bolted on later.
NHIMG editorial — based on content published by Arxan Technologies: Platform Engineering, IDPs, and Golden Paths
By the numbers:
- Gartner predicts that by 2026, 80% of large software engineering organizations will have dedicated platform engineering teams.
- According to a Google Cloud research report, 71% of leading adopters of platform engineering have significantly improved their time-to-market.
- The same Google Cloud research report says only 28% of less mature adopters have significantly improved their time-to-market.
Questions worth separating out
Q: How should platform teams govern secrets across internal developer platforms?
A: They should treat secrets as part of the platform control plane, not as a separate vaulting concern.
Q: Why do golden paths reduce risk when they are designed well?
A: Golden paths reduce risk because they replace ad hoc implementation with approved workflows, standard controls, and repeatable checks.
Q: What do security teams get wrong about platform engineering governance?
A: They often assume the platform team owns operations and security teams only need to review the end result.
Practitioner guidance
- Map platform permissions to identity ownership Document which human teams, service accounts, and automation paths can create, change, approve, and destroy developer environments.
- Embed policy checks into golden paths Require every approved template to enforce baseline access rules, environment restrictions, and deployment approval logic before a service can move forward.
- Audit pipeline credentials and provisioning access Review which secrets, tokens, and role bindings are used by CI/CD and infrastructure-as-code workflows.
What's in the full article
Arxan Technologies' full blog post covers the operational detail this post intentionally leaves for the source:
- Platform engineering examples for CI/CD standardisation, infrastructure provisioning, and service catalog design
- A comparison of developer portal approaches, including tradeoffs in governance depth and operational overhead
- Case study detail on how Toyota used Backstage to reduce onboarding time, deployment effort, and cloud costs
- Specific observations on how different IDP options handle RBAC, audit logging, and multi-cloud compatibility
👉 Read Arxan Technologies' analysis of platform engineering, IDPs, and golden paths →
Platform engineering and golden paths: what changes for delivery teams?
Explore further
06/09/2026 3:45 pm
Platform engineering is becoming an identity governance problem as much as a delivery problem. Once internal developer platforms mediate provisioning, deployment, and observability, they also mediate access decisions for humans, service accounts, and automation. That means IAM teams cannot treat developer portals as purely operational tooling. The governance model has to extend into the platform layer, where self-service is only safe if identity, entitlements, and auditability are built in from the start.
A question worth separating out:
Q: What happens when self-service delivery is built without identity controls?
A: Self-service without identity controls usually creates faster sprawl, not faster delivery. Teams can provision environments, deploy services, and attach credentials with too little oversight, which increases drift, audit gaps, and over-privilege. The result is a delivery system that scales inconsistency as efficiently as it scales code.
👉 Read our full editorial: Platform engineering and golden paths reduce DevOps fragmentation
