What do organisations get wrong when they treat identity events as purely social networking?

Why This Matters for Security Teams

Identity events are often treated as relationship-building exercises, but security teams lose value when attendance is reduced to networking without decisions. The real risk is missed operational learning: patterns in secrets exposure, privileged access sprawl, and broken offboarding do not show up in slide decks alone. NHIMG research shows the scale of the problem, including the Ultimate Guide to NHIs finding that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

That matters because identity events are one of the few places where practitioners can compare how governance fails across AI access, privileged access, and infrastructure identity in real environments. When teams hear the same failure mode repeated across industries, they can validate whether their own controls are real or merely documented. The most useful discussions often link directly to control design, not vendor narratives, and should be grounded in current guidance such as NIST SP 800-207 Zero Trust Architecture and breach pattern analysis like the 52 NHI Breaches Analysis. In practice, many security teams encounter the real cost only after a secrets leak or privilege misuse has already forced an incident review, rather than through intentional peer exchange.

How It Works in Practice

Useful identity events translate discussion into operational artefacts. Instead of collecting business cards, teams should be comparing how they issue, rotate, and revoke credentials for agents, service accounts, and infrastructure workflows. The right questions are practical: Where are secrets stored? Who can approve standing access? How quickly does JIT access expire? What telemetry proves an identity event was actually authorized? Those questions align with the control intent described in NIST SP 800-63 Digital Identity Guidelines and with NHIMG guidance in the Top 10 NHI Issues.

In practice, teams get better outcomes when they use events to pressure-test three things:

• Whether NHI inventory is complete enough to support ownership, rotation, and offboarding.
• Whether privileged access policies are enforced at runtime or only reviewed after the fact.
• Whether AI and automation workflows use workload identity, short-lived tokens, and policy checks before tool use.

That operating model turns a conference conversation into a governance checkpoint. It also helps separate mature programs from those that only have awareness materials. Identity events become valuable when attendees leave with a backlog of control changes, not just contact lists, and when those changes can be measured against real-world exposures such as the Code Formatting Tools Credential Leaks pattern. These controls tend to break down when teams try to manage autonomous workloads with static human-style access reviews because runtime behaviour changes faster than the review cycle.

Common Variations and Edge Cases

Tighter event agendas often increase coordination overhead, requiring organisers to balance networking value against the need for concrete security outcomes. That tradeoff is real, especially when executives, practitioners, and vendors all attend for different reasons. Current guidance suggests the event still has value if it produces a shared control language, but there is no universal standard for measuring that value yet.

The edge cases usually appear when identity events are dominated by product messaging, or when the audience is too broad to discuss NHI governance in detail. In those settings, attendees may leave with general awareness but no actionability. The stronger model is to treat sessions as working groups around access governance, agentic workflows, and secrets hygiene, then record owners, deadlines, and follow-up reviews. That approach aligns with zero trust thinking in NIST SP 800-53 Rev. 5 Security and Privacy Controls and with incident pattern evidence from JetBrains GitHub plugin token exposure.

For teams focused on NHI risk, the key question is not whether the event was lively but whether it changed policy, ownership, or telemetry design. If it did not, it was networking only.

Related resources from NHI Mgmt Group

• What do organisations get wrong when they treat identity security as only an IAM or workforce problem?
• What do organisations get wrong when they treat PQC planning as a purely cryptographic upgrade?
• What do organisations get wrong when they treat partner enablement as a sales-only function?
• What do security teams get wrong when they treat channel enablement as separate from identity governance?