TL;DR: 2025 updates to Connect added federation-based application registration, JIT user provisioning, issuer validation, certificate rescans, and workflow changes that reduce onboarding friction while tightening configuration correctness across identity operations, according to Raidiam. The governance challenge is shifting from manual control to proving that federation, claims, and certificate states stay accurate at scale.
At a glance
What this is: Raidiam’s year-in-review on Connect highlights federation, onboarding, issuer validation, and certificate controls that reduce manual handling while tightening identity correctness.
Why it matters: IAM and NHI teams need to see how federation and certificate workflows are becoming governance controls, not just operational conveniences, especially when trust state changes faster than review cycles.
Context
Federation and certificate governance matter because identity trust now changes through configuration, claims, and issuer state rather than only through human approval. When those values drift or get reused incorrectly, onboarding may still succeed but the trust relationship is no longer what operators assume.
Raidiam’s 2025 changes show a programme moving toward clearer validation, more explicit authority handling, and better lifecycle visibility for applications, servers, certificates, and users. The practical question for identity teams is whether their governance model can keep pace with self-service registration and automated trust updates without losing control of who or what is trusted.
For NHI governance, the important shift is that onboarding and certificate management are increasingly part of the control plane itself. That makes federation metadata, issuer uniqueness, and certificate revalidation core identity controls rather than back-office details.
Key questions
Q: How should teams govern federation-based application onboarding?
A: Treat onboarding as a trust decision, not just a registration task. Require federation metadata, issuer validation, and claim alignment before an application is allowed to participate in production trust paths. That keeps local configuration from drifting away from the identity relationship the ecosystem is actually using.
Q: Why does issuer uniqueness matter in federation and SSO workflows?
A: Issuer values identify who signs or vouches for tokens, so duplication creates ambiguity in validation and routing. If two servers share the same issuer, downstream systems can no longer rely on that value as a stable trust anchor. The result is configuration confusion that often looks like an integration bug until it becomes a governance problem.
Q: What breaks when certificate state is not continuously revalidated?
A: Revocation can lag behind actual authority state, which leaves inactive certificates visible in the platform and available to dependent workflows. That creates stale trust, weakens audit confidence, and makes lifecycle records less reliable for security review. Certificate state has to track issuing authority state, not just creation history.
Q: How do workflow controls help reduce onboarding errors for NHIs?
A: Guided workflows matter because they move validation to the point of entry. Inline checks, sequenced required fields, and immediate feedback reduce the chance that a server, certificate, or application is created with incomplete trust data. That is operationally important when onboarding volume increases and manual review no longer scales cleanly.
Technical breakdown
How federation-based application registration changes trust establishment
OpenID Federation replaces ad hoc client setup with a trust chain built from entity statements, entity configurations, and federation list endpoints. Instead of registering an application only through a local management API, the relying party can be validated through federation metadata that describes who it is, who vouches for it, and where trust should propagate. That changes the control boundary because onboarding is no longer just provisioning an object, it is establishing a verifiable trust relationship. In practice, this reduces manual drift but raises the importance of consistent metadata and issuer alignment.
Practical implication: Treat federation metadata as a governed trust artifact and validate it before permitting application onboarding.
Why issuer uniqueness and role metadata matter for configuration correctness
Issuer validation prevents two authorisation servers from presenting the same issuer value, which would otherwise make token validation and trust decisions ambiguous. The same logic applies to the expanded role metadata required for federation scenarios, where entity type, claim name, operator, and data type must all be explicit. These controls turn hidden assumptions into machine-checkable constraints. They also reduce the risk that roles or servers are reused in a context where their meaning no longer matches the federation model.
Practical implication: Enforce issuer uniqueness and federation-specific role metadata before allowing a trust relationship to go live.
How certificate rescans and soft-delete support lifecycle governance
Certificate rescan closes the gap between certificate issuance and certificate state. When the platform revalidates certificates against issuing authorities, it can reflect revocation without waiting for a separate administrative cleanup step. Soft-delete for certifications adds a similar lifecycle layer by preserving inactive records for review and reactivation instead of erasing them. Together, these changes improve auditability and reduce blind spots in trust operations. They also show that lifecycle state is part of governance, not just record keeping.
Practical implication: Use certificate revalidation and inactive-state handling to preserve evidence of trust changes and revocation history.
Breaches seen in the wild
- Coupang Signing Key Breach: Unrevoked signing key credentials expose 33.7 million records after employee offboarding failure at Coupang.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Federation is becoming the trust boundary for NHI governance. When application registration shifts into federation-based onboarding, the security question is no longer only who can create an object, but what evidence proves the object should be trusted. That moves governance upstream into metadata validation, issuer control, and claims alignment. Practitioners should treat federation policy as part of the identity control plane, not as a convenience layer.
Issuer uniqueness is a control, not an implementation detail. Duplicate issuer values create ambiguity in token validation and server identity, which is exactly where trust systems fail quietly. Raidiam’s issuer validation change reflects a broader market pattern: identity programmes are moving from permissive configuration to explicit trust constraints. The practitioner implication is to stop assuming server identity is self-evident and start enforcing it as a governed invariant.
Certificate rescans expose the cost of stale trust state. A certificate that remains visible after revocation creates a false sense of validity across dependent systems and review processes. Automatic revalidation narrows that gap by aligning platform state with issuer state, which is essential when certificates are used as trust anchors. The lesson for NHI governance is that lifecycle accuracy is a control objective, not an administrative preference.
Self-service onboarding only scales when the workflow itself carries governance. Guided wizards, inline validation, and immediate certificate download reduce operational friction, but the real value is that they move correctness checks to the moment of action. That is where NHI and federation programmes succeed or fail. Practitioners should see workflow design as a governance mechanism that either prevents drift or accelerates it.
OpenID Federation, issuer validation, and certificate revalidation together describe a runtime governance layer. This is the named concept that best fits the article: trust is being checked continuously through metadata, issuer state, and certificate state rather than only at provisioning time. That matters because identity ecosystems now depend on states that can change after onboarding. The implication for practitioners is to govern trust as a living system, not a static registration event.
From our research library:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: Ultimate Guide to NHIs — Standards
What this signals
Runtime governance layer: Federation, issuer validation, and certificate rescanning are converging into a control pattern where trust state must be checked at the moment it changes, not only when it is created. Teams that still treat onboarding as a one-time event will miss the lifecycle drift that appears after registration.
The governance signal here is that NHI programmes need explicit evidence for trust decisions across applications, servers, and certificates. Manual process alone cannot keep pace once registration, claims, and revocation move into self-service workflows.
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 gap is a reminder that configuration correctness cannot depend on memory or habit.
For practitioners
- Validate federation metadata before onboarding Require entity statements, entity configurations, and federation list references to be checked before an application is accepted into production trust paths.
- Enforce issuer uniqueness across authorisation servers Block any server configuration that reuses an issuer value so token validation and trust decisions remain unambiguous across the ecosystem.
- Make federation-specific role metadata mandatory Require entity type, claim name, operator, and data type before a role can be reused in any federation workflow.
- Revalidate certificates against issuing authorities Continuously check issued certificates for revocation status so the platform state matches authority state without waiting for manual cleanup.
Key takeaways
- Raidiam’s 2025 updates show that federation, issuer control, and certificate revalidation are now part of day-to-day identity governance.
- The main risk is stale or ambiguous trust state, especially when onboarding and validation become self-service and distributed.
- Practitioners should move checks into the workflow itself so trust decisions stay explicit, repeatable, and auditable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Federation registration and issuer validation directly govern how NHIs authenticate and are trusted. |
| NHI-05 — Overprivileged NHI | Automatic role assignment and federation metadata shape effective privilege scope. | |
| NHI-07 — Long-Lived Secrets | Certificate lifecycle and revocation handling are central to reducing stale trust material. | |
| Recommendation — Enforce federation and issuer controls to prevent weak or ambiguous NHI authentication paths. Review federation role metadata to keep NHI privilege scope aligned with claims and intent. Revalidate certificates and retire stale trust material as part of NHI lifecycle governance. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Role metadata and onboarding validation govern entitlements and authorisation boundaries. |
| Recommendation — Apply entitlement review to federation roles and server authorisations before production use. | ||
| NIST Zero Trust (SP 800-207) | Continuous verification | Issuer checks and certificate revalidation align with continuous trust verification. |
| Recommendation — Continuously verify trust attributes instead of relying on one-time onboarding checks. | ||
Key terms
- OpenID Federation: OpenID Federation is a trust framework that extends OIDC and OAuth 2.0 so organisations can verify each other through signed metadata and delegated authorities. It replaces many manual onboarding relationships with cryptographically verifiable trust chains, which is especially relevant in multi-party digital ecosystems.
- Issuer validation: Issuer validation is the check that ensures a trust source is unique, consistent, and acceptable before it can be used. For non-human identities, it helps prevent conflicting token trust relationships and reduces ambiguity in authentication and audit records.
- Certificate Revalidation: The process of checking an already issued certificate against its issuing authority to confirm whether it is still valid or has been revoked. It keeps platform state aligned with the certificate authority and reduces the risk of stale trust records surviving after revocation.
- Federation metadata: Federation metadata is the signed information that tells other parties how an identity or application should be trusted. In NHI governance, it becomes a control surface because issuer values, claim rules, and entity details determine whether registration and authentication behave correctly.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 27, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org