Kong Developer Summit 2026 in Los Angeles: identity implications

At a glance

What this is: Kong Developer Summit 2026 is an in-person event in Los Angeles focused on keynotes, workshops, and deep technical sessions around modern application connectivity and access patterns.

Why it matters: It matters because IAM, NHI, and platform teams often inherit the access patterns that developer events normalise, including API, workload, and agent-facing identity decisions.

By the numbers:

• The event runs in Los Angeles from September 30 to October 1, 2026, with pre-event certification training starting September 29.
• Early bird registration is $249, standard registration is $449, and last chance pricing is $549.
• The certification training add-on is limited to 100 seats and is priced at $299 early bird, $499 standard, and $599 at last chance.

👉 Register for Kong Developer Summit 2026 in Los Angeles

Context

Kong Developer Summit 2026 is a developer-facing event built around APIs, platform engineering, and the access decisions that sit underneath modern application delivery. For identity teams, the relevance is not the venue or the schedule but the way developer-centric access models shape service accounts, tokens, and other non-human identities across production environments.

The practical gap is that many identity programmes still review these patterns after the engineering choices are already embedded. When builders treat access as an implementation detail, governance teams inherit the consequences in onboarding, privilege scope, and credential lifecycle management. That makes this summit useful as a signal of where access patterns are heading, even when the agenda is not written for IAM practitioners directly.

The article also shows a familiar pattern in enterprise events: the commercial packaging of learning, certification, and deep technical content around the same underlying identity problem. That is typical for a large vendor summit, but the governance implications extend beyond the event itself.

Key questions

Q: How should IAM teams interpret developer summit content for identity governance?

A: They should treat developer summit content as an early signal of which access patterns will spread into production. The useful question is not whether the event is security focused, but whether it normalises service-account use, secret handling, and token-based access in ways that change your governance baseline. That makes the content relevant to NHI, workload identity, and lifecycle controls.

Q: Why do developer-led access models create NHI risk?

A: Developer-led access models often prioritise speed and integration over clear ownership, expiry, and offboarding. That creates long-lived tokens, scattered service accounts, and unclear responsibility for machine-held access. Once those patterns scale, IAM teams inherit a governance problem that looks technical but is really lifecycle and accountability drift.

Q: How can security teams use event agendas to spot identity gaps?

A: Look for repeated emphasis on APIs, workshops, certification, and hands-on sessions around authentication or service access. Those signals usually indicate where engineering teams are being trained to make access decisions. If identity governance is absent from the agenda, it often means controls will be bolted on later rather than designed in.

Q: What should organisations do after a summit focused on platform engineering and access?

A: They should convert the event’s themes into review items for service accounts, secrets, and privilege scope. The most useful outcome is a short list of patterns that need policy, ownership, or lifecycle control before they become default practice across environments.

Background and context

Developer summit access models and identity sprawl

Developer summits like this one usually surface the operational reality of modern platform access: multiple tools, multiple credentials, and different layers of trust for humans, services, and automation. The underlying problem is not the event itself, but the way API access, token use, and environment-level permissions are often handled as engineering conveniences. In practice, that creates fragmented identity boundaries that IAM teams later have to reconcile across cloud, CI/CD, and runtime systems.

Practical implication: map the access patterns discussed at the event to your service-account and token governance model before they are copied into production.

Certification training as a governance signal

Certification add-ons at technical summits usually signal that the topic is being operationalised for builders, not just discussed at a strategy level. That matters for identity because training content often determines what gets normalised in day-to-day implementation, especially around API authentication, secret handling, and operational access. Once those patterns become part of engineering muscle memory, they are harder to correct through policy alone.

Practical implication: review training curricula and workshop outputs as upstream inputs to your identity standards, not as standalone education.

What deep technical sessions mean for workload identity

Deep technical sessions can be the point where workload identity decisions move from theory to implementation detail. In environments built around APIs and services, the real control questions are how credentials are issued, how long they live, where they are stored, and which systems are allowed to act on their behalf. That is where NHI governance becomes concrete: secret sprawl, token lifecycle, and privilege scope are all part of the same control surface.

Practical implication: treat session outputs as requirements for your NHI lifecycle controls, especially rotation, scope review, and offboarding.

NHI Mgmt Group analysis

Developer conferences are governance events in disguise. The access models normalised in builder communities often become the default control assumptions later seen in production systems. That means IAM teams are not just governing current behaviour, they are also reacting to patterns already taught, copied, and scaled by engineering organisations. Practitioners should read summit agendas as indicators of where identity risk will emerge next.

API and workload identity now sit at the centre of platform security conversations. Events like this show that the centre of gravity has shifted away from human login experiences and toward service-level access, tokens, and runtime permissions. That aligns closely with OWASP-NHI and NIST CSF thinking, because the main governance problem is not authentication alone but the lifecycle of machine-held access. Teams should treat developer-led access models as part of the NHI programme, not a separate engineering concern.

Certification content influences control standardisation more than most security teams assume. When a vendor summit packages certification, workshops, and product sessions together, it helps define what practitioners consider normal implementation. That matters because identity policy often follows implementation habits rather than the other way around. The implication is that governance teams need earlier review points for engineering education, especially where APIs, service accounts, and secrets are involved.

Event packaging is a useful proxy for market direction. The combination of keynotes, workshops, and hands-on technical tracks suggests that identity-adjacent platform capabilities are being absorbed into broader developer operations rather than kept in isolated security tooling. For practitioners, that means governance has to keep pace with where access decisions are actually made. The field is moving toward embedded identity controls, and programme owners should plan accordingly.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That behaviour gap matters because 43% of security professionals are already concerned about AI systems learning and reproducing sensitive information patterns from codebases, according to The State of Secrets in AppSec.

What this signals

Developer-led access decisions are increasingly shaping the identity surface before security teams get a vote. That is the real signal in events like this summit: governance now has to inspect engineering norms, not just authenticate identities. If platform teams standardise token-based access, IAM programmes must decide where ownership, review, and retirement of those credentials actually sit.

Secret management remains the slowest-moving part of the machine identity stack. Our research shows the average estimated time to remediate a leaked secret is 27 days, which means exposure often outlasts the engineering sprint that created it. For readers, the takeaway is straightforward: lifecycle control, not policy language, determines whether an NHI programme can keep pace with developer practice.

Identity teams should expect more access patterns to be absorbed into platform engineering workflows. That makes workload identity, service-account governance, and secret handling a board-level architecture issue rather than a back-office control. Use the NIST Cybersecurity Framework 2.0 to align governance, protection, and recovery decisions around the same operational reality.

For practitioners

• Review developer training outputs for identity assumptions Ask platform and engineering teams which access patterns, token-handling habits, and secret-management practices are being reinforced in workshops and certification content. Use that review to catch identity assumptions before they become standard deployment patterns.
• Map API access patterns to NHI lifecycle controls Trace how service accounts, API keys, and machine tokens are created, reused, and retired across the systems discussed at the summit. Tie each pattern to ownership, expiry, rotation, and offboarding controls.
• Insert IAM review gates into platform engineering work Require identity architecture review before new platform workflows or developer enablement programmes are adopted. Focus on privilege scope, authentication method, and credential persistence rather than waiting for post-deployment remediation.
• Align workshop takeaways to workload identity standards Translate summit-level implementation guidance into explicit policy for workload identity, secret handling, and service-to-service authorisation. Where possible, anchor that policy to the NIST Cybersecurity Framework 2.0 and your internal NHI governance model.

Key takeaways

• Kong Developer Summit 2026 is relevant to IAM because it signals how developers are being trained to normalise API and workload access patterns.
• Identity governance risk emerges when service accounts, tokens, and secrets are treated as implementation details rather than controlled lifecycle assets.
• Practitioners should convert summit themes into policy review, credential ownership, and workload identity controls before those patterns spread further.

Key terms

• Workload Identity: Workload identity is the set of credentials and trust signals used by applications, services, and automated systems to authenticate and authorize themselves. In identity governance terms, it is not about a person logging in. It is about proving which machine or process is allowed to act, for how long, and under whose ownership.
• Service Account: A service account is a non-human identity created for a system, application, or integration to perform tasks without a human user behind it. Its security depends on explicit ownership, limited scope, and lifecycle control, because unattended credentials can outlive the workload they were created for.
• Credential Lifecycle: Credential lifecycle is the full path from issuance to retirement for secrets, tokens, keys, and certificates. For non-human identities, the lifecycle matters as much as the permission model because stale credentials often remain valid long after the original use case has changed or disappeared.

Deepen your knowledge

API access, workload identity, and secrets lifecycle are central topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are translating developer practices into identity controls, the course is a practical next step.

This post draws on content published by Kong: Kong Developer Summit 2026 in Los Angeles. Read the original.