Notifications
Clear all
Topic starter
06/07/2026 9:36 am
TL;DR: The real issue is governance of the authentication boundary, not the plugin list itself, according to Curity. The key challenge is deciding where assurance, trust, and lifecycle control sit when login is mediated by multiple external identity sources.
NHIMG editorial — based on content published by Curity: authenticator plugins for login integration with the Curity Identity Server
Questions worth separating out
Q: How should security teams govern multiple authenticator options in one identity platform?
A: Security teams should treat each authenticator as a distinct trust path with its own assurance, recovery, and lifecycle rules.
Q: Why do federated login options create governance risk for IAM programmes?
A: Federated login creates governance risk when teams assume all authenticators are equivalent.
Q: What breaks when account linking is not controlled across authenticators?
A: Uncontrolled account linking can create duplicate identities, inconsistent recovery paths, and sessions that are hard to attribute during audit or incident review.
Practitioner guidance
- Define authenticator approval criteria Establish a written approval model for each authenticator type, covering assurance level, recovery path, data sharing, and the user populations allowed to use it.
- Map each authenticator to a policy tier Assign every login integration to a specific policy tier so the application knows when to allow step-up checks, fallback, or restricted access.
- Test account linking and recovery flows Exercise account creation, linking, password reset, and identity recovery paths across all enabled authenticators to confirm that the resulting session remains attributable and supportable.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- Specific plugin examples and the individual login providers they connect to
- Implementation-oriented examples of how each authenticator fits into the identity server
- The practical catalogue of supported authenticator options for teams evaluating integration paths
- Reference material for teams building or extending authentication flows in Curity Identity Server
👉 Read Curity’s guide to authenticator plugins for identity server login options →
Authenticator plugins for login: what do they change for IAM?
Explore further
06/07/2026 9:50 am
Authenticator choice is an authentication-governance decision, not a convenience feature. Curity’s plugin model shows that the control point is no longer just the login screen, but the trust relationship behind each authenticator. Once an identity server can delegate authentication to multiple external sources, IAM teams have to govern assurance, account linking, and recovery as first-class policy decisions. The practical conclusion is that authenticator inventories belong in identity governance, not in application teams’ ad hoc configuration notes.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
A question worth separating out:
Q: Who should own the lifecycle of external authenticators in IAM design?
A: IAM and identity governance teams should own authenticator lifecycle policy, even when the technical integration is delivered by application or platform teams. If an external login source changes assurance level, data-sharing terms, or revocation behaviour, the identity programme must decide whether that authenticator still belongs in the architecture.
👉 Read our full editorial: Curity authenticators show how social and eID login fits IAM
