# Identity and Access Management in 2026: Seven Recent Changes

> Seven recent IAM announcements and release-note developments cover passkeys, token protection, non-human identities, access-review staging and delegated agent access, with release status and U.S. applicability explained.

- Canonical page: https://mtfinstitute.com/insights/identity-access-management-recent-changes-2026/
- Content type: Article
- Editorial category: Articles & Analysis
- Publisher: MTF Institute of Management, Technology and Finance
- Author: MTF Institute Research Team- Published: 2026-10-06
- Updated: 2026-10-06
- Language: English
- Topics: AI Agents, Identity and Access Management, Passkeys, Identity Governance, Workload Identity

*United States | Evidence reviewed 6 October 2026*

Identity and access management (IAM) work is changing on three fronts. A large identity provider is changing the default path from phone-based multifactor authentication to passkeys. A new US government report sharpens attention on the tokens and signing keys behind single sign-on and workload access. Identity vendors are announcing or listing ways to discover, assign owners to, review, and control non-human identities, including AI agents. These are dated announcements and release-note entries, though they do not prove that every US organization has adopted them.

This article examines seven dated announcements and release-note developments between 8 July and 6 October 2026. It uses official publications from NIST, Microsoft, Okta and SailPoint, independently of any vacancy sample. Product notes are evidence of a vendor's stated release stage, not a survey of US practice or proof that a feature reached a specific tenant. The practical question throughout is what an IAM team can verify in its own environment: which identities exist, what access they can exercise, who is answerable for them, and whether the authentication and authorization path behaves as designed.

## 1. Passkey migration has become a dated operational change

On 13 July, Microsoft announced that it would begin making passkeys the default authentication experience in Entra ID public-cloud tenants on 1 September. As the rollout reaches an in-scope tenant, users enabled for SMS or voice are auto-enabled for passkeys and prompted to register one after multifactor sign-in, unless the tenant uses Microsoft's temporary opt-out. Microsoft also announced a planned retirement of its own SMS and voice delivery, beginning for most affected users in February 2027, with a later July date for Global Administrators and external users. Its [dated announcement](https://www.microsoft.com/en-us/security/blog/2026/07/13/microsoft-entra-id-security-updates-passkeys-are-the-default-authentication-method-in-entra-id/) and [implementation page](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement) set out the cohort differences. The announcement explicitly says that other cloud environments have separate timelines.

That change turns passkey work into an inventory and migration problem. An IAM analyst first needs a reliable count of people who are enabled for, and actually depend on, SMS or voice. Those groups are not identical. Policy settings show permitted methods; sign-in evidence shows use. The analyst then needs to identify users whose devices and working conditions support a synced or device-bound passkey, and those who need a different approved route. A phased pilot should test enrollment, ordinary sign-in, account recovery and replacement devices before widening the campaign.

The status needs careful wording. September marks the start of a rollout, not proof of full adoption. Microsoft's [implementation page](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-sms-voice-retirement) allows tenants to delay automatic passkey enablement and registration-campaign nudges with a temporary opt-out during the temporary opt-out period ending February 1, 2027; it does not opt them out of 2027 enforcement. Without that opt-out, the registration nudge can be snoozed without a limit by default. A tenant may have users who have been enabled for passkeys but have never registered one. A useful operational measure therefore separates *eligible*, *prompted*, *registered* and *successfully using* passkeys. This keeps support staff from declaring a migration complete after changing a policy switch. Where telephony remains necessary, Microsoft describes a third-party provider path; that decision belongs in a documented exception population and tested sign-in route.

Security policy, registration prompts, recovery, communications and help-desk readiness have to agree. Enrollment failures can interrupt work, while widely available phishable fallbacks can undermine the intended change.

## 2. Tokens, assertions and signing keys received a new US reference

On 15 September, NIST announced the final [Interagency Report 8587, *Protecting Tokens and Assertions from Forgery, Theft, and Misuse*](https://csrc.nist.gov/news/2026/protecting-tokens-and-assertions-nist-ir-8587). Developed with CISA's Joint Cyber Defense Collaborative, the report addresses federal agencies and cloud service providers. NIST says the final version clarifies secure storage versus secure use of signing keys, bases key-validity considerations on system classification and transaction sensitivity, and adds workload-token considerations, including short-lived tokens in place of persistent secrets where appropriate. It also covers identity-provider and authorization-server architecture, verification and lifecycle controls.

This is a final publication, so it is a firmer reference than a draft or preview feature. Its direct audience is bounded, however. It does not establish that every private US enterprise is legally required to implement each recommendation, or that existing deployments already meet it. For non-federal IAM teams, its value lies in a disciplined review of the federated access path: who signs tokens, where signing keys live, which system can use those keys, how recipients validate issuer, audience, signature and lifetime, and what happens when a token or key must be withdrawn.

The distinction between a token and a password matters operationally. A user may complete a strong sign-in and still have an application accept a stolen, forged or overlong token. Conversely, an automated workload may never type a password, yet still hold a long-lived secret with wide permissions. IAM teams should trace both paths from issuance to resource access. Evidence should include configuration, a sample validation test, key rotation records, and a compromise procedure. The report's workload emphasis makes machine-to-machine access part of the same risk discussion as workforce federation.

NIST's SP 800-63-4 suite, published in 2025, remains useful background on assurance, authentication and federation. It is a baseline for interpreting the topic, not evidence of a new event during this study's 90-day period. [NIST baseline](https://pages.nist.gov/800-63-4/sp800-63.html)

## 3. Non-human identity discovery is moving into ordinary governance data

SailPoint's [11 September SaaS release notes](https://community.sailpoint.com/release-notes/saas/saas-release-notes-september-11-2026) describe production connectors that aggregate service accounts, API keys, stored credentials, agent tokens and registry tokens as non-human identities. JDBC and REST WebServices connectors gained a dataset model for agents, Model Context Protocol (MCP) servers and tools, including relationships and agent-owner correlation. The note says these features were released to production in SailPoint SaaS.

Previously scattered machine artifacts can now appear as inventory records with entitlements and relationships. A service account in a deployment platform, a token used by a build agent and an AI agent's connection to a tool may each have a different owner and revocation route. A review that displays only the account name can miss the effective chain of access. An analyst needs to know what the source connector can see, what it cannot see, whether the record maps to a real owner, and which underlying system grants the privilege.

Aggregation is a starting point. Connector coverage is specific to named systems, and discovering a key does not prove that its scope is appropriate or that its owner is current. A practical inventory should retain the source system, identity type, owner, purpose, granted resource, credential or token type, last observed use, creation and expiry dates when available, and the action required to disable access. Reconcile a sample against source systems to detect missing, duplicate and stale records. A newly visible agent with an apparently empty owner field is an investigation item, not automatically an orphan until the source and correlation rules are checked.

SailPoint also [announced general availability of Agentic Fabric on 4 August](https://www.sailpoint.com/press-releases/sailpoint-identity-security-solution), positioning it for AI and machine identity discovery, governance and control. This is a separate product announcement from the September connector release. The GA statement demonstrates vendor availability, while its promised security outcomes remain claims to test in a particular deployment. The article therefore does not use SailPoint's promotional percentages as estimates of US AI-agent access or risk. An IAM team evaluating such a product should ask for observed discovery coverage, false positives, owner assignment rules, review records, and a tested disable procedure.

Together, these two developments suggest a widening unit of governance. Human users still need joiner, mover and leaver controls. Machine identities need equally explicit creation, change, review and retirement, with special attention to the relationship among agent, tool, credential, human sponsor and resource. The product releases make that work more visible, but local evidence determines whether the control actually works.

## 4. Access-review campaigns can be staged before launch

Okta's [Identity Governance API release notes](https://developer.okta.com/docs/release-notes/2026-okta-identity-governance/) list early-access staging of certification campaigns as expected in Preview Orgs on 16 September. The stage can show targeted users, resources and reviewer assignments before a campaign starts. This is an emerging capability; the listing does not confirm deployment in a given tenant or establish a general production date.

The change matters because a review campaign can be formally completed and still yield poor evidence if it asks the wrong person to certify access, omits resources, or includes a stale population. Staging introduces a quality check at the point where the campaign can still be corrected. For example, an analyst can compare the staged scope with the approved application inventory, check whether the current manager or resource owner is assigned, and sample a few high-risk entitlements before launch. Mismatches should be logged and corrected in the authoritative source where possible, so the next campaign does not repeat them.

Early access status limits the conclusion. A US company using Okta may not have the feature. The workflow principle still holds: access-review evidence depends on accurate population, resource and reviewer mapping. Where the capability is available, its API makes a pre-launch check more explicit; it does not replace human judgment about whether access is justified or guarantee that a reviewer understands an entitlement.

Okta's September notes also list beta APIs for cancelling active or pending access requests. That illustrates a related lifecycle problem: a request can become unnecessary while it is still moving through an approval chain. Because those endpoints are beta and this article focuses on the stronger dated set above, they are supporting context rather than a separately counted trend. [Okta September notes](https://developer.okta.com/docs/release-notes/2026-okta-identity-governance/)

## 5. Agent-to-application access is acquiring explicit connections and release stages

Okta's [Identity Engine API release notes](https://developer.okta.com/docs/release-notes/2026-okta-identity-engine/) list agent single sign-on support for third-party OIDC requesting applications and OIDC or SAML resource applications as “GA in Preview,” expected in Preview Orgs on 30 September. They also list preview support for securing multiple MCP servers with a custom authorization server, and beta extensions to AI-agent profiles under that expected date. The same page records an August production-GA milestone for Cross App Access support for AI agents and applications. These entries have different scopes and release stages; the listing does not confirm September deployment in any tenant or production GA for agent SSO.

For an IAM practitioner, the core problem is delegation. An agent acting for a user needs an identifiable requesting application, an allowed resource, a defined authority, and a token path whose scope can be inspected. If an agent traverses several tools, the reviewer needs to know which identity initiated the action and which hop received what authority. A resource connection that exists in a catalogue but has no owner, test or revocation route is an incomplete control.

In an eligible preview tenant, a sensible validation is a bounded transaction: register one requesting agent and one resource application; approve only the required connection; exercise an authorized action; then try an action beyond the permitted scope. Inspect the records that show user context, agent identity, application, token audience and decision. This test demonstrates whether the full access path enforces the intended controls. Beta profile fields and mappings deserve extra checks because an incorrect provider-to-agent attribute may silently affect ownership or policy targeting.

## 6. Privileged workload connections expose the credential design choice

Okta's [Privileged Access API release notes](https://developer.okta.com/docs/release-notes/2026-okta-privileged-access/) list workload-principal SaaS account roles, API-key authentication for workload connections, and static JSON Web Key Set (JWKS) verification for workload connections as expected in Preview Orgs on 20 August. The features carry a GA label under the *Preview Orgs* column, with no expected production date in those rows. The listing does not confirm deployment in any tenant; the GA label does not override the preview-environment column.

Where available, these capabilities widen what a privileged-access operator may need to configure and review for non-human principals. API keys can be useful for connecting workloads, but the team must still set scope, protect storage, plan rotation and know how to revoke them. Static JWKS content can allow JWT verification where public key discovery endpoints are unsuitable, including some on-premises environments. It creates a key-maintenance obligation: if the trusted key set changes, the operator needs a controlled update and test. A misconfigured issuer or stale key could either block legitimate jobs or accept an unintended token.

This development intersects with NIST's September token report but is narrower. NIST offers US federal and provider-oriented implementation recommendations; Okta documents a particular product capability in preview organizations. Together they prompt a concrete review question: for each privileged workload connection, what evidence shows the identity of the caller, the validity and scope of its credential, the trust in its signing key, and the path to immediate disablement? The answer must come from the organization's configuration and logs, not from either publication alone.

## What the changes add up to

The seven announcements and release-note developments do not point to one universal IAM architecture. They show that IAM work spans more identity types and more moments in the access lifecycle. Microsoft gives a dated migration path for human authentication. NIST gives a final reference for the tokens that carry authority after authentication. SailPoint and Okta list ways to expose machine identities, agent relationships, review preparation and privileged workload connections in product workflows. The job for a US IAM team is to turn applicable capabilities and recommendations into verifiable local controls.

A useful operating review can ask five questions. First, who or what is the principal: a person, service account, workload or agent? Second, what resource and action are actually authorized, including delegation across applications? Third, who owns the identity and who can approve, review or revoke its access? Fourth, which credential or token carries that authority, and how is it issued, validated, rotated and ended? Fifth, what evidence shows the control works for a real transaction and a failed one? Those questions apply to a passkey migration, an access campaign and an agent connection without assuming that the same technology answers each one.

The main uncertainty is adoption. Release notes and vendor announcements establish available or planned capabilities, not US market penetration, incident reduction or typical employer practice. Several September Okta features are preview or beta. Microsoft describes a rolling public-cloud change and future retirement dates. This study did not inspect tenant configurations, measure user enrollment, survey organizations or compare product efficacy. It also found no separate, sufficiently verified 90-day CyberArk, FIDO Alliance or CISA event to count without stretching the evidence. Future versions should revisit production status and test the claims against observed implementation data.

### Method and source notes

The primary evidence window was 8 July–6 October 2026. Official pages were opened and checked for announcement dates or dated release-note entries, release stage, scope and geography. Seven items from four publishers met the threshold, so the window was not extended. Okta's dates are expected preview availability, not verified page-publication or tenant-deployment dates. The study is a targeted current-change analysis, not a prevalence estimate. The article is original synthesis with direct source links. NIST SP 800-63-4 (2025) is used solely as a baseline.



## Citation

When citing or summarizing this material, link to the canonical HTML page: https://mtfinstitute.com/insights/identity-access-management-recent-changes-2026/