Notifications
Clear all
Topic starter
06/07/2026 9:42 am
TL;DR: Restricted administration, admin UI federation and MFA, redirect URI policies, token signing key rotation, DKIM, and RESTCONF authorization for the Identity Server are covered in a how-to collection, according to Curity. The material reinforces that identity server administration is itself a high-value control plane, so access boundaries, signing key handling, and privileged workflow governance cannot be treated as routine.
NHIMG editorial — based on content published by Curity: Administration and related identity server how-to guidance
By the numbers:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.
Questions worth separating out
Q: How should security teams restrict access to identity server administration planes?
A: Security teams should isolate admin interfaces from general application traffic, require privileged authentication for every management path, and enforce explicit authorization for configuration changes.
Q: When does token signing key rotation become an operational risk?
A: Key rotation becomes risky when issuer and verifier are not coordinated.
Q: What do teams get wrong about federated login for admin users?
A: Teams often assume federation automatically makes privileged access safer.
Practitioner guidance
- Separate management-plane access from user-plane access Place admin UI, RESTCONF, and related configuration endpoints behind distinct network and identity controls.
- Bind admin access to strong federation and MFA Use federated login with multi-factor authentication for privileged administration, then constrain sessions with short-lived authentication state and explicit revocation handling.
- Run token signing key rotation as a coordinated change Treat signing key updates as an issuer-consumer coordination exercise.
What's in the full article
Curity's full how-to collection covers the operational detail this post intentionally leaves for the source:
- Step-by-step configuration examples for restricting administration access to the Curity Identity Server
- Specific guidance for enabling federated or MFA login to the admin UI
- Implementation details for token signing key rotation and safe JWT validation handling
- Configuration patterns for RESTCONF authorization rules, redirect URI policies, and DKIM setup
👉 Read Curity's administration guidance for identity server access and key rotation →
Curity identity server administration and token rotation controls?
Explore further
06/07/2026 9:58 am
Identity server administration is a privileged control plane, not an ordinary application surface. The Curity roundup is really about governance of the system that governs everyone else. Once an attacker or careless operator reaches token signing, redirect policy, or admin configuration, the resulting impact propagates across every connected client and service.
A few things that frame the scale:
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches, according to The 2025 State of NHIs and Secrets in Cybersecurity.
- Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.
A question worth separating out:
Q: Who is accountable for identity server policy changes and signing keys?
A: Accountability belongs to the team that owns the identity control plane, not just the application owners consuming its tokens. Policy changes, signing key updates, and administrative access decisions should be formally owned, logged, and reviewed as privileged changes with clear operational and security sign-off.
👉 Read our full editorial: Curity's admin access and key rotation guidance for identity servers
