TL;DR: Cryptographic agility readiness is the ability to discover, govern, and rapidly update certificates, keys, algorithms, and libraries without disruption, according to Keyfactor, as organisations face fragmented inventories, manual renewal work, and post-quantum transition pressure. The real test is whether cryptographic change can happen at scale under policy, not whether teams can describe the risk.

NHIMG editorial — based on content published by Keyfactor: How to Assess Your Organization’s Cryptographic Agility Readiness

By the numbers:

• 69% of organisations now have more machine identities than human ones.
• Only 38% have automated certificate lifecycle management in place.
• 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface.

Questions worth separating out

Q: How should organisations assess cryptographic agility readiness?

A: Start with visibility, then test whether cryptographic change can be executed under policy without disruption.

Q: Why do fragmented cryptographic inventories create operational risk?

A: Fragmented inventories hide where cryptographic assets live, who owns them, and which business services depend on them.

Q: What do security teams get wrong about crypto agility?

A: They often treat it as a future migration project instead of a continuous governance capability.

Practitioner guidance

• Build a complete cryptographic inventory Map certificates, keys, algorithms, libraries, HSMs, load balancers, CI/CD pipelines, and cloud workloads into one authoritative record.
• Automate certificate renewal and revocation Replace spreadsheet-led renewal with policy-driven workflows that can renew, replace, and revoke certificates in bulk while preserving approvals for sensitive assets.
• Reduce hard-coded cryptography in applications Abstract algorithm choices away from code and device-specific trust roots where possible.

What's in the full article

Keyfactor's full guide covers the operational detail this post intentionally leaves for the source:

• A step-by-step readiness checklist for assessing cryptographic visibility across workloads, pipelines, and devices
• Detailed guidance on prioritising weak, expired, self-signed, or non-compliant certificates for remediation
• Operational patterns for policy-driven certificate lifecycle automation and bulk change execution
• Testing considerations for hybrid and post-quantum cryptography in non-production environments

👉 Read Keyfactor's guide on cryptographic agility readiness and operational assessment →

Cryptographic agility readiness: what IAM and PKI teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A step-by-step migration from homegrown SAML and OAuth/OIDC connections to WorkOS centers on auditing current SSO dependencies, choosing either per-connection reconfiguration or a proxy approach, and cutover planning for zero customer downtime, according to WorkOS. The real issue is not the migration path itself but the operational fragility of bespoke SSO logic and the governance it leaves behind.

NHIMG editorial — based on content published by WorkOS: Migrating from a homegrown SSO implementation to WorkOS

Questions worth separating out

Q: How should teams migrate homegrown SSO without breaking enterprise logins?

A: Start by inventorying every SAML and OAuth/OIDC dependency, then migrate one connection at a time or use a proxy if the tenant count is large.

Q: What breaks when a custom SSO implementation is too tightly coupled to tenant-specific IdP settings?

A: Changes to ACS URLs, NameID formats, redirect URIs, or claims mappings can break login for a single customer or a whole tenant.

Q: How do you know when an SSO migration is actually complete?

A: A migration is complete when every connection is active in the new system, old handlers receive no traffic, successful sessions continue across the customer base, and customer-facing setup guides point to the new admin flow.

Practitioner guidance

• Audit every SSO dependency before migration Document ACS URLs, SP Entity IDs, signing and encryption settings, NameID formats, redirect URIs, scopes, custom claims, and tenant identification logic before changing any flow.
• Separate migrated and legacy paths during cutover Keep a routing map that sends only verified connections to the new callback handler while leaving unmigrated tenants on the legacy path.
• Use the proxy pattern only with strict routing validation If you have many connections, preserve the existing callback URL as a proxy and confirm that every forwarded request retains the correct tenant context.

What's in the full article

WorkOS's full blog post covers the operational detail this post intentionally leaves for the source:

• Code-level examples for Next.js and Express callback handling across SAML and OIDC.
• WorkOS Admin Portal setup flow for IT admins who must reconfigure IdP connections.
• CSV import details for proxy-based migration when customer IdPs cannot be changed.
• Event monitoring examples using the WorkOS Events API and Datadog integration.

👉 Read WorkOS's migration guide for homegrown SSO to WorkOS →

Homegrown SSO migration to WorkOS: what changes for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Google’s exact-match redirect URI requirement creates operational risk for multi-tenant SaaS apps, where customer-specific domains, migrations, and manual console updates can trigger login failures or misconfigurations, according to WorkOS. Exact matching reduces one attack surface, but it shifts the burden to disciplined URI lifecycle management and safe proxy patterns.

NHIMG editorial — based on content published by WorkOS: Google OAuth's strict redirect URI matching, a guide for multi-tenant apps

Questions worth separating out

Q: What breaks when Google OAuth redirect URIs are not registered exactly?

A: Login flows fail with redirect_uri_mismatch errors because Google requires the authorization request callback to match the registered value character for character.

Q: Why do custom domains make OAuth callback governance harder?

A: Custom domains multiply the number of callback values that must be registered, tracked, and retired.

Q: How do teams know whether redirect URI management is under control?

A: A healthy programme can answer three questions quickly: which URIs are active, which tenant owns each one, and when each old callback will be removed.

Practitioner guidance

• Canonicalise redirect URI construction Treat the callback string as a constant and verify that the scheme, host, port, and path match the registered value exactly in every environment.
• Register new URIs before cutover Add the replacement callback to Google Cloud Console before DNS changes or tenant migration begins, then keep both URIs active through the transition.
• Retire old URIs with a documented delay Do not remove the previous callback until in-flight sessions have cleared and the new flow has been validated end to end.

What's in the full article

WorkOS's full article covers the operational detail this post intentionally leaves for the source:

• Exact redirect registration workflow for Google Cloud Console across tenant domains
• Migration sequence for keeping old and new callbacks live during customer cutover
• Proxy pattern trade-offs, including state handling and open redirect risk
• Practical checklist for monitoring redirect_uri_mismatch errors at scale

👉 Read WorkOS's guide to strict Google OAuth redirect URI handling for multi-tenant apps →

Google OAuth redirect URIs in SaaS: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Agent experience is the design layer between products and AI agents, and the source article argues that agents need explicit, structured, idempotent, machine-readable interfaces far more than human-oriented UX flourishes. The practical shift is that API parity, visible reasoning, and reversible actions become governance requirements, not polish, as agent-driven workflows scale.

NHIMG editorial — based on content published by WorkOS: Agent experience: How to design products that agents can actually use

Questions worth separating out

Q: How should security teams govern AI agents that use public APIs?

A: They should treat agent-facing API use as delegated execution, not ordinary application traffic.

Q: Why do UI-only workflows create risk for machine identities?

A: Because machine identities cannot reliably operate through visual interfaces, UI-only steps often force teams into browser automation or uncontrolled workarounds.

Q: What do organisations get wrong about agentic retries and idempotency?

A: They often assume a failed request means nothing happened, which is unsafe in agent workflows.

Practitioner guidance

• Map agent-facing actions to explicit API parity Inventory which product functions are only available in the UI and define API equivalents for each one that an agent may need to call.
• Require structured errors and typed responses Standardise error codes, response shapes, and field types so agent callers can branch deterministically instead of parsing free text or inferred status.
• Enforce idempotency on side-effecting workflows Use idempotency keys for create, send, modify, and delete actions that agents may retry.

What's in the full article

WorkOS's full article covers the operational detail this post intentionally leaves for the source:

• Specific API design patterns for agent consumers, including error object structure and schema conventions
• Examples of products that still depend on UI-only workflows and why that breaks agent automation
• Practical guidance on matching autonomy to reversibility for user-facing agent actions
• Implementation notes on OpenAPI and GraphQL schema quality for machine-readable consumption

👉 Read WorkOS's article on designing products agents can actually use →

Agent experience for AI agents: are your APIs ready for AX?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Auth.md introduces a discoverable registration path for agents using Markdown-based service instructions, protected resource metadata, and two registration flows that extend existing OAuth and JIT provisioning patterns, according to WorkOS. The shift is not new crypto but a new trust primitive for agent-initiated access, where identity and delegation have to be resolved before the agent can act.

NHIMG editorial — what this means for AI and NHI governance

Questions worth separating out

Q: How should security teams govern agent registration for non-human identities?

A: Security teams should treat agent registration as a governed onboarding event, not a convenience feature.

Q: Why do agent-initiated registration flows matter for IAM programmes?

A: They matter because they move the first trust decision from a human-driven browser flow into the service protocol itself.

Q: What breaks when agents can only register through human-style sign-up flows?

A: Agents stall at the moment they need to act, and the organisation responds by creating one-off endpoints, manual account creation, or shared credentials.

Practitioner guidance

• Map agent registration to an approved onboarding path Document which services may accept agent-initiated registration, which proof methods are allowed, and which business owners approve each flow.
• Separate verified and claimed flows in policy Treat identity-asserted registration and OTP-claimed registration as different trust levels.
• Bind credential issuance to lifecycle controls Require issuance records, expiry handling, and revocation hooks for every agent credential.

What's in the full announcement

WorkOS's full research covers the operational detail this post intentionally leaves for the source:

• Step-by-step auth.md file structure and the exact sections services need to publish
• Endpoint-by-endpoint integration guidance for /agent-auth, /agent-auth/claim, and /agent-auth/claim/complete
• Claim ceremony and OTP state-machine details for user-claimed registration
• Implementation notes for revocation handling and credential expiry behaviour

👉 Read WorkOS's agent registration guidance for auth.md and delegated access →

Auth.md for agent registration: what does it change for IAM teams?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: An IETF Internet-Draft on AI agent authentication introduces AIMS, a reference model that treats agents as workload identities using short-lived credentials, scoped tokens, and runtime authorization, according to Aembit. The real shift is that IAM assumptions built for human sessions and static service identities no longer fit actors that act, delegate, and re-evaluate context at runtime.

NHIMG editorial — based on content published by Aembit: AI agents are starting to look less like tools and more like participants

Questions worth separating out

Q: How should security teams govern AI agents that act on behalf of users?

A: Treat the agent as a non-human identity with its own lifecycle, ownership, and access policy.

Q: Why do AI agents complicate existing IAM and NHI controls?

A: They complicate control design because they can select actions at runtime, call multiple APIs, and move authority across systems without a human session boundary.

Q: What breaks when agents use long-lived API keys or shared credentials?

A: Ownership, accountability, and blast radius all become harder to contain.

Practitioner guidance

• Define agents as workload identities Model every agent as a distinct non-human identity with its own lifecycle, ownership, and access boundary.
• Scope credentials to specific actions Issue short-lived credentials that are tied to a narrow action set and a single execution context.
• Evaluate delegation at every hop Require policy checks whenever an agent acts on behalf of a user or passes authority to another system.

What's in the full article

Aembit's full post covers the operational detail this post intentionally leaves for the source:

• The draft's component-level AIMS model for identity issuance, attestation, credential presentation, and enforcement points
• The specific standards the article connects to agent delegation, including OAuth, JWTs, certificates, and workload identity
• The practical limitations the author calls out around runtime policy, multi-agent delegation, and operational complexity
• The article's view on why existing identity building blocks may converge into a shared agent identity pattern

👉 Read Aembit's analysis of AI agent identity and AIMS →

AIMS for AI agents: are your controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: SaaS environments are breaking traditional user access review models because access now spans distributed applications, service accounts, APIs, and rapidly changing permissions, according to SecurEnds. Access review programmes that assume stable roles and static systems can no longer keep pace with privilege sprawl, shadow IT, and orphaned access.

NHIMG editorial — based on content published by SecurEnds: cloud user access reviews across SaaS and cloud applications

Questions worth separating out

Q: How should security teams implement cloud user access reviews across SaaS and multi-cloud environments?

A: Start with a single inventory of identities, entitlements, and connected applications across your cloud estate, then segment reviews by risk and identity type.

Q: Why do SaaS access reviews often miss the highest-risk access?

A: They usually focus on named users and miss inherited permissions, shadow IT, and service accounts with long-lived privileges.

Q: What breaks when cloud access reviews are still run like on-premise recertifications?

A: You lose pace, coverage, and evidence quality.

Practitioner guidance

• Centralize entitlement inventory across cloud and SaaS platforms Pull identities, roles, permissions, and connected applications into one certification view so reviewers can see inherited and indirect access before approval decisions are made.
• Separate human, service, and shared account reviews Create distinct certification workflows for employees, service accounts, and shared credentials because each population has different ownership, expiry, and evidence requirements.
• Prioritize high-risk applications first Run more frequent reviews for production infrastructure, finance systems, customer data platforms, and administrator roles before expanding to lower-risk tools.

What's in the full article

SecurEnds' full article covers the operational detail this post intentionally leaves for the source:

• Platform-by-platform review patterns for Microsoft 365, Salesforce, AWS, GCP, ServiceNow, Slack, and GitHub
• Practical examples of which entitlements to certify in each environment, including admin roles, service accounts, and shared access
• Workflow guidance for automated review routing, escalations, and evidence capture
• Implementation detail on how to prioritize high-risk applications without losing governance coverage

👉 Read SecurEnds' analysis of cloud user access reviews across SaaS and multi-cloud environments →

Cloud access certification in SaaS: what IAM teams are missing?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Segregation of duties and separation of duties are often used interchangeably, but the distinction matters because SoD targets conflicting permissions while separation of duties distributes operational responsibility across people and teams, according to SecurEnds. Treating them as one control blurs audit, access, and accountability decisions.

NHIMG editorial — based on content published by SecurEnds: Segregation of duties vs separation of duties in cybersecurity and IAM

Questions worth separating out

Q: How should security teams implement segregation of duties in IAM workflows?

A: Start by mapping the high-risk actions that must never sit in one entitlement path, then enforce those conflicts at role design and provisioning time.

Q: Why do separation of duties controls fail even when policies exist?

A: They fail when the workflow still lets one person influence the full control chain, such as request, approval, and provisioning.

Q: What do organisations get wrong about segregation of duties reviews?

A: They often review titles instead of actual entitlements, so hidden conflicts remain inside roles, inherited permissions, and exception paths.

Practitioner guidance

• Define a formal SoD conflict matrix List the exact permission combinations that are prohibited across finance, IAM, PAM, and admin workflows, then review them whenever roles or applications change.
• Separate request, approval, and provisioning steps Ensure the person requesting access cannot approve it and the approver cannot provision it.
• Automate conflict detection across hybrid systems Use rule-based checks to flag risky access combinations in cloud, SaaS, ERP, and directory systems before they become audit findings.

What's in the full article

SecurEnds's full article covers the operational detail this post intentionally leaves for the source:

• Concrete examples of SoD controls in finance, IAM, HR, and privileged access workflows
• The article's comparison table showing where segregation and separation of duties overlap and diverge
• Compliance mappings across SOX, HIPAA, PCI-DSS, ISO 27001, and NIST
• Implementation guidance for automating conflict detection in hybrid environments

👉 Read SecurEnds's guide to segregation of duties vs separation of duties →

Segregation of duties vs separation of duties: what IAM teams miss?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Segregation of duties compliance is a core control for SOX, HIPAA, and GDPR, but manual reviews, access creep, and fragmented hybrid environments weaken its ability to prevent fraud and unauthorized action, according to SecurEnds. The control still matters, but it now needs continuous governance rather than periodic checking.

NHIMG editorial — based on content published by SecurEnds: segregation of duties compliance across SOX, HIPAA, and GDPR

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.

Questions worth separating out

Q: How should organisations implement segregation of duties in hybrid environments?

A: Start with a formal SoD matrix that maps prohibited combinations across finance, healthcare, cloud, and SaaS systems.

Q: Why do access reviews often miss SoD violations?

A: Because access reviews are snapshots, not continuous control points.

Q: What breaks when segregation of duties is not continuously monitored?

A: Toxic combinations can persist unnoticed in privileged, financial, and regulated-data workflows.

Practitioner guidance

• Map toxic combinations across business workflows Build an SoD matrix for finance, healthcare, and personal-data workflows, then define explicit conflicts such as create-and-approve or modify-and-audit.
• Embed conflict checks into provisioning Require automated SoD validation before access is approved or assigned in ERP, SaaS, and cloud administration workflows.
• Re-certify privileged access continuously Move privileged and high-risk accounts onto shorter review cycles with event-driven triggers for mover, leaver, and role-change events.

What's in the full article

SecurEnds' full article covers the operational detail this post intentionally leaves for the source:

• Specific examples of SoD conflicts in SOX, HIPAA, and GDPR workflows that teams can map to their own applications
• Step-by-step guidance for building and maintaining an SoD matrix across cloud, SaaS, and on-premise environments
• Practical recommendations for automating user access certifications and conflict detection in governance workflows
• Audit-readiness reporting patterns that show remediation history, approvals, and exception handling

👉 Read SecurEnds' guidance on segregation of duties compliance across regulated environments →

SoD compliance in hybrid IAM: where governance breaks down?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Cloud segregation of duties is harder to enforce in AWS, Azure, and GCP because permissions now shift through IaC, CI/CD, temporary elevation, and non-human identities, according to SecurEnds. The core governance problem is that static review models cannot keep pace with distributed cloud access, overprivileged workloads, and dynamic privilege changes.

NHIMG editorial — based on content published by SecurEnds: segregation of duties in cloud environments across AWS, Azure, and GCP

Questions worth separating out

Q: How should security teams implement segregation of duties in multi-cloud environments?

A: Security teams should define prohibited access combinations for each cloud platform, then enforce them before permissions are granted.

Q: Why do service accounts create segregation of duties risks in cloud IAM?

A: Service accounts create SoD risk because they often run continuously, inherit broad permissions, and are not reviewed with the same rigor as human users.

Q: What breaks when cloud access reviews do not include machine identities?

A: When machine identities are excluded, dormant service accounts, unused APIs, and overprivileged automation can keep working long after the business need has changed.

Practitioner guidance

• Define a cloud-specific SoD matrix List prohibited combinations for request, approval, deployment, production access, and audit authority across AWS, Azure, and GCP.
• Include non-human identities in access reviews Review service accounts, API keys, automation scripts, and workloads alongside human users.
• Separate privileged administration from audit oversight Ensure the same team or identity cannot assign high-risk roles and certify them.

What's in the full article

SecurEnds' full article covers the operational detail this post intentionally leaves for the source:

• Platform-by-platform SoD examples for AWS, Azure, and GCP IAM models
• Specific cloud governance patterns for separating admin, deploy, and audit responsibilities
• Operational guidance for handling service accounts, APIs, and automation identities in reviews
• Examples of SoD conflict detection and remediation inside cloud access workflows

👉 Read SecurEnds' analysis of segregation of duties across AWS, Azure, and GCP →

Cloud segregation of duties in AWS, Azure, and GCP: what breaks?

Explore further

View Full Forum →  |  NHI Foundation Course →