Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: Identity, authentication, authorization, token handling, and API security are increasingly being framed as modular building blocks for enterprise security design, according to Curity. For IAM teams, the significance is that identity controls increasingly have to operate as an architectural layer rather than a point solution.
NHIMG editorial — based on content published by Curity: Security Architecture and Neo-Security Architecture
Questions worth separating out
Q: How should teams design identity architecture for both applications and APIs?
A: Teams should design identity architecture so authentication, authorization, token services, and federation are managed as shared controls rather than embedded separately in each application.
Q: Why do authorization decisions need dedicated governance in modern architectures?
A: Authorization now determines real access outcomes across APIs, services, and distributed systems, so it cannot be treated as an application detail.
Q: How can identity teams reduce security risk in modular architectures?
A: Identity teams can reduce risk by limiting duplicated access logic, centralizing policy where appropriate, and reviewing token and federation flows end to end.
Practitioner guidance
- Map identity services to control-plane responsibilities Document which components handle authentication, authorization, federation, token issuance, and user management, then assign ownership for each service boundary.
- Centralize authorization policy decisions Move access decision logic out of scattered application code where possible and into a common policy layer that can be reviewed, logged, and tested consistently across APIs and services.
- Review token and federation dependencies Trace how tokens are issued, validated, refreshed, and revoked across integrated systems, and confirm that each dependency has a clear lifecycle and audit trail.
What's in the full article
Curity's full article covers the architectural building blocks this post intentionally leaves at a higher level:
- Detailed explanation of the Identity Management System components and where each service fits in the architecture
- Curity's own breakdown of AuthZEN and how authorization exchange fits into API security design
- More context on how tokens, federation, and user management are combined in the neo-security model
- Additional glossary coverage for identity architecture terminology and related building blocks
👉 Read Curity's overview of neo-security architecture and identity building blocks →
Neo-security architecture and IAM: what does it change for teams?
Explore further
06/07/2026 9:55 am
Neo-security architecture is a governance model, not just an integration pattern. The article frames identity, authorization, and token services as reusable building blocks, which means security outcomes now depend on how those blocks are composed. That is the same structural problem IAM leaders face when trying to align human identity, NHI, and API access under one programme. The practitioner conclusion is that architecture decisions are now governance decisions.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most identity programmes still lack the inventory needed to govern modular access layers effectively.
A question worth separating out:
Q: What should practitioners check when identity becomes part of the architecture layer?
A: Practitioners should check ownership, logging, revocation, and lifecycle handling for every identity service that influences access. If those responsibilities are unclear, the architecture may look modular but still produce fragmented trust decisions. A strong review asks whether the identity layer can be operated, audited, and changed without breaking policy consistency.
👉 Read our full editorial: Neo-security architecture frames identity as the control plane
