Duo is joining PlainID's IDP Authorizer program. Your tokens are about to get smarter.

When a user authenticates through an IdP, the resulting token carries claims that downstream applications use to make access decisions. In most enterprise environments today, those claims are static. They reflect what was mapped at configuration time, not what the user should actually be able to do right now.

A user whose role changed this morning still carries yesterday's entitlements in their token. An employee who moved from Engineering to Sales still has access to developer tools until someone manually updates the IdP mapping. The token does not know what changed, it only knows what was configured.

Organizations that have invested in dedicated authorization engines like PlainID have already solved the "what can this user do" problem. They have policies, context, and real-time evaluation. But that investment only pays off if the IdP can call out to the authorization engine at token issuance time and inject those decisions as claims.

Duo has not supported this pattern. Until now.

We are partnering with PlainID to bring deeper dynamic authorization to Duo's access flows. Duo is joining PlainID's IDP Authorizer program, which means PlainID customers can use Duo as their identity provider without giving up fine-grained, policy-driven token enrichment.

PlainID evaluates authorization policies at authentication time and returns claims that Duo injects into the token before it reaches the application. Applications get context-aware access decisions without needing their own integration to PlainID.

The integration is powered by a new capability in Duo: Inline Hooks. These are synchronous callout points in Duo's token issuance pipeline that let external services enrich tokens and assertions with dynamic claims.

1. A user authenticates through Duo SSO

2. Before token issuance, Duo calls PlainID with user and session context

3. PlainID evaluates its authorization policies and responds with claims to include

The integration starts with token enrichment and assertion modification:

• Token Inline Hooks: Enrich OIDC/OAuth tokens with dynamic claims from PlainID at issuance time

• SAML Assertion Inline Hooks: Modify SAML assertions with dynamic attributes before signing

External Authorization Hooks, which route runtime permit/deny decisions to PlainID for use cases like MCP tool access, will follow as the platform matures.

The underlying hook platform is engine-agnostic by design. PlainID is our first partner and validates the pattern, but the contract works with any HTTP-based policy decision point.

For teams running PlainID today: You no longer need to choose between Duo and your authorization investment. Duo handles identity. PlainID handles what users can do. The hook connects them at the moment it matters most.

For teams migrating to Duo: Token extensibility has been a blocker for some organizations. With this integration, that blocker is going away.

For teams planning for AI agents: As agents interact with enterprise systems, authorization decisions get more complex, not less. Having PlainID's policy engine available during Duo authentication flows means those decisions can be made consistently whether a human or an agent is requesting access.

Token and SAML Assertion Inline Hooks are entering Alpha (limited availability with select design partners for validation and feedback) soon. We will be working with design partners to validate the integration before broader availability.

This is early, and we are sharing it now because the partnership is real, the architecture is taking shape, and we want to hear from teams who have been waiting for this.

This integration expands on Duo’s list of hundreds of technology partnerships. You can learn more about our complete ecosystem of integrations at ecosystem.duo.com.

If you are interested in participating as a design partner, or if PlainID integration has been a factor in your identity strategy, reach out to your Duo contact today and get connected with the Duo Product team.

Enterprise identity has changed a lot over the last few years.

Users are no longer sitting behind a single network perimeter, accessing a small set of applications from managed devices. Today, they work from anywhere. Applications sit across SaaS, private data centers, cloud platforms, and partner environments. Devices can be managed, unmanaged, personal, mobile, or sometimes simply unknown.

And then there are the identities.

Human and non-human identities (NHIs), such as service accounts, SaaS accounts, cloud identities, legacy accounts, and now even AI-driven workflows are adding to the mix. Identity sprawl has become one of the biggest challenges security teams are trying to solve.

Attackers have noticed this shift too. They are not always trying to force their way in through exposed infrastructure. Increasingly, they are logging in with valid credentials, abusing excessive privileges, hijacking sessions, and blending into everyday user activity.

That means identity can no longer be treated as a one-time login check.

We need to know which accounts exist, how they are being used, what sessions are active, and whether the level of trust should change as risk changes.

In simple terms, we need to secure every account and every session. Three identity security challenges teams face

When we talk to customers about identity security, three (3) challenges usually come up.

Fragmented identity visibility: Most organizations have more than one identity source. There may be Microsoft Entra ID, Active Directory, SaaS directories, cloud accounts, privileged accounts, service accounts, and third-party identities. Each system has its own view of users, permissions, activity, and risk. The security team is often left trying to piece it all together manually and understand overall identity posture along with this.

Inconsistent access enforcement: Organizations usually have security controls in place, but they do not always work as one system. MFA may sit in one place. Device posture may be checked somewhere else. SaaS access, private app access, and network access may all follow separate policy models. That makes it hard to apply zero trust consistently across users, devices, applications, and environments.

Static decisions in a dynamic world: A user may pass MFA in the morning and get access. But what happens if the account starts behaving unusually later in the day? What if the device posture or device location changes? What if the session becomes risky? What if an account has more privileges than it should?

Identity risk is not static. So, security cannot afford to be static either.

This is where zero trust needs to evolve from a one-time authentication decision into a continuous, per-session context-aware model.

Identity becomes the new control plane.

Cisco brings a platform approach to identity security by connecting identity visibility, access enforcement, network control, and threat response through Cisco Security Cloud.

At the center of this approach is Cisco Identity Intelligence, which helps organizations understand identity activity, discover risky accounts, identify excessive privileges, and close the gap between authentication and access.

But visibility on its own is only half the job. The real value comes when identity intelligence can drive action.

• Cisco Duo helps verify trusted users and trusted devices with strong MFA, device trust, posture checks, and risk-based access.

• Cisco Secure Access extends identity-aware enforcement across SaaS, internet, and private applications, helping users reach the applications they need without giving them broad access to everything behind the network.

• Cisco ISE brings identity deeper into the network, supporting identity-based access for campus, branch, wireless, wired, VPN, and segmentation use cases.

• Splunk helps bring identity signals together with broader security telemetry, giving teams better context to detect, investigate, and respond faster across the environment.

Together, these capabilities help organizations move away from static access decisions and toward continuous identity security.

Not just: did the user log in?

But: is this account trusted, is this device healthy, is this session behaving normally, and should this access continue?

Let’s make this real.

Imagine a finance user accessing a sensitive application.

In a traditional model, the decision may be fairly simple. The user belongs to the Finance group. MFA is complete. Access is allowed.

That is useful, but it does not tell the whole story.

With Cisco, the decision can include much richer context.

1. Duo verifies the user and checks whether the device is trusted and healthy.

2. Cisco Identity Intelligence looks at the account itself. Is this identity behaving normally? Does it have excessive privileges? Has it shown unusual access patterns? Is there a signal that should change the access decision?

3. Cisco Secure Access applies the right policy at the application level. If the user, device, and session look trusted, the experience stays simple. If something looks risky, access can be challenged, limited, or blocked.

4. Splunk can correlate that identity activity with other security signals from across the environment. This helps the security team understand whether the event is isolated or part of a larger attack path.

That is the balance customers are looking for: tighter control when risk is high, and a smoother experience when trust is strong.

Cisco’s approach is different because identity is not treated as a standalone control.

Identity connects to access.
Identity connects to the network.
Identity connects to threat response.
And identity connects to the broader security operations workflow through Splunk.

Every account needs visibility. Every session needs context. Every access decision needs risk awareness. And every control point needs to work together.

This matters even more as organization adopt more SaaS, more cloud, more remote access, more third-party users, and more AI-driven workflows. The number of identities will keep growing. The number of sessions will keep increasing. And attackers will keep looking for the weakest identity path within the ever-growing attack surface.

The answer is not to add yet another disconnected identity tool and create more work for already stretched security teams. The answer is a connected security platform that can see identity risk early, enforce the right access policies, extend control into the network, and help teams respond to incidents faster.

Organizations should assess where identity visibility gaps, inconsistent access policies, and unmanaged risks exist across their environment, and explore how Cisco and its partners can help build a connected zero trust architecture that protects every account and every session. Learn more about our zero trust solution.

For years, multi-factor authentication has been the baseline for protecting accounts, but not all MFA is created equal. Attackers have grown adept at phishing their way past weaker methods like SMS, phone calls or one-time passcodes, tricking users into handing over the very factors meant to keep them safe. In response, Duo continues to invest in phishing resistant authentication like passkeys and Duo Mobile Proximity Verification to make sure our customers are able to widely adopt these methods and better protect your organizations.

Phishing-resistant authentication is moving from a best practice to a hard requirement for many, starting with the accounts that matter most: your administrators and privileged users.

Salesforce is now one of those platforms. Beginning July 20, 2026 Salesforce requires phishing-resistant MFA for all privileged users in production, including anyone with the System Administrator profile or permissions like Modify All Data, View All Data, Customize Application, or Author Apex. This applies whether those users log in directly to Salesforce or through a single sign-on (SSO) provider.

Note: Duo’s Microsoft integration using Azure Conditional Access Custom Control does not provide Authentication Method Reference (AMR) signals required during authentication by design. Please make sure to migrate your privileged users to the new Duo Entra ID External MFA integration or Duo SSO for Salesforce as soon as possible to avoid user lockout.

In practice, this means the methods many admins rely on may no longer get them in the door. Legacy factors like SMS passcodes, phone callbacks, and one-time passcodes don't meet the bar for phishing resistance, and users relying on them will be prompted to enroll a stronger method. For organizations logging in through an identity provider, Salesforce doesn't dictate the specific tool. Instead, it looks for a signal from the IdP confirming that a phishing-resistant authentication took place. The takeaway for admins is simple: the era of "any MFA will do" is over, and it's time to make sure your privileged users are authenticating with phishing-resistant methods.

The good news: meeting Salesforce's bar doesn't require ripping out everything. Duo offers two phishing-resistant options that you can roll out side by side, depending on what fits your users.

Passkeys (platform and roaming authenticator) are the industry standard for phishing-resistant authentication, built on the open FIDO2/WebAuthn specification. What makes them phishing-resistant is simple: a passkey registered for Salesforce only works for Salesforce. If a user lands on a malicious login page, the passkey just won’t work there.

Duo Mobile Proximity Verification is our proprietary solution on phishing-resistant authentication, designed for organizations that heavily depend on Duo Mobile, and love the user experience! With Duo Desktop doing origin binding and Bluetooth handshake between the Duo Desktop and Duo Mobile confirming the user has access to both devices, Duo Mobile Proximity Verification protects users from common phishing attacks such as social engineering and attacker-in-the-middle style attacks.

Both methods are governed through Duo's authentication methods policy, so enabling phishing-resistant auth for your Salesforce admins is a group policy change, not a project. Scope it to your privileged-access group, set the allowed factors, and the policy does the rest. Users keep the Duo experience they already trust; you get a clean signal back to Salesforce that a phishing-resistant authentication took place without disrupting your admins' workflow.

The July 20, 2026 deadline is a forcing function, but it doesn't have to be a fire drill. Salesforce is asking for a stronger signal at the front door for your most sensitive users, and Duo is built to deliver exactly that signal, without massive undertaking.

Whether your organization standardizes on passkeys, leans on Duo Mobile Proximity Verification, or deploys both across different user populations, Duo gives you the policy controls to roll out phishing-resistant MFA at the pace your business can absorb. Group-based policies mean you can start with your System Administrators and expand coverage to other privileged roles over time - all from the same Duo Admin Panel your team already operates in.

This is the partnership we want to be for our customers: helping you stay ahead of mandates like Salesforce's while protecting the user experience that keeps adoption high and helpdesk tickets low. Phishing resistance shouldn't come at the cost of usability, and with Duo, it doesn't have to.

Experience Duo's seamless authentication with a quick interactive Proximity Verification product tour, or get started adding phishing resistance with a 30-day free trial.

When it comes to multi-factor authentication (MFA), not all methods provide the same level of protection. Telephony-based MFA, including SMS passcodes and phone callback verification, was once considered a reliable and accessible option. Today, evolving security standards and an increase in sophisticated cyberattacks has rendered these methods increasingly vulnerable, and many organizations are replacing SMS MFA with stronger alternatives like Duo Push notifications, security keys, and biometric authentication.

This blog post explains why telephony-based MFA is no longer sufficient, what stronger MFA options are available, and how to migrate your organization away from telephony methods step by step. Whether you are just starting to evaluate the change or ready to execute, this guide gives you a clear path forward.

Explore the versatility of Duo’s authentication methods and how they support a modern security strategy.

Phone call and SMS-based MFA methods are vulnerable to several well-documented attack techniques. These include:

• SIM swapping: Attackers convince a carrier to transfer a phone number to a new SIM card, intercepting all SMS codes sent to that number.

• Phishing: Fake websites trick users into entering one-time passcodes, which attackers capture and use in real time.

• Social engineering: Phone scams manipulate users or carrier support staff into revealing information or approving fraudulent requests.

• Message interception: Attackers exploit weaknesses in telecommunications protocols to intercept SMS messages in transit.

These are not theoretical risks. While the National Institute of Standards and Technology (NIST) encourages organizations to adopt phishing-resistant authentication methods, Duo specifically recommends moving away from telephony-based MFA such as SMS and phone calls due to vulnerabilities like SIM swapping and message interception. Federal cybersecurity guidance and many cyber insurance policies increasingly require stronger, phishing-resistant MFA to protect critical systems and data.

Beyond security, telephony-based MFA carries ongoing costs. Every phone call and SMS message used for authentication incurs a per-transaction fee. For organizations with large user populations, these costs add up quickly compared to push-based or token-based methods that do not rely on telephony infrastructure.

User experience is another factor. Missed calls, delayed SMS codes, and poor cellular reception create friction that frustrates users and increases help desk ticket volume. Is two-factor authentication with SMS still safe enough for your organization? For most, the answer is no.

Cisco Duo offers several authentication methods that provide better security, lower cost, and a smoother user experience than phone call and SMS. Understanding the types of multi-factor authentication available helps you choose the right fit for your organization.

Duo Push and Verified Duo Push
Duo Push sends a login request directly to the Duo Mobile app on a user's smartphone, and the user taps to approve or deny. Verified Duo Push adds a verification step by requiring the user to enter a code displayed on the login screen, which helps prevent accidental approvals. Push-based authentication eliminates the SMS channel entirely, removing the risk of SIM swapping and message interception.

Security keys and FIDO2/WebAuthn
Hardware security keys use cryptographic authentication that is bound to the specific website requesting it. This makes them phishing-resistant by design because the key will not respond to a fraudulent site. FIDO2 and WebAuthn are the open standards behind this technology

Biometric authentication
Fingerprint and facial recognition verify identity using something the user is, rather than something they know or receive. Biometric methods are fast, convenient, and difficult to replicate remotely.

Hardware tokens
Hardware tokens generate one-time passcodes without relying on a phone or network connection. While they carry an upfront cost, they eliminate the ongoing per-transaction fees associated with telephony.

The benefits of MFA improve significantly when organizations move from telephony to these stronger methods. Push-based and phishing-resistant options reduce risk while also reducing friction for users and costs for the organization.

This section walks you through the process for retiring phone call and SMS authentication in your Cisco Duo environment. These six steps are based on real-world experiences supporting organizations navigate this transition successfully. Each step includes the rationale behind it and guidance for executing it in your Duo Admin Panel.

A note before you begin: Every organization is different. Use these steps as a framework and adapt the details to fit your user population, directory configuration, and support capacity.

Before making any policy changes, you need a clear picture of who is currently authenticating with telephony methods. This allows you to scope the migration accurately and avoid surprising users with unexpected changes.

Use the Authentication Log in your Duo Admin Panel to identify these users:

• Navigate to Reports and open the Authentication Log.

• Set filters for two-factor authentication (2FA) methods, selecting Phone Call and SMS Passcode.

• Adjust the time range to capture as many unique users as possible. A 30 to 90 day window is a good starting point.

• Export the filtered log to compile your list of unique telephony users.

Group your identified telephony users together so you can manage their transition incrementally. This exemption group allows these users to continue using phone call and SMS while you work through the migration, without affecting users who already use stronger methods.

• If your users are managed directly in Duo, create a new user group in the Users section of the Duo Admin Panel.

• If your organization syncs a directory to Duo, create the group in your directory.

• Add all telephony users identified in Step 1 to this exemption group.

Before you disable telephony methods globally, you need to make sure users in the exemption group can still authenticate. Create a custom policy that allows phone call and SMS and apply it to the exemption group.

• Create a new policy: Navigate to Policies, select Add Policy, and give it a clear name such as "Telephony Exemption Policy."

• In the Authentication Methods section, enable Phone Callback and SMS Passcodes along with any other methods your organization allows.

• Save the policy.

• Apply the policy to the exemption group: Navigate to Policies, locate the new policy, select Actions, and then Apply. Choose the exemption group and reorder policies as needed for your configuration.

Now disable telephony methods in the Global Policy. This change will have minimal impact because the users affected are already authenticating with non-telephony methods. It also prevents anyone from migrating backward to telephony during the transition.

• Navigate to Policies and open the Global Policy editor.

• Under Authentication Methods, uncheck SMS Passcode and Phone Callback.

• Save the policy.

Communicate before you save. Even though this change primarily affects users who do not rely on telephony, it removes the option from their login screens. Let affected users know in advance using Duo's prepared communication templates for policy enforcement changes.

This step is the most people-focused step. Map out how and when you will migrate the exemption group to stronger authentication methods.

Decide on your approach. You can migrate all remaining telephony users at once or in phases. Consider the following factors:

• How many users are in the exemption group

• What devices your users have access to (smartphones, security keys, hardware tokens)

• How much help desk capacity you have during the transition period

• Whether certain teams or departments should migrate before others

A phased approach gives you room to communicate effectively, help users adjust, and catch issues before they affect the entire group. A simultaneous cutoff can work for smaller groups but risks higher help desk volume and user frustration if problems arise.

Set clear deadlines. Define when phone call and SMS will be disabled for telephony users and communicate those dates early and often.

Draft your communications. Include the following in your messages to affected users:

• What is changing and why

• Instructions for switching to a stronger method like Duo Mobile

• How to obtain a security key or hardware token if applicable

• The transition timeline with specific dates

• Where to get help

Duo provides a "Promoting Duo Push" knowledge base article with additional resources to support this campaign.

As users in the exemption group switch to stronger authentication methods, remove them from the group. When project deadlines arrive, remove any remaining users.

• Monitor the exemption group and remove users as they confirm successful enrollment in a new method.

• Once the group is empty and all users are authenticating with non-telephony methods, delete the custom exemption policy. The Global Policy now applies to everyone.

• Review the Authentication Log after the final cutoff for any login issues related to the change.

The technical migration is only half the work. Clear, empathetic communication makes the difference between a smooth transition and a flood of help desk tickets.

Keep these MFA best practices in mind when communicating with end users:

• Lead with the why. Help users understand that this change protects them and the organization, not just that IT decided to change something.

• Use plain language. Not every user knows what SIM swapping or phishing-resistant MFA means. Explain the change in terms they relate to.

• Give them time. Announce the change well before deadlines so users can transition at their own pace.

• Make it easy. Provide step-by-step instructions for enrolling in Duo Push or setting up a security key. Link directly to the resources they need.

• Offer support channels. Tell users exactly where to go if they need help, whether that is a help desk ticket, a Slack channel, or a dedicated FAQ page.

Duo provides communication templates you can customize for your organization.

Moving away from telephony-based MFA is a significant project, and you do not have to do it alone. Duo Care is Duo's dedicated support program designed to help your team through every stage of your security journey, including migrations like this one.

With Duo Care, your organization gets:

• Personalized planning and guidance from a dedicated team that understands your environment and helps you build a migration plan tailored to your users, applications, and goals.

• Access to experienced security professionals who provide best practices, answer technical questions, and help troubleshoot challenges throughout the project.

• Proactive health checks that review your Duo account regularly, helping you identify potential issues before they affect users and keeping you informed about new features and recommendations.

• Reduced disruption and faster adoption through expert-guided deployment, which minimizes help desk tickets and user frustration.

• Training and enablement resources so everyone in your organization, from IT administrators to end users, feels confident and prepared.

Get started with Duo Care to plan your telephony migration.

Agentic AI is rapidly changing the world, creating opportunities for growth and innovation we couldn’t even have imagined just a few years ago. And threat actors are taking notice, using these same advanced AI models to penetrate an expanding threat surface, take over systems, steal sensitive information, and create chaos in their wake.

It’s clear we’re at a tipping point in the industry where fast-moving, AI-led innovation on both sides of the fence is putting immense pressure on people like us who are tasked with securing this brave new world. Trust in identity has never been more critical.

The Cisco Duo Identity Summit brings together industry experts to bring clarity and trust to identity into your organization in 2026 and beyond. We will unpack the exact trends shaping the current threat landscape, while learning how to secure the new agentic workforce, defeat advanced social engineering attacks, achieve true phishing resistance and how to, ultimately, create trust across your organization. If you are responsible for identity and access management at your organization, you’ll want to be there.

The event promises more than great speakers and content. The virtual experience will be filled with interactive features, peer-to-peer networking opportunities, and an extensive resource library to keep you engaged during and after the event. We’ll even be rolling out a new identity-focused, Space Invaders inspired 8-bit video game that attendees will be able to play between sessions. The person with the highest score at the end of the day will earn bragging rights and win one of our signature green Duo shirts.

• Keynote: Identity Security for the Agentic Era I’ll be kicking it off in the keynote. The identity threat surface is outpacing traditional access controls as automation, identities, devices and applications continue to multiply. The rise of Agentic AI is changing how work gets done, and it is also changing how attackers operate. My keynote frames identity not as a checkpoint, but as a foundational and living trust layer across the enterprise. I’ll explore where identity is headed, why trust must be continuously earned and how to prepare for AI-driven risk.

• Identity Security at Work: How Box Balances Security and Productivity including Akhila Nama, Global Head of Enterprise Security at Box.

• Securing Identity at Scale: The School District of Philadelphia’s Path Forward with Andrew Speese, Deputy CISO at the School District of Philadelphia.

• Outsmarting AI-Driven Social Engineering Tactics with Cisco Talos’s Joe Marshall, and experts from Persona. Learn about the current top social engineering tactics and how to stop them in their tracks.

• Technical Masterclass: Deployable End-to-End Phishing Resistance with Danny Paul, Cisco – We all know we need end-to-end phishing resistance, but complexities and high costs prevent many organizations from doing everything they can to stop this common threat. Danny Paul walks us through the process of making enrollment easier and more seamless so we can improve adoption.

• Is Active Directory still your Weak Link? With Joe Duggan. As agentic AI expands the identity threat surface, trust has to be continuously earned across every user, device, application, and agent, making Active Directory protection even more urgent.

• A Zero Trust Playbook for the Agentic Workforce with Chris Anderson, Cisco – Agentic AI has moved artificial intelligence from the sandbox to the real world. But what does this mean for identity in this brave new world? Cisco’s Chris Anderson walks us through how identity is changing and why trust is becoming your greatest asset in the age of AI.

Duo is a mainstay in the identity world and we're happy that we can pull so many awesome speakers and attendees together for a day of honest and enlightening conversation and presentations. Genuinely looking forward to this event and kicking it off on Wednesday, June 24 with all of you. Please join us.

At RSAC 2026, we introduced Duo Agentic Identity—identity, authorization and audit purposed for AI agents operating at machine speed across enterprise environments. The launch laid out three capabilities that together close the agent governance gap:

• Discovery, built on Cisco Identity Intelligence, to surface every agent in your environment, including the shadow ones you didn't know existed.

• Identity lifecycle, built on Duo Directory, to make every agent a first-class non-human identity tied to an accountable human owner.

• Least-privilege authorization, enforced at every tool call through a gateway that intercepts agent requests and evaluates them against Duo's fine-grained authorization policy engine.

The first two capabilities are infrastructure-agnostic by design. Today, we're closing the loop on the third: per-tool-call authorization now works with different AI gateways you run.

Since RSAC, the agent infrastructure landscape has only diversified. Enterprises aren't converging on a single gateway. Teams are choosing infrastructure based on their cloud provider, existing stack, and operational maturity. Some are deploying open-source gateways for new AI projects. Others are extending service mesh infrastructure they already run, or building on cloud-native platforms like AWS. And many are running Cisco Secure Access alongside the rest of their security fabric.

One question we kept hearing from customers: How do I get consistent identity and authorization controls when my agent infrastructure is diverse?

Without a consistent answer, organizations face a familiar set of risks amplified by machine speed: over-privileged agents accessing tools they shouldn't, no audit trail connecting agent actions to accountable humans, and inconsistent controls that vary gateway by gateway. The same compliance gap that plagued human access a decade ago is now emerging in the agent layer—except agents operate 24/7 and execute in milliseconds.

Gateways handle routing and enforcement well, but routing alone doesn't answer the critical question: who should be able to access which tools, and on whose behalf?

Duo Agentic Identity is expanding to serve as the authorization engine for any agent gateway. The architecture is simple: Duo decides; your gateway enforces. Regardless of which gateway sits between your agents and your tools, Duo provides the identity and authorization intelligence behind every decision. This means per-tool-call authorization; not just "can this agent connect to this server," but rather "can this user's agent invoke this specific tool on this specific server, right now." Authorization decisions are made in real time, based on Duo group membership and the fine-grained policies you define.

Further, every tool call produces an identity-correlated audit log: human → agent → tool → action. This complete chain of accountability maps every autonomous action back to a human identity. Built on OAuth 2.1 and OIDC, the integration is standards-based and works with the MCP clients your developers already use: VS Code, Cursor, Claude Code, and custom agents, alongside emerging protocols as the ecosystem evolves.

Duo is shipping an authorization connector that plugs directly into supported gateways. No proprietary lock-in required to get enterprise-grade authorization.

Not every organization is ready for a fully managed gateway, and they shouldn't have to be. Duo meets you where you are:

• AgentGateway or Envoy: Deploying a new AI project from scratch? Install the Duo Authorization Connector and get per-tool-call access control in minutes.

• AWS Bedrock AgentCore: Building on AWS? Duo integrates as the identity provider with gateway interceptors that enforce fine-grained policy on every tool call.

• Arcade.dev: The actions runtime for enterprise AI agents, with 7,500+ pre-built integrations. Duo SSO serves as Arcade's OAuth 2.1 provider, so users authorize tools through Duo, and Arcade enforces which actions each user's agents can take based on user permissions and Duo-issued scopes. Every action is logged for full governance. No separate gateway required.

• Cisco Secure Access: Best for enterprise-grade security. Full managed gateway with network-level enforcement, deep traffic inspection, and enterprise resilience. The tightest integration and most complete experience in the Cisco portfolio.

One Duo Admin Panel manages policies across all of them. Same authorization logic, same audit logs, same group-based policies, regardless of the enforcement point.

Your policies travel with you. Start with whichever gateway fits today; your agents, identity mappings, and policies carry forward if your enforcement point changes tomorrow. For customers who want identity and network controls converged in a single managed plane, Duo paired with Cisco Secure Access delivers that integrated experience. For customers running other gateways, Duo brings the same authorization logic and audit fidelity to whatever enforcement point you've chosen.

You can start configuring least-privileged access for agents today. The Duo Admin Panel now includes a Getting started with agentic AI experience, a guided checklist that walks administrators through securing their agent infrastructure:

1. Get Duo Premier. Start a 30-day free trial of Duo to unlock full agentic security capabilities.

2. Connect a gateway. Choose between Cisco Secure Access, AgentGateway, AWS AgentCore or Envoy.

3. Protect with Duo authentication. Configure OAuth 2.1 / OIDC for agent workflows.

4. Add authorization. Create fine-grained, tool-level access policies for groups.

5. Register agents. Control which agents can access which MCP tools and resources.

6. Monitor activity. View agent activity with full identity correlation.

The Duo Admin Panel shows connected gateways, discovered MCP servers and their tools, active policies, and enforcement status, all in one place. Duo works with Cisco Secure Access, open-source AI/MCP gateways, and AWS Bedrock AgentCore Gateway today, with Cisco AI Defense integration coming soon.

Agentic AI governance shouldn't require ripping out your infrastructure or committing to a single vendor's gateway. Duo Agentic Identity provides the authorization layer with per-tool-call access control, identity-correlated audit, and unified policy management—on top of whatever gateway you're already running, and at the pace your organization is ready for.

For early access to Duo's gateway integrations and to help shape what comes next, reach out to your Cisco contact and work directly with our product and engineering team.

Learn more about Cisco's zero trust for agentic AI workforce at cisco.com/go/securing-agentic-ai

There’s a pattern I see regularly when talking with enterprise customers about Microsoft 365: they want to go passwordless, they’re already using Cisco Duo for multi-factor authentication (MFA) through a conditional access integration, but they assume the next step would require a massive identity migration project. It’s a reasonable assumption, but it’s wrong. Federation is simpler than its reputation suggests, and it doesn’t require moving your existing applications anywhere.

Many organizations come to me already using one of our conditional access integrations with Entra ID, either the custom control or the newer Microsoft Entra External MFA (formerly known as Microsoft External Authentication Methods, or EAM) integration. Both of these integrations are great at what they do: they let you enforce Duo MFA after users authenticate with their Microsoft password. The experience is familiar, the rollout is quick, and you can be up and running in minutes.

But here's the thing: these integrations kick in after the password. Microsoft handles the initial password validation, then hands off to Duo for the second factor. That architecture works well for MFA, but it means passwordless authentication isn't on the table. You can't eliminate the password when someone else is asking for it first.

With federation, the dynamic shifts. When you federate your domain to Duo SSO, Microsoft recognizes your users by their email domain and immediately redirects them to Duo before they ever see a password prompt. Duo owns the entire authentication process, which means we can offer passwordless options like passwordless Duo Push and passkeys right from the start. For your users, this means the login experience shifts slightly: instead of entering their password on a Microsoft page, they'll enter it on a Duo page—or skip the password entirely if you've enabled passwordless authentication.

Want to understand how federation compares to other single sign-on (SSO) approaches? Read our guide to federated identity management vs. SSO.

This is probably the most common concern I hear, and it's completely understandable. Organizations often have hundreds or even thousands of applications connected to Entra ID for SSO. The thought of migrating all of those to a new identity provider sounds like a massive undertaking.

Here's the key insight: you don't have to. When you federate your domain to Duo, your existing Entra ID-connected applications continue to work. The federated authentication flow just adds a step: users are redirected from Entra ID to Duo, authenticate with Duo (including passwordless if you've enabled it), and then get redirected back through Entra ID to their application. These redirects happen so quickly that users barely notice, especially if you're using features like Duo Passport to reduce friction across multiple apps.

I've worked with customers who had legitimate concerns about this: they imagined months of migration work, application-by-application. In practice, most of them had federation up and running in an afternoon (in their sandbox—can’t forget about change control), with all their existing apps working exactly as before. The difference is that now their users can go passwordless.

Another common misconception is that federating to Duo means abandoning your Entra ID conditional access policies. This isn't the case. Your conditional access policies continue to apply to federated logins, they just evaluate after the user has completed authentication with Duo and been redirected back to Entra ID.

This gives you flexibility. You can keep your existing conditional access policies in place, or you can consolidate enforcement to the Duo side using Duo's policy engine—or some combination of both. Many customers find that Duo's policy framework is easier to manage, especially for things like device trust checks, but the choice is yours.

If you're currently using our conditional access custom control integration, you may be aware that Microsoft is moving toward their Entra External MFA (formerly known as Microsoft External Authentication Methods, or EAM) framework as the replacement for custom controls. Many customers are evaluating the jump from custom controls to External MFA right now, and it's worth considering federation as part of that conversation.

Both External MFA and the custom control integration share the same fundamental limitation: they operate after the password. They're both excellent for enforcing MFA, but neither unlocks passwordless. If passwordless or features like Duo Passport for seamless cross-context authentication are on your roadmap, federation is the path that gets you there.

External MFA does have some advantages over the custom control integration, particularly around satisfying Microsoft’s built-in MFA requirements for admin portals and privileged identity management. But it also has limitations: For instance, Microsoft restricts you to a single External MFA integration per Entra ID tenant, whereas with custom controls you could create multiple integrations for granular visibility and control. Federation shares this one-integration-per-tenant limitation with External MFA, but it offers something neither conditional access integration can: a consistent, unified authentication experience across all your applications, and the ability to go passwordless.

One point worth clarifying: federation and External MFA aren’t mutually exclusive. In fact, most customers I work with end up using both. Federation handles authentication for your federated domain—the users with email addresses like jdoe@example.com who make up the bulk of your organization. But there are authentication scenarios that federation doesn’t cover.

For example, you may have accounts on your default “onmicrosoft.com” domain, such as service accounts, break-glass admin accounts, or guest accounts. These non-federated accounts still authenticate directly with Microsoft and can still be protected by Duo via EAM. Similarly, Entra ID Privileged Identity Management (PIM) verification prompts and other flows that aren’t traditional authentication flows can be protected using EAM.

The practical takeaway: think of federation as your primary integration for everyday user authentication, with External MFA providing coverage for the edge cases and administrative scenarios that fall outside the federated flow.

A common question I get: “Can we start with IT, then roll out to marketing, then sales?” The short answer is that federation is a hard cutover at the domain level—you can’t selectively federate some users in a domain while leaving others unfederated.

That said, if you have multiple domains in your Entra ID tenant, you can stage your rollout domain by domain. Each domain is a separate federation configuration, so you could start with a smaller domain to build confidence before federating your primary domain. And if you want hands-on experience before touching production at all, you can federate a test domain in your production tenant or use a sandbox Entra ID tenant. If you’ve been looking for an excuse to buy a fun domain name, here it is. Trying the federation process yourself is a great way to get familiar with the architecture and the PowerShell commands involved.

One important note about subdomains: once you verify a domain in Entra ID, any subdomains you verify afterward will inherit that domain’s federation configuration. So if you verify example.com and then test.example.com, you can’t independently federate the subdomain. If you’re setting up a greenfield environment and anticipate needing independent subdomain configurations, verify your subdomains first.

I want to address something I sense from customers sometimes: a hesitation around whether federation is a proven approach. Maybe it feels like a bigger architectural change than it really is, or maybe the word “federation” just sounds intimidating.

The reality is that federation is how enterprise identity has worked for decades. If your organization ever used Active Directory Federation Services (AD FS)—and many enterprises did—you were already federating. The difference is that Duo SSO is dramatically easier to set up and manage than AD FS ever was. The actual federation process typically takes just a few minutes: verify the prerequisites in Entra ID, create the application in the Duo Admin Panel, run the preconfigured PowerShell script we provide, and you're done.

I've walked through this process with healthcare systems managing thousands of clinicians, with law firms protecting sensitive client data, with financial institutions under strict regulatory requirements. The pattern is consistent: what seems like a big step turns out to be straightforward, and the capabilities it unlocks—passwordless authentication, simplified authentication flows, centralized policy management—make it well worth the investment.

If you're interested in exploring federation for your organization, here's what I'd recommend. First, take a look at our Duo Single Sign-On for Microsoft 365 documentation. It walks through the prerequisites and federation process in detail. The main requirements are straightforward: a verified domain in Entra ID, and users synced via Entra Connect Sync (though Duo's new directory capabilities are opening up even more options here).

If you're a current Duo Care customer working through this decision, reach out to your Duo Care team. We've had these conversations many times, and we're happy to help you think through the architecture that makes the most sense for your organization. The goal isn’t to push everyone toward federation regardless of their situation; it’s to make sure you’re aware of the full range of options and what each one unlocks. That said, if passwordless is on your roadmap, federation is likely the path you’re looking for.

Explore the Duo Single Sign-On for Microsoft 365 documentation to get started or contact your Duo Care team to talk through your options.

You apply least privilege to your end users. You verify their devices, scope their access, and monitor what they can reach. But what about the admins managing your security tools every day?

Admin accounts are some of the highest-value targets in any organization. A compromised admin with broad permissions can generate bypass codes, weaken MFA policies, or modify single sign-on (SSO) configurations—quietly undermining the security layer your business depends on. That is why we are bringing the same least privilege discipline to the people managing Duo.

Custom Admin Roles is now generally available for all Duo customers. You can create your own administrator roles with granular permission controls, so every admin on your team gets exactly the access they need and nothing more.

Ready to get started? Log in to the Duo Admin Panel to create your first custom admin role.

You already apply least privilege to your end users. Your admins deserve the same protection.

Depending on the privilege level, a compromised admin account can cause widespread damage across your identity security configuration. Role-based access control (RBAC) reduces that risk by ensuring each admin operates within a clearly defined scope—one that matches their actual job, not a generic role that happens to be close enough.

Duo has long offered eight built-in admin roles with a fixed set of permissions:

• Owner

• Administrator

• Application Manager

• User Manager

• Help Desk

• Billing

• Read-only

• Integration Manager

These built-in roles give you role-based access control with clear segregation of duties right out of the box. For many teams, they are a good fit. But they are not always a perfect match for how your organization actually operates.

Maybe you want an admin with all the permissions of both User Manager and Application Manager, but without the ability to manage policy that comes with the full Administrator role. Or maybe you have multiple levels of help desk—some who need to see sensitive user attributes, and others who should not.

Until now, you had two options: give admins more privilege than they need, or build manual processes that are hard to maintain and harder to audit. Neither approach supports a strong security posture.

Custom Admin Roles removes that tradeoff. You can now create administrator roles that reflect your organization's actual structure, not a predefined template.

Here is what's now available to any Duo admin with the Owner role:

• Create unlimited custom roles tailored to your organization's operational structure

• Set granular permissions across five categories: Users & Groups, Devices, Features, Applications, and Accounts

• Start from templates by basing a new role on any existing built-in or custom role, then adjust individual permissions up or down

• Assign custom roles anywhere you already use existing roles, including subaccount administration for Managed Service Providers (MSPs) and Administrator Sync

• Edit roles on the fly – permission changes take effect immediately for every administrator assigned to that role

• Assume roles without logging out to verify a role’s configuration before rolling it out to your administrators

• Compare roles any time after creation to highlight the differences and get a full understanding of each role’s privileges

Permissions default to the most restrictive setting unless you apply a template, so you're always building up from least privilege by design.

While every organization structures its security team differently, a few patterns come up often:

• Tiered help desk: Create a Tier 1 help desk role that can reset MFA devices but cannot view sensitive user attributes, and a Tier 2 role with broader visibility for escalations.

• User Identity Manager: Grant full management of users but restrict security-sensitive actions, like putting users into bypass mode.

• Subaccount Lifecycle Manager: Create, configure, and decommission child accounts but disallow any modification of users, policies, or security settings on the parent account.

These scenarios were not possible with built-in roles alone. Custom Admin Roles changes that.

Creating a custom role takes just a few steps right from the Duo Admin Panel:

1. Navigate to Users > Administrators > Admin Roles

2. Click Add custom admin role

3. Name your role, optionally apply a template from an existing role, and expand each permission category to fine-tune access to match your security goals

4. Click Add

That's it! Your new role is ready to use immediately. The role can be assigned anywhere standard roles can be assigned – when manually creating an admin, from an admin’s profile, from the role details page, via Admin API or through admin directory sync.

Before rolling a new role out to your team, we recommend using Assume Role to temporarily experience the Admin Panel exactly as that role will. This lets you verify the configuration matches your intent without affecting a real admin account.

Custom Admin Roles is available now for customers on Duo Essentials, Advantage, and Premier edition. Any admin with the Owner role can start creating custom roles immediately.

To see the feature in action, watch the video below or visit the Custom Admin Roles documentation for a complete walkthrough.

Already a Duo customer? Log in to the Duo Admin Panel to get started.

New to Cisco Duo? Start a free trial to see Custom Admin Roles and the full identity security platform in action.

• Try Cisco Duo free. See Custom Admin Roles, adaptive access policies, and the full identity security platform.

• Custom Admin Roles documentation. The complete guide to creating roles, setting permissions, using Assume Role, and assigning roles to administrators.

• Privileged access management risks. Learn why over-privileged accounts are one of the most common identity security risks and how to reduce your exposure.

• Privileged access management best practices. A guide to managing privileged accounts across your organization, including strategies that extend beyond admin roles.

• Zero trust vs least privilege. Least privilege is a core principle of zero trust security. This article explains how they connect and reinforce each other.

• Zero trust security. Custom Admin Roles is one part of a broader zero trust approach to users, devices, and applications.

• Adaptive access policies. Custom Admin Roles controls what your admins can do. Adaptive access policies control how your users authenticate.

• What is Identity and Access Management. Custom Admin Roles is a practical example of IAM applied to your own security team.

This is the first edition of a new monthly identity threat brief for the Cisco Duo blog. Each month, I examine the identity-based attacks shaping the current threat environment, the structural weaknesses they exploit, and the defenses that hold up against them.

Identity-based attacks target authentication systems, credentials, and identity infrastructure rather than application code or encryption. In recent weeks, four incidents made the pattern clear: attackers stole authentication tokens from compromised routers, breached a national identity agency, abused a trusted vendor's notification system to deliver phishing, and compromised messaging-app accounts to read encrypted communications.

None of these attacks broke cryptography. None defeated multi-factor authentication (MFA) head-on. Each one went around the authentication layer instead of through it. These incidents are a clear opening case for this series: identity is now the primary attack surface, and the authentication layer is where attackers concentrate effort.

Across the four incidents, the pattern is consistent. Attackers did not try to defeat the strong cryptographic controls protecting modern systems. They targeted the trust relationships, session artifacts, and infrastructure that surround authentication.

Stolen tokens granted access without credentials. A breached government identity system exposed citizen data at scale. Legitimate vendor infrastructure delivered phishing that passed every standard email authentication check. Compromised endpoints gave attackers plaintext access to encrypted conversations.

The strategic implication for identity teams is direct: controls designed to verify credentials cannot stop attackers who already hold authenticated sessions or who never needed credentials in the first place. The identity attack surface now extends well beyond the login prompt.

• Router DNS hijacking to harvest Microsoft Office tokens. Russian military intelligence group APT28 (also tracked as Fancy Bear and Forest Blizzard) compromised more than 18,000 routers to intercept OAuth authentication tokens for Microsoft Outlook on the web. The campaign affected more than 200 organizations and 5,000 consumer devices at peak. (Krebs on Security reported the campaign in detail.)
  https://krebsonsecurity.com/2026/04/russia-hacked-routers-to-steal-microsoft-office-tokens/

• Breach of France's National Agency for Secure Documents (ANTS). On April 15, 2026, ANTS disclosed a breach exposing login credentials, names, dates of birth, addresses, and account identifiers for an undisclosed number of French citizens.
  https://therecord.media/france-cyberattack-agency-passports

• Phishing through Apple's legitimate account notification system. Attackers embedded callback-phishing lures inside genuine Apple security notifications sent from appleid@id.apple.com. The messages passed SPF, DKIM, and DMARC checks. (BleepingComputer reported the technique.)
  https://www.bleepingcomputer.com/news/security/apple-account-change-alerts-abused-to-send-phishing-emails/

• Compromise of commercial messaging-app accounts. A joint CISA and FBI advisory warned that Russian intelligence services compromised thousands of individual messaging-app accounts to access encrypted communications without breaking the underlying encryption.
  https://www.cisa.gov/resources-tools/resources/russian-intelligence-services-target-commercial-messaging-application-accounts

Each incident exploits a different surface, but the underlying logic is the same.

APT28 did not phish credentials or defeat MFA. The group exploited known vulnerabilities in end-of-life Mikrotik and TP-Link SOHO routers, modified DNS settings to point to attacker-controlled servers, and intercepted OAuth tokens after users had already authenticated successfully.

Because OAuth tokens are issued after MFA verification, the stolen tokens granted fully authenticated sessions. No further credentials or one-time codes were required. Krebs on Security reported the campaign and noted the technique is highly effective at evading malware-focused detection.

This is an MFA bypass in the most practical sense: MFA worked exactly as designed, and the attacker waited for the token it produced.

The compromised ANTS data included login credentials and the personal information used to verify identity in administrative procedures. The Record reported the breach as the latest in a series targeting French government identity infrastructure, including a February 2026 breach of France's National Bank Accounts File that exposed information on roughly 1.2 million accounts.

Stolen identity data of this kind feeds downstream attacks: account takeover, fraudulent document applications, and credential reuse against unrelated services.

BleepingComputer reported that attackers embedded fraudulent transaction notices and callback phone numbers inside genuine Apple account-change emails. Because the messages originated from Apple's verified sending infrastructure, they passed every email authentication check designed to detect spoofing.

The attack does not exploit a technical vulnerability. It exploits the gap between sender verification and content trust.

The CISA and FBI joint advisory stated explicitly: attackers did not break the encryption of the messaging platforms. They compromised individual user accounts through credential phishing, session token theft, SIM swapping, and exploitation of weak authentication.

Once inside an account, attackers had plaintext access to historical messages, real-time conversations, and contact lists they could use to expand the attack.

MFA, SPF, DKIM, DMARC, and end-to-end encryption are strong controls. They are also narrow controls. Each verifies one specific thing: that a user holds a second factor, that an email originated from an authorized sender, or that a message was encrypted in transit.

None of them verify that the session in use is legitimate, or detect when a trusted platform delivers malicious content. None of them protect a credential database or a token store. The four recent incidents land at exactly these gaps.

The structural defense against this pattern is to make stolen credentials and stolen tokens harder to use, and to detect identity misuse when it occurs.

Phishing-resistant MFA uses cryptographic protocols such as FIDO2 (Fast Identity Online 2) and WebAuthn that bind authentication to the specific origin a user is signing into. Unlike one-time codes, push notifications, or SMS, phishing-resistant MFA cannot be replayed, intercepted on a fake site, or approved by a confused user.

It addresses the structural weakness behind credential phishing and many forms of session hijacking. For identity teams reviewing their authentication stack, phishing-resistant MFA is the highest-leverage control available today.

Token binding ties an authentication token to the device that obtained it. A stolen token cannot be replayed from an attacker's infrastructure. Conditional access policies add risk-based checks at session reuse, not just at sign-in. Together, they reduce the value of a stolen OAuth token of the kind APT28 harvested.

Detection of identity-based attacks depends on observing what authenticated identities do, not just whether they authenticated. Behavioral monitoring, anomalous-session detection, and analysis of token activity surface compromise even when credentials and MFA were not defeated.

Cisco Duo's identity threat detection and response capabilities operate at this layer. They pair with identity security posture management to surface the configuration weaknesses attackers target.

None of these controls work in isolation. They sit inside an identity security program that connects authentication, posture management, detection, and response.

For a Director of Identity reading this brief, the recent incidents translate into four practical actions.

• Treat the authentication layer as an attack surface, not a control surface. Authentication is no longer just something the identity team configures. It is something attackers actively target. Inventory where authentication tokens live, how long they last, and who can use them.

• Move toward phishing-resistant authentication. Deprecate SMS and push-only MFA on a defined timeline. Each of the recent incidents demonstrates the limits of authentication factors that can be intercepted, replayed, or socially engineered.

• Invest in identity-specific detection. Endpoint detection and network detection do not see identity misuse. Detection of session anomalies, token replay, and unusual authentication patterns requires identity-layer telemetry.

• Treat identity infrastructure breaches as catalysts for downstream attacks. A breach like the ANTS disclosure does not end with the disclosed agency. The exposed data feeds account takeover, credential stuffing, and impersonation across unrelated services.

This is the first in a series of recurring monthly briefs. Each edition examines the identity-based attacks shaping the threat environment that month, the structural weaknesses they exploit, and the defenses that hold up against them. Attackers are adapting quickly. I will track how that adaptation unfolds and what identity teams need to know.

Visit the Duo blog to follow the identity threat intelligence series and get each monthly edition as it publishes.

User lifecycle management is the process of creating, updating, and removing user access to applications and systems as employees, contractors, and partners join, change roles, or leave an organization. Done well, it protects the business without slowing people down. Done manually, it introduces errors, delays, and orphaned accounts that attackers can exploit.

Organizations no longer deal with a simple, centralized workforce logging in from a single corporate office. Today’s IT environments are hybrid, user populations are highly diverse, and the perimeter has dissolved into a network of cloud applications, remote endpoints, and third-party integrations.

To secure this dynamic environment, you need comprehensive identity lifecycle management.

In a recent episode of our Duo 3 in 30 webinar series, I sat down with Cisco Customer Solutions Engineer Reetam Mandal to explore three Duo features that automate identity lifecycle management from onboarding to departure: Duo Directory, Directory Sync, and Custom Attributes.

If you missed the live session, this post provides a deep dive into the three pillars covered in the webinar 3 in 30: Identity Lifecycle Management, Duo Directory, Directory Sync, and Custom Attributes.

Duo Directory is a cloud-based user directory that stores and manages user identities for authentication and policy enforcement.

Identity management can quickly become a tangled web, especially if your organization operates within a hybrid environment or relies on a mix of internal employees, contractors, and partners. Duo Directory cuts through this complexity by offering incredible flexibility, acting as the foundational component for managing your user identities.

It centralizes the user information relevant to Duo’s authentication and policy enforcement, giving IT and security teams a unified pane of glass to view and control exactly who accesses corporate resources. During the webinar, we covered three primary deployment scenarios:

Not every organization needs a massive Active Directory (AD) environment or a heavy-duty identity provider (IdP). For small-to-medium businesses, startups, or organizations adopting a strict cloud-first strategy, Duo Directory can serve as your primary, standalone identity store.

Administrators can create, manage, and configure users directly within the Duo Admin Panel. You can set required password options, manage credentials, and enforce enrollment policies without routing through an external ID source. When users enroll in Duo for the first time, they can be prompted to set a password, allowing Duo to handle the entire authentication lifecycle. This provides a simple, agile, and scalable option for securing access without the overhead of additional infrastructure.

For larger enterprises that have heavily invested in existing IdPs like Active Directory, Microsoft Entra ID, or Okta, Duo Directory doesn't force you to rip and replace. Instead, it acts as an intelligent identity broker.

In this setup, Duo Directory sits in front of your existing identity providers. It mediates authentication requests, applies Duo's phishing-resistant multi-factor authentication (MFA) and adaptive access policies, and then passes the authenticated user back to your primary IdP. This allows you to maximize existing infrastructure investments while layering on advanced security. Every login is protected by strong authentication and context-aware policies.

To manage multiple directories seamlessly, Duo utilizes routing rules. An admin can create custom rules dictating how different users are processed. For example, if a user attempts to log into Duo Central, Duo’s single sign-on portal, and their email originates from a subsidiary’s domain, their request is automatically routed to Active Directory. A default fallback rule ensures that anyone not matching custom criteria is still securely authenticated.

One of the most common headaches for IT administrators is managing access for external users—contractors, vendors, partners, or temporary interns. These individuals need access to specific corporate resources, but adding them to your primary corporate directory clutters your environment and introduces significant security risks.

Duo Directory offers a practical approach. You can run Duo Directory side-by-side with your existing IdP. This allows you to create and manage third-party users directly within Duo, keeping them completely segregated from your main identity store. You maintain strict, granular control over what these external users can access, apply specific security policies to them, and keep your core directory clean and secure.

Directory Sync is an automated process that synchronizes users and groups from external identity stores (Microsoft Entra ID, Active Directory, Google Workspace, OpenLDAP, Okta) into Duo Directory.

Having a robust directory is only the first step. The real challenge lies in keeping that directory accurate as your workforce constantly changes. Employees are hired, promoted, transferred, and eventually leave the organization. Managing these state changes manually is slow, error-prone, and creates security gaps.

This is where Directory Sync comes in. Working hand-in-hand with Duo Directory, Directory Sync automates user onboarding and offboarding by synchronizing users and groups from your existing external directories directly into Duo. Currently, Duo supports seamless synchronization with Microsoft Entra ID, Active Directory, Google Workspace, OpenLDAP, and Okta.

Let’s explore the three major operational and security benefits of implementing Directory Sync:

Manual user provisioning is tedious, time-consuming, and highly prone to human error. When a new batch of employees starts, IT teams often scramble to manually create accounts across dozens of applications.

Directory Sync eliminates this friction. Administrators can set synchronization schedules—for instance, automatically syncing with Active Directory every 12 hours. When a new employee is added to your primary directory, they are automatically provisioned in Duo. You can even automate the onboarding process by configuring Duo to automatically send enrollment emails to newly synced users. By removing these tedious administrative tasks, your IT team is freed up to focus on strategic, high-value security initiatives.

While onboarding is important for productivity, offboarding is critical for security. One of the most severe security vulnerabilities an organization can face is the "orphaned account"—an active account belonging to an employee who has already left the company. These dormant accounts are prime targets for threat actors.

Directory Sync drastically reduces this window of vulnerability. When a user is deactivated, terminated, or removed from your master directory, Directory Sync ensures their access to all Duo-protected applications is immediately revoked. In the Duo Admin Panel, administrators can clearly see a user's status change to "Pending Deletion" the moment they are deprovisioned. This automated, immediate revocation prevents potential data breaches and strengthens your overall security posture.

Effective security policies rely on accurate data. If your identity system thinks a user is in the marketing department, but they transferred to finance three months ago, your access policies are fundamentally broken.

Directory Sync ensures that the user and group information within Duo is always a true, accurate reflection of your primary authoritative identity source. During the setup process, administrators have granular control over exactly what gets imported. You can define specific groups (e.g., fetching only the "Interns" or "UX Team" groups) and map exact user attributes like usernames, email addresses, and display names.

By automating this synchronization, you eliminate data discrepancies. This is not only crucial for ensuring context-aware security policies function correctly; it is also a strict requirement for many regulatory compliance frameworks that demand up-to-date, auditable user records.

Custom Attributes are user-specific tags that extend the default user schema, enabling context-aware access policies based on role, clearance, department, or status.

With your directories established and your synchronization automated, you have a solid identity foundation. However, modern Zero Trust security requires more than just knowing who a user is; you need to understand their context.

Standard user data, such as basic group membership, is often insufficient for today’s complex access requirements. This brings us to the third feature highlighted in the webinar: Custom Attributes.

Custom Attributes allow administrators to go beyond the default schema and define unique, highly specific tags for users. This rich context empowers you to build intelligent, granular, context-aware access policies that drive smarter security decisions.

A user's role in an organization is rarely defined by a single group membership. With Custom Attributes, you can define highly specific tags that align with your unique business structure. You can tag users based on their specific department, their cost center, their employee number, their job title, or even their security clearance level.

Because managing dozens of attributes can become visually overwhelming, Duo allows administrators to group these attributes logically within the Admin Panel (e.g., grouping all project-related tags under a "Special Projects" category). By enabling these custom attributes, you can create highly precise policies that grant or deny access to applications based on exact roles and characteristics, ensuring users only have access to the resources necessary for their specific responsibilities.

Not all applications are created equal. An application housing the company's cafeteria menu requires vastly different security controls than a database containing sensitive customer financial records or protected health information.

Custom Attributes allow you to tag users who handle highly sensitive data. For example, you can create a custom attribute labeled "PCI Data Access" or "HIPAA Compliant." Once these users are tagged, you can build stringent, targeted policies around them. You might require that any user with the "PCI Data Access" attribute must authenticate using a phishing-resistant MFA factor (like a biometric or FIDO2 security key) and must be logging in from a corporate-managed, trusted device before they are granted access. This allows you to apply maximum friction and security exactly where it is needed, without disrupting the workflow of users accessing low-risk applications.

User status is rarely static. Employees go on sabbatical, contractors are hired for 30-day sprints, and staff members are temporarily assigned to cross-functional teams. When a user's state changes, your security policies must adapt instantly.

Custom Attributes enable this agility. You can define attributes that reflect dynamic, temporary states. For instance, Reetam demonstrated creating a "Temporary Access" attribute in the webinar. You can build a policy that triggers when this attribute is applied, automatically limiting the user's access to a specific subset of applications for exactly 30 days.

Alternatively, you could create an "On Leave" attribute. If an employee goes on extended medical or parental leave, applying this attribute could automatically block all access to corporate resources until they return, preventing their dormant account from being compromised while they are away. This dynamic adaptability ensures your security posture evolves in real-time alongside your workforce.

Identity lifecycle management is a continuous process, not a one-time project. Three Duo features work together to automate it:

• Duo Directory centralizes and brokers user identities across standalone, hybrid, and third-party scenarios.

• Directory Sync automates onboarding and offboarding across Microsoft Entra ID, Active Directory, Google Workspace, OpenLDAP, and Okta.

• Custom attributes enforce granular, context-aware access policies based on role, clearance, or status.

Together, these three features deliver automated user lifecycle management: the right users get the right access to the right resources under the right conditions, from their first day to their last.

Watch the Duo 3 in 30 webinar on identity lifecycle management, available on-demand on the Duo website. We walk through the live Admin Panel configurations, and you’ll see how easy it is to implement these solutions in your own environment.

Watch the 3 in 30 webinar
Start a free trial

Cisco stands alone in the Customers’ Choice Quadrant for 2026 based on reviews of its Duo offering in the Access Management VOC

Cisco Systems was named a Customers’ Choice in the 2026 Gartner Peer Insights™ Access Management Voice of the Customer. The recognition follows Cisco’s inclusion in the 2026 Gartner Peer Insights™ Voice of the Customer User Authentication category. Cisco is the only vendor to be mentioned as a Customers’ Choice in both the 2026 VOC for Access Management and User Authentication based on reviews of its Cisco Duo offering.

Among the companies evaluated by customers within the 2026 Gartner Peer Insights™ Access Management Voice of the Customer, Cisco was the only vendor to appear in the Customers’ Choice quadrant. Placement in the quadrant reflects ratings and reviews that met or exceeded the market average for User Interest and Adoption (x-axis) and Overall Experience (y-axis).

Cisco, based on reviews for Duo, received an overall rating of 4.8 out of 5, reflecting that 98% of customers are willing to recommend Cisco for access management, the highest percentage among vendors in the category.

Placement in the Gartner Peer Insights™ 2026 Customers’ Choice quadrant is based on ratings and reviews submitted by anonymous customers that met or exceeded the market average for Overall Experience and User Interest and Adoption. Cisco’s ratings are reflective of 62 reviews by verified customers during an 18-month period ending February 28, 2026.

According to Gartner Peer Insights™, Access Management’s purpose is to give people (employees, consumers, and other users) and machines access to protected applications in a streamlined and consistent way that enhances the user experience. Duo delivers comprehensive access management capabilities and broad Identity and Access Management (IAM) value including:

• Identity lifecycle management

• User authentication including phishing-resistant, multi-factor authentication (MFA) and end-to-end passwordless login

• Single sign-on (SSO) and session management

• Identity directory

• Authorization policy definition and enforcement

• Adaptive, risk-based access

• Session protection and monitoring

• Identity context sharing across security tools

• Consolidated identity provider (IdP) and directory management capabilities

Direct quotes from the Gartner Peer Insights™ Access Management Reviews include:

“Passwordless Remote Access and Simple Management Achieved with Seamless Setup Process”

"Easy to get started and set up; we installed the Duo authentication proxy and it took no longer than a day to get it up and into the testing phase. The dashboard is excellent and simple. Active Directory Integration was seamless and allows us to manage users and groups from a single place and the changes are reflected in the Duo dashboard.”

"Duo Provides Granular Security Policies and Easy Implementation for Organizations"

“The security features are very comprehensive for identity security. The ability to use the onboard "directory" for creating user accounts in combination with integrated identity platforms gives additional flexibility for tracking identities for casual or non-traditional users.”

“Multi-Factor Star”

“DUO has been an outstanding solution for us. It has helped us implement two-factor authentication for more applications than we ever imagined, with enough two-factor options to accommodate every user.”

“Cisco is constantly adding functionality to DUO, allowing us to grow with the product and adapt to an ever-changing security landscape.”

"Push Notification Passcode Feature Enhances Security Without Disrupting Workflows"

“This product strikes a good balance between security and usability... It is a very simple and quick authentication process. Push notification with verified passcode feature is very simple and provides strong security without interrupting everyday work.”

"Duo Delivers Reliable Performance with Strong Security and Seamless Integration Features"

"What I like most is the wide range of features Duo offers. It provides comprehensive security capabilities while remaining easy to manage and integrate with our systems.”

• Read the 2026 Voice of the Customer for Access Management

• Read the additional peer-based Duo reviews

• Learn more about the Gartner Peer Insights™ Access Management Reviews and Ratings

• Read the previous blog post, Cisco Systems Named a Customers’ Choice in Gartner Peer Insights™ 2026 Voice of the Customer for User Authentication

Explore related resources to learn more about the capabilities highlighted in this recognition:

• What is Identity and Access Management (IAM) - a foundational guide to the discipline highlighted in this category

• What is identity security - how identity security connects to access management and broader protection

• What is Single Sign-On (SSO) - an overview of one of the core capabilities Duo delivers

• What is MFA - a plain-English explanation of multi-factor authentication

• How to set up phishing-resistant MFA - practical guidance on implementing phishing-resistant authentication

• 5 passwordless authentication benefits you shouldn't ignore - why passwordless is gaining traction in modern access management

• What are the 7 pillars of zero trust - context for the adaptive, risk-based access capability

Gartner and Peer Insights™ are trademarks of Gartner, Inc. and/or its affiliates. All rights reserved. Gartner Peer Insights content consists of the opinions of individual end users based on their own experiences, and should not be construed as statements of fact, nor do they represent the views of Gartner or its affiliates. Gartner does not endorse any vendor, product or service depicted in this content nor makes any warranties, expressed or implied, with respect to this content, about its accuracy or completeness, including any warranties of merchantability or fitness for a particular purpose.

Gartner, Gartner Peer Insights Voice of the Customer for Access Management, Peer Contributors, April 24^th, 2026.

Gartner, Gartner Peer Insights Voice of the Customer for User Authentication, Peer Contributors, January 22^nd, 2026.

In a previous post, we explored why depending on a single Identity Provider (IdP) creates concentration risk that can affect availability, security, vendor leverage, and business continuity. Now we want to walk through the practical strategies for addressing that risk.

If your organization has assessed its IdP concentration risk and determined that a mitigation strategy is necessary, this post provides two proven approaches you can implement. For a comprehensive framework to evaluate identity providers and directory strategies, download the IAM Buyers Evaluation Guide.

We believe organizations operating critical infrastructure must implement a practical mitigation strategy for identity concentration risk. Two approaches have proven effective:

• Backup IdP: Maintain a secondary IdP that you fail over to during disruptions to your primary provider.

• Split IdP: Run two IdPs concurrently with your user base distributed across both providers.

Each approach has distinct advantages depending on your organization's size, complexity, and operational maturity. The following sections walk through both in detail.

This strategy involves failing over to a backup IdP to reduce the potential impact of an outage at your primary provider. The operating model works as follows:

• During normal operations, users authenticate through Single Sign-On (SSO) with your primary IdP.

• During an IdP outage, you change the SSO configuration of your applications to switch authentication to the backup IdP.

To execute this strategy successfully, follow these five principles.

Choose your backup IdP from a different vendor. Operational diversity is the foundation of this approach. If your backup IdP runs on the same vendor infrastructure as your primary IdP, a single vendor-level disruption can take down both providers simultaneously. Select a backup provider that operates on independent infrastructure.

Match the configuration of your primary IdP. When you create a backup IdP, replicate the configuration of your primary IdP as closely as possible. This includes Multi-Factor Authentication (MFA) policies, conditional access rules, group memberships, and attribute mappings. Configuration parity ensures that users experience consistent security enforcement regardless of which IdP handles authentication.

Hydrate the backup IdP with your current user base. Your backup IdP must contain an up-to-date copy of your primary IdP's user directory. This ensures that every user can authenticate and access the required applications and services when you activate the backup. Most organizations have moved from manual provisioning to automation that integrates Human Resources Management Systems (HRMS) with the IdP. Establishing this synchronization with a second IdP is usually a one-time setup using connectors provided by the new provider.

Prepare Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) profiles in advance. Most systems and applications allow you to create multiple SAML and OIDC profiles, with each profile referring to a different IdP. To minimize the work required during a failover event, prepare these profiles before you need them:

1. Create separate SAML and OIDC profiles for your primary IdP and your backup IdP

2. Configure SSO to use only the primary IdP profile during normal operations

3. When an outage occurs, modify the SSO configuration to use the backup IdP profile

This preparation reduces your failover from a complex reconfiguration exercise to a profile switch.

Prepare the backup IdP to handle production load. When you activate the backup IdP, it must handle all of the authentication requests that your primary IdP normally processes. When you size your backup deployment, account for two key factors:

• The number of users in your organization who authenticate through SSO

• The configured session length in your applications, which determines how frequently users are redirected to the IdP for reauthentication

For example, if your session length is between eight and 24 hours, authentication requests typically spike during morning hours when employees begin their workday. Size your backup IdP to handle these peak loads, not just average traffic.

You may not need to provision an entirely new IdP to serve as your backup. Many organizations still operate an on-premises IdP that could fill this role. For example, your organization might use Active Directory as its authoritative source for identities and Active Directory Federation Services (AD FS) for SSO. In this scenario, AD FS could serve as the backup IdP.

This reuse approach helps you limit both cost and maintenance overhead. Before committing to a new provider, audit your existing infrastructure for an IdP that already has access to your user directory and supports SAML or OIDC federation.

A backup IdP that has never been tested is not a reliable backup. To ensure your SSO failover process works when you need it, verify the process on a regular schedule:

1. Select one or more applications and manually switch their SSO profile assignment to the backup IdP

2. Verify that SSO with the backup IdP authenticates users as expected

3. Confirm that signing certificates are current and valid

4. Document the time required to complete the switchover

5. Identify any steps that caused delays or confusion and refine the process

Treat failover testing the same way you treat disaster recovery testing for other critical systems. A documented, rehearsed process executes faster under pressure than one your team performs for the first time during an actual outage.

This strategy involves running two IdPs concurrently and distributing your user base across both providers. Unlike the backup approach, both IdPs are active during normal operations. The operating model works as follows:

• One segment of your users authenticates through SSO with IdP 1

• Another segment authenticates through a second SSO configuration with IdP 2

Choosing how to split your user base. Organizations can segment users across IdPs in several ways:

• By user type: First-party users such as employees and interns authenticate through one IdP, while third-party users such as vendors and contractors authenticate through the other (as shown in the image above)

• By business function: Critical business units use one IdP, and non-critical units use the other

• By geographic location: Primary office locations use one IdP, and secondary locations use the other (this is our recommended approach as it provides the cleanest operational separation)

The split approach provides several operational benefits compared to maintaining a standby backup:

Avoids complete identity failure. Because both IdPs are always active, an outage at one provider only affects the user segment assigned to that provider. The other segment continues to authenticate normally. Your organization never experiences a total identity blackout.

Eliminates switchover complexity during outages. With a backup IdP strategy, your team must execute a failover procedure under pressure during an outage. With split IdPs, the SSO configurations for both providers are already active. The incremental effort during a disruption is limited to reassigning the SSO profile for the affected user segment to the functioning IdP.

To implement the split approach effectively:

• Choose IdPs from different vendors to maintain operational diversity, just as with the backup approach

• Hydrate all users to both IdPs so that either provider can authenticate any user when needed, not just the segment currently assigned to it

• Assign the correct users and groups to the correct IdP in each of your applications

• Have users set up their authentication credentials across both IdPs so they can authenticate through either provider without delays during a reassignment

Whether you choose the backup approach or the split approach, start with these three steps:

Audit your blast radius. If your primary IdP went offline for four hours, which mission-critical systems would remain accessible? Map every federated application to understand your full exposure.

Evaluate your N+1 options. Do you have an existing on-premises IdP or a secondary cloud provider that could serve as a failover? Assess what you already have before investing in new infrastructure.

Practice the switch. Ensure your team knows exactly how to execute a SAML profile switchover before a crisis forces them to learn on the fly. Document the procedure, assign roles, and rehearse it.

For a step-by-step framework to evaluate IdP providers and directory strategies as part of your resilience plan, download the IAM Buyers Evaluation Guide.

Identity controls access to every application, every dataset, and every workflow your organization depends on. We do not accept single points of failure in our power grids, our databases, or our networks. It is time we apply the same standard to our identity systems.

Ready to explore how Cisco Duo can strengthen your identity resilience strategy? Talk to a security expert.

AI agents are in your environment right now. They’re reading databases, sending messages on behalf of employees, and executing multi-step workflows across production systems. If you’re a security leader, you already know this introduces risk.

The hard part isn’t awareness. It’s the pressure to keep pace. Every week brings new agentic capabilities, new integrations, new competitive advantages your organization can’t afford to sit out. So you let adoption move forward and accept a certain level of risk, because falling behind feels worse.

That’s a reasonable trade-off. But most organizations are accepting risk they haven’t actually scoped. The agentic AI security challenge covers more ground than traditional security models account for, and without a way to think about it, it’s hard to know which exposures matter, which ones are already present, and where your existing controls fall short.

In our research at Cisco Duo into how AI agents interact with enterprise systems through protocols like MCP (Model Context Protocol), we keep seeing threats cluster into three categories. The point here isn’t to slow down adoption. It’s to give security teams a framework for reasoning about where the real exposure is, so you can keep moving forward with your eyes open.

The most common agentic threats aren’t attacks. They’re configuration mistakes and tooling limitations.

When organizations deploy agents, they connect them to enterprise tools and grant permissions. The urgency is part of it, but the bigger issue is tooling. The policy and configuration systems most organizations rely on were designed for human users. They don’t map cleanly to agents, which are non-human identities that need per-action scoping, tighter delegation boundaries, and identity models that most traditional tools simply don’t support. So teams do the best they can with what they have, and the result is permissions that are too broad, too persistent, and too loosely scoped. You don’t need an attacker to exploit these conditions. They’re exploitable by design.

Over-privileged agents are the simplest example. A developer wants a coding assistant to review pull requests and leave comments. They hand it their personal GitHub access token, the same one they use for CLI work. That token carries every permission the developer has: push code, merge branches, delete repositories, access private repos across the org. The agent was meant to read and comment. Now it can do everything the developer can, with no guardrails and no one in the loop.

Delegation scope drift is harder to spot. An agent starts with read-only Salesforce access. Over eight months, support tickets lead to adding write access, then export, then full API access. Each change makes sense at the time. Nobody reviews the cumulative result, which now far exceeds the original intent.

Cross-user boundary violations show up when agents can reach data belonging to someone other than the user who authorized them. An enterprise Slack integration grants agents access to “all channels the app is installed in” rather than “channels the delegating user belongs to.” One user’s agent can now read another user’s private channels and DMs.

Shared agent identities are an attribution problem. A platform team creates a single “team-devops-bot” identity shared by 20 engineers, connected to AWS, Kubernetes, and Terraform. When the agent runs a destructive terraform destroy, logs show “team-devops-bot.” Good luck figuring out which engineer triggered it.

None of these are edge cases. They’re the default outcome when you apply existing identity and access patterns to agents without rethinking the model. The fixes aren’t exotic: least-privilege scoping per agent, user-level isolation, individual identities with clear ownership, periodic review of accumulated permissions. Most teams just haven’t had the bandwidth to get there yet.

Perfect permissions don’t prevent all damage. Agents interpret instructions, make judgment calls, and sometimes get it wrong. No attacker required.

Dangerous tool sequences are where traditional access controls break down. An automation agent (1) reads database credentials from a secrets vault, (2) queries customer PII from a database, and (3) uploads a “backup” to an S3 bucket. Every individual action is allowed. Strung together, it’s data exfiltration. If your policy only evaluates actions one at a time, you’ll never catch this.

Runaway execution is the least sophisticated failure mode and potentially the most disruptive. In March 2026, a multi-agent research system’s Analysis and Verification agents entered an undetected recursive feedback loop. The Analysis Agent expanded content based on Verification feedback, which triggered new verification questions, which triggered more analysis. Every API call succeeded. Every response was well-formed. The loop ran for eleven days before anyone noticed. Cost: $47,000 (Dev|Journal, 2026). This pattern is endemic across AI coding tools: Cursor, Copilot, and Claude Code have all had documented infinite loop incidents, with individual cases racking up hundreds to thousands of dollars in minutes.

The thread connecting these is that access control alone won’t save you. You need behavioral monitoring: what does normal agent activity actually look like, and what deviates from that? You need to evaluate tool interactions as sequences, not individual calls in isolation.

The first two categories are self-inflicted. This one involves an adversary on the other end.

As agents become standard enterprise infrastructure, attackers are adapting. The attack surface is there, and they’ve already started working it.

The confused deputy is a classic attack pattern that gets significantly more dangerous with agents. In 2025, four critical-severity vulnerabilities (CVSS 9.3-9.4) hit Anthropic, Microsoft, ServiceNow, and Salesforce, all following the same pattern: an attacker injects hidden instructions into content the agent processes (an email, a web form, a Slack message), and the agent uses its legitimate permissions to exfiltrate data to the attacker. Microsoft’s EchoLeak vulnerability (CVE-2025-32711) was a zero-click attack: the victim never even opened the malicious email. Copilot’s retrieval engine ingested the payload alongside trusted SharePoint files and encoded sensitive data into an outbound URL. The agent isn’t over-privileged in any of these cases. These are identity-based attacks where the agent’s own credentials become the weapon, manipulated into misusing its legitimate access on behalf of someone who doesn’t have it.

Agent credential theft is scaling fast, and it’s a different problem than stolen passwords. When a human credential leaks, the attacker gets one person’s access, usually gated by multi-factor authentication (MFA), to a limited set of systems. Agent credentials are bearer tokens. There’s no second factor. Whoever has the key IS the agent. And because agents tend to accumulate access across multiple services (AWS, GitHub, Slack, databases), a single compromised credential can grant broad cross-system access at machine speed. Making it worse: research has found that 53% of MCP servers rely on long-lived static secrets, and only 8.5% use OAuth (ReversingLabs, 2025). These aren’t short-lived tokens that expire in an hour. They’re keys that sit valid for months. In February 2026, researchers discovered a misconfigured database on the AI agent platform Moltbook that exposed 1.5 million of these keys in plaintext (prplbx, 2026) (OpenAI, Anthropic, AWS, GitHub, Google Cloud). Any attacker with those keys could fully impersonate any agent on the platform. The broader trend is accelerating: 67% of compromised organizations experienced credential theft against cloud management consoles in 2025, and 61% of organizations now cite AI as their top data security concern (AICerts, 2026).

MCP server security is a genuinely new concern, and the numbers are sobering. The MCPTox benchmark found that 5.5% of MCP servers exhibit tool poisoning attacks, 43% are vulnerable to command injection, and a third allow unrestricted network access (MCPTox, 2026). In the first two months of 2026 alone, over 30 CVEs were filed against MCP servers, clients, and infrastructure (heyuan110, 2026). One of the most notable, CVE-2025-6514, was a CVSS 9.6 remote code execution flaw in mcp-remote (Amla Labs, 2025), an npm OAuth proxy package with over 437,000 downloads. On the supply chain side, open source MCP servers have been found with hidden reverse shells and single-line code updates that silently forward data to third-party servers (Docker, 2026).

Each category demands something different. Misconfigurations are a governance problem: better defaults, tighter guardrails, regular review. Non-deterministic execution and malicious attacks are both observability and detection problems, but different kinds: the first requires behavioral monitoring across sequences of actions, not just individual calls; the second layers on threat intelligence, credential hygiene, and infrastructure validation.

No single control covers all three. But AI agent security starts with a few things that help everywhere:

• Least-privilege authorization at the tool-call level. Agents should get exactly the permissions they need for their specific task, evaluated per action, not granted in bulk.

• User isolation by design. An agent acting on behalf of one user should never be able to touch another user’s data or sessions.

• Infrastructure validation. The tools and servers agents connect to need verification. Governing the agents themselves isn’t enough if the infrastructure underneath them is compromised.

• AI agent monitoring across sequences. A single tool call might look fine. The pattern across a session is where risk shows up.

The agentic threat landscape is growing fast, and it’s more specific than “agents might go rogue.” Keeping up with AI capability in your organization matters. So does keeping up with security practices in this space, and the two should move in lockstep, not six months apart.

At Duo, we’re actively researching these threat categories as part of our work on agentic identity and MCP security. To see how we’re applying least-privilege authorization, user isolation, and infrastructure validation to the agent ecosystem, visit our Agentic AI Security page or start a free trial.

Many MSPs are helping clients build a stronger security foundation. But getting there isn't always straightforward. It takes time, resources, and alignment across teams. Yours and theirs.

Meanwhile, threats aren't waiting.

Many of your clients still rely on passwords and legacy access controls that weren't designed for today's attacks that target logins, not systems. Some have MFA in place, but the challenge is coverage and effectiveness. Ensuring it's enforced at the right access points and resistant to modern phishing attacks.

According to Cisco Talos' 2025 Year in Review, VPNs are one of the top identity control points attackers target because VPNs authenticate users with credentials, and credentials get stolen. Without phishing-resistant MFA on the VPN, a stolen password is all an attacker needs to create a fully trusted session and move freely as a valid user. No forced entry. No alerts.

And they're not stopping at the VPN. Talos found that MFA itself is under direct attack: device compromise attacks where attackers fraudulently register their own device as a trusted MFA factor surged 178% in 2025.

That's not a technology failure. That's your clients' exposure.

According to Microsoft's 2025 Digital Defense Report, phishing-resistant MFA blocks over 99% of identity-based attacks, making it one of the most effective controls you can deploy across your client base.

At the same time, expectations are rising.

Your clients are being pushed to adopt stronger access controls as users, devices, and applications connect from everywhere. But in practice, rolling out these frameworks introduces friction. New policies to configure, identity and device signals to align, and controls to integrate across existing systems.

Managing multiple tenants, stitching together tools from different vendors, and maintaining consistent security policies across client environments increases operational overhead, drives up costs, and pulls focus away from what actually matters: reducing client risk.

This is the gap most MSPs are feeling: high client expectations. Limited capacity.

Ready to take the first step? The Service Creation Guide walks through how to package identity-led access security into a scalable, revenue-generating managed service. If you have clients to bring along, the at-a-glance gives them a quick summary they can act on today.

Cyber insurers are also raising the bar. They're no longer satisfied with checkbox compliance. They expect continuous validation that controls like MFA are actively enforced. Your clients need to demonstrate measurable identity security to maintain coverage and manage premiums. As their trusted security partner, MSPs are on the hook to help them prove it.

You don't need to overhaul everything. You need to focus on where attackers actually get in. Small steps starting with securing access can reduce client risk today while moving them toward a security model where only the right people get in, without introducing extra work for your team.

If you're looking for immediate traction across your client base, start with the access points attackers rely on most—VPN, Wi-Fi, and administrative systems. Critical access points like Remote Desktop Protocol (RDP) and server logins are often overlooked or inconsistently protected across client environments, especially in hybrid setups. Extending phishing-resistant MFA to these remote desktop and server logins closes another common gap and gives you another high-value control point to offer clients.

Cisco Duo verifies identity using phishing-resistant MFA and adaptive access policies. Meraki enforces access at the network layer.

Together, they secure VPN, Wi-Fi, and administrative access across your clients without adding complexity or slowing your team down.

Here’s what Cisco Duo and Meraki deliver:

Duo and Meraki give your team clear audit trails, exportable compliance logs, and fast deployment across every client. And with Duo Essentials, you also get passwordless authentication and single sign-on (SSO) — so users get a smoother login experience while your team avoids managing multiple credentials across every client.

This doesn't have to be an all-or-nothing transformation. For your clients, meaningful progress starts with securing how they get in. Lock down access first. Everything else follows.

Following the adoption of zero-trust architectures, identity systems have become the new first line of defense. The shift from trusting connections based on network origin to verifying identity and device posture before granting access has been one of cybersecurity's most significant advances.

If your organization relies on a single Identity Provider for every authentication decision, now is the time to evaluate whether that dependency creates more risk than you realize. Cisco Duo offers a free 30-day trial that lets you explore how Duo Single Sign-On (SSO) and Duo Multi-Factor Authentication (MFA) work as a second identity layer alongside your existing infrastructure.

Modern hybrid and multi-cloud adoption typically results in a sprawl of disparate identity systems. The common approach to bridge these silos is through identity federation. Software as a Service (SaaS), Infrastructure as a Service (IaaS), and private applications are redirected to a central Single Sign-On (SSO) system using Security Assertion Markup Language (SAML) or OpenID Connect (OIDC).

This approach delivers real benefits. Security administrators manage one Identity Provider (IdP), which simplifies configuration for Multi-Factor Authentication (MFA), joiner-mover-leaver processes, conditional access policies, and group memberships. Users benefit from not having to remember different credentials for every system they access.

The result is one of the rare occasions where stronger security also delivered a better user experience.

However, this consolidation has a side effect. Most organizations now depend on a single Identity as a Service (IDaaS) provider, usually determined by whichever collaboration suite the organization adopted. That single IdP has become the authentication core for every application, every user, and every access decision.

Having a unified identity system creates what risk professionals call concentration risk: a single point of failure in a critical layer. This risk has four distinct dimensions, and each one can affect your organization differently.

1. Availability risk measures the scope of impact when outages or incidents occur. IDaaS depend on a complex chain of globally shared components, including cloud infrastructure, Border Gateway Protocol (BGP) networks, Domain Name System (DNS), and internal application services. A faulty global configuration change in any one of these components can disrupt the entire downstream IDaaS service. If your organization depends on a single IDaaS provider for all authentication, the blast radius of an outage extends to every application and every user. Consider a scenario where your IdP experiences a four-hour outage during peak business hours. Every employee across every office loses access to every federated application simultaneously. Help desk tickets spike, productivity stops, and revenue-generating activities halt.

2. Security risk reflects the impact of a systemic compromise. IDaaS providers are mega technology vendors and gatekeepers of large cloud systems and sensitive data sets. This makes them primary targets for threat actors. A compromise at the IdP level does not just affect one application. It potentially exposes every application and data set that trusts that IdP for authentication decisions. Organizations that depend on a single IdP have no alternative authentication path if that provider is compromised.

3. Vendor risk covers reduced negotiation leverage and technology dependencies. IDaaS providers linked to collaboration suites typically optimize their identity products to work best within their own ecosystem. This incentivizes deeper buy-in and increased consumption of their technology stack. Over time, this creates contractual and technical lock-in that weakens your financial leverage and restricts your choice of technologies compared to using a mix of providers.

4. Business continuity risk addresses financial, legal, and regulatory exposure. Regulatory frameworks increasingly require organizations to demonstrate resilience in critical systems. If an identity outage prevents access to systems that support compliance obligations, the consequences extend beyond lost productivity into potential regulatory findings and legal liability.

Eliminating single points of failure has always been a core principle of risk management. The concept of N+1 redundancy has been adopted across virtually every layer of infrastructure design:

• Power systems use redundant supplies and generators

• Cooling systems use backup units to prevent thermal failures

• Compute and storage systems use clustering and replication

• Network infrastructure uses redundant paths and failover routing

• Firewalls and security appliances use high-availability pairs

• Databases use replication and geographic distribution

Each of these systems is considered too critical to operate without a backup. Yet most organizations accept a single point of failure in the very system that controls access to all of these resources.

If N+1 is standard practice for power, compute, networking, and firewalls, identity should not be the exception.

An additional IdP can provide contingency access and reduce concentration risk. However, you must weigh these advantages against certain new risks that a second IdP might introduce.

Security parity matters. If the additional IdP has weaker security than your primary IdP, the overall security posture for the organization becomes weaker. Security is as strong as the weakest link. When selecting a second IdP, evaluate its MFA capabilities, phishing resistance, and conditional access policies against the same standards you apply to your primary provider.

Complexity increases the risk of human error. An overly complex multi-vendor approach can lead to configuration mistakes that cause downtime. We recommend limiting your identity infrastructure to no more than two IdPs. This provides resilience without introducing unmanageable complexity.

SAML assertion consistency is critical. If the primary IdP and backup IdP differ in how they issue SAML assertions, users may be exposed to spoofing attacks. Ensure that both providers use consistent assertion formats, signing certificates, and attribute mappings.

Before implementing a mitigation strategy, start by understanding your current exposure. Ask these questions:

• How many applications depend on your primary IdP for authentication?

• If your IdP went offline for four hours, which mission-critical systems would remain accessible?

• Do you have an existing on-premises IdP that could serve as a failover option?

• Does your current IdP vendor also provide your collaboration suite, creating both identity and productivity dependency on the same provider?

• Have your compliance or audit teams flagged identity as a concentration risk?

If the answers to these questions reveal significant dependency, you are not alone. Most organizations that have consolidated to a single IdP face this exposure. The important step is acknowledging it and building a plan to address it.

Next week, we will publish a companion post that walks through two proven approaches for mitigating IdP concentration risk: the backup IdP model and the split IdP model. The backup approach involves maintaining a secondary IdP that you can fail over to during disruptions. The split approach involves running two IdPs concurrently with your user base distributed across both, so a single outage never affects your entire organization.

That post will cover the implementation details, including how to reuse an existing on-premises IdP, how to keep your backup IdP hydrated with your current user base, how to prepare SAML and OIDC profiles in advance, and how to test your failover process. If you have read this far and recognize that your organization faces IdP concentration risk, that post will give you the practical playbook for addressing it.

We do not accept single points of failure in our power grids, our databases, or our networks. It is time we apply the same standard to our identity systems.

If you are evaluating how to build resilience into your identity infrastructure, the IAM Buyers Evaluation Guide covers directory strategies, IdP selection criteria, and how to assess providers for redundancy and failover. Download the IAM Buyers Evaluation Guide.

Endpoint management platforms sit at the intersection of identity and device control. A compromised administrator does not need to find a zero-day or write custom malware. They already have the keys to push configurations, wipe devices, and modify security policies across an entire fleet.

This is not a theoretical risk. It is a documented pattern, and it has a name: identity-based attacks on management infrastructure. Every time an attacker compromises administrative credentials for platforms like Microsoft Intune or Entra ID, they turn the tool designed to protect endpoints into a weapon. No malware required. No vulnerability exploited. Just identity governance that was not working the way it should.

For a deeper look at why administrative access is vulnerable when it is not governed properly, read Cisco Duo's guide to privileged access management risks.

In early 2026, a cyberattack hit Stryker Corporation, a major U.S. medical technology firm, and disrupted operations globally. No ransomware was deployed. No novel malware was found. Attackers compromised administrative credentials for Microsoft Intune and Entra ID, turning Stryker's own endpoint management infrastructure into a weapon for destructive wiper operations.

Following the attack, CISA issued an alert urging U.S. organizations to strengthen their endpoint management configurations. All three of CISA's recommendations, least privilege, phishing-resistant multi-factor authentication (MFA), and multi-admin approval, point to the same underlying problem: identity governance for the systems that manage devices and access is not keeping pace with how attackers operate.

The Stryker incident is not an outlier. It fits a pattern that security teams should recognize.

Expel's 2026 Annual Threat Report found that 68.6% of all security incidents last year were identity-based attacks, with nearly half resulting in successful authentication using stolen credentials. Endpoints accounted for 29% of all incidents. The overlap between these two categories, where compromised identities meet device management infrastructure, is where the greatest risk lives.

The compounding problem is dwell time. IBM's 2024 Cost of a Data Breach Report found that breaches involving stolen credentials take an average of 292 days to identify and contain. Apply that timeline to a compromised endpoint management administrator, and the attacker has nearly 10 months of access to push policies, modify configurations, and stage destructive payloads, all through legitimate tooling that will not trigger traditional malware detection.

Meanwhile, most organizations still treat endpoint management consoles with less rigor than they apply to their cloud infrastructure. Only 6% of organizations report fully automated endpoint management, according to Automox's 2026 State of Endpoint Management Report. Forty-three percent of IT teams spend more than 10 hours per week on manual endpoint tasks, time that is not being spent auditing who has administrative access or whether those permissions are still appropriate.

Identity threat detection and response (ITDR) for management infrastructure is not a feature most organizations have implemented. The gap between how attackers exploit administrative credentials and how organizations monitor those credentials remains wide.

CISA's alert reads like an endpoint management checklist. But every recommendation maps directly to identity and access management. You cannot harden endpoint management without first hardening identity.

Least privilege means ensuring people have only the access they need, only for as long as they need it. That starts with knowing who has elevated access, what they can do with it, and whether those permissions are still justified.

Most organizations over-provision MDM administrators because privileges accumulate on accounts over time and are rarely audited, largely due to limited visibility across the identity landscape. Step-up authentication, where administrators must verify their identity again before performing high-impact actions, adds a dynamic control layer that static role assignments cannot provide.For a comprehensive framework on implementing least privilege for administrative accounts, see Cisco Duo's privileged access management best practices guide.

Phishing-resistant MFA goes beyond push notifications and SMS codes. Organizations that enforce phishing-resistant MFA block over 99% of identity-based attacks. It relies on cryptographic authentication tied to a physical device, blocking the credential interception techniques that made the Stryker attack possible.

Traditional MFA approaches, including app-based push notifications, are increasingly vulnerable to adversary-in-the-middle attacks and MFA fatigue. In a fatigue attack, an attacker triggers repeated push notifications until the user approves one out of frustration. In an adversary-in-the-middle attack, the attacker intercepts the authentication session in real time, capturing both the credentials and the MFA approval. Neither attack works against FIDO2-based authentication because there is nothing to intercept or approve.

CISA is specifically calling for FIDO2-level assurance for privileged accounts. To learn more about what phishing-resistant MFA is and how to implement it, see Cisco Duo's guide to phishing-resistant MFA.

Multi-admin approval means a single compromised identity cannot unilaterally execute destructive operations. This is the control that could have limited the blast radius at Stryker. But it only works if the identities approving those actions are themselves verified through strong, phishing-resistant methods.

Without multi-admin approval, an attacker with one set of compromised administrative credentials can wipe devices, push malicious configurations, and modify security policies with no second check. With it, destructive actions require verification from multiple verified administrators, reducing the blast radius of any single compromised account.

The Stryker attack and the CISA alert point to a set of capabilities that any identity security platform should provide for organizations managing endpoint infrastructure. The question is not whether to strengthen identity controls for administrative access, but what those controls should look like.

Phishing-resistant authentication without hardware keys. FIDO2-level assurance has historically required expensive hardware key rollouts. Cisco Duo's proximity verification uses Bluetooth Low Energy between a user's laptop and mobile device to establish phishing-resistant authentication at FIDO2-level assurance without shipping and managing hardware tokens. Cisco reports 50%+ cost savings compared to traditional hardware key deployments. This covers the full authentication lifecycle: OS login, application access, and mid-session verification.

Post-authentication session protection. Authentication does not end at login. Attackers increasingly steal session cookies to bypass MFA entirely, no credentials needed. Duo Desktop replaces traditional session cookies with cryptographic challenges that cannot be replayed, closing the post-authentication gap that most identity solutions leave open.

Unified identity visibility across fragmented environments. Most enterprises run multiple identity providers, including on-premises Active Directory, Entra ID, and often a third cloud provider. Duo Identity Intelligence creates a converged identity graph across these sources, surfacing dormant accounts, excessive privileges, and identity drift between HR systems and directory services. This is exactly the visibility needed to implement CISA's least-privilege recommendation at scale, not just for Intune but across the entire administrative landscape.

Risk-based access policies driven by user trust scores. Rather than static role assignments, Duo continuously evaluates user trust based on behavior, device posture, and cross-platform signals, then enforces differentiated access policies in real time. Administrators flagged as high-risk can be automatically stepped up to stronger verification or temporarily restricted.

Cisco secures its own global workforce of 125,000 users and 285,000 devices with Duo, and has been recognized as a Gartner Peer Insights Customers' Choice for User Authentication two years running.

To understand the foundational principles behind this identity-centric security approach, see Cisco Duo's guide to identity security.

The Stryker attack was not exotic. It was predictable and preventable with identity controls that already exist. The CISA alert confirms what security architects have known: endpoint management systems are critical infrastructure, and they deserve the same identity rigor as your most sensitive applications.

Every security leader should be asking two questions this week:

• Who has administrative access to our endpoint management platform?

• Would we detect it if one of those credentials was compromised?

If the answers are not immediate and confident, the hardening work starts with identity.

Download the Guide to Restoring Trust in Identity to learn more about strengthening identity controls for administrative access and reducing risk in your environment.

Going passwordless is one of the most impactful steps an organization can take to reduce phishing risk and simplify the authentication experience. We’ve seen broad customer adoption of Duo Push for passwordless thanks to its familiar user experience, and we’re committed to continuously improving that experience.

Today, we’re introducing enhancements to Duo Passwordless Push for Duo SSO apps that address limitations of the browser cookie-based approach used to establish device trust. Previously, switching browsers, setting up a new laptop, or simply clearing cookies could force users back to a password. That friction makes achieving true passwordless more difficult.

By integrating Duo Desktop into the passwordless workflow and adding Bluetooth proximity verification, we’ve made Duo Passwordless Push more resilient, more consistent, and ready for organizations that want to go all in without compromise.

Duo Passwordless Push works by verifying that a user's browser is recognized before allowing access. Until now, that trust relied on a browser cookie. Cookies work in many use cases, but they come with limitations that surface in everyday scenarios.

For example, when logging in from an embedded browser where cookies don’t persist, Duo Passwordless Push becomes an unviable method and requires users to log in with another method; usually, that means passwords and two-factor authentication (2FA). For teams that have disabled password fallback to fully commit to passwordless, this can stop a user's day in its tracks.

Clearing cookies also means starting over. IT policies, browser updates, or users tidying up their settings can all wipe cookies.

Furthermore, when users get new laptops, no pre-existing trust signals like cookies exist to allow passwordless push. Users must either re-enroll or authenticate again on that device first to obtain a cookie before passwordless push is available to use. These limitations make achieving true passwordless challenging.

With Duo Desktop registered on an endpoint, device trust is now stored server-side and tied to the device itself instead of a single browser. When a user marks a browser as known during authentication, that trust decision is associated with the endpoint through Duo Desktop. The next time they sign in, even from a different browser, Duo Desktop identifies the device and the trusted status carries over automatically.

Cookies are still supported as an optional fallback for scenarios where Duo Desktop is not running. This ensures a smooth rollout with no disruption.

In practice, this means users no longer lose device trust. Switching browsers, clearing cookies, or resetting profiles no longer sends them back to square one.

To address the new laptop problem, we’ve introduced a highly secure way to establish device trust. When a user signs in from an unrecognized endpoint, they’re prompted to enter a Duo Mobile one-time-passcode (OTP), followed by Bluetooth proximity verification. This confirms that their registered mobile device is physically nearby before completing the passwordless push.

This layered approach prevents common attacks such as push harassment and remote phishing. There’s no password, no fallback factor, and no manual Bluetooth device pairing. Duo Desktop and Duo Mobile handle the Bluetooth handshake seamlessly in the background while the user simply approves the push. The result is a clean, secure path to truly passwordless onboarding.

Administrators get two new policy options to tailor the authentication experience based on their risk tolerance:

1. First, you can choose whether Bluetooth proximity verification is required only on unrecognized endpoints (the default) or required on every passwordless login for a stricter posture in more critical environments.

2. Second, you can disable browser cookies as a trust signal. With Duo Desktop handling trust at the endpoint level, cookies are no longer necessary. Removing them from the equation means a stolen or replayed cookie can never be used to satisfy the device trust check for a passwordless push. This hardens your passwordless deployment against cookie theft without impacting user experience, since Duo Desktop handles device recognition seamlessly.

Passwordless authentication should simply work. It should feel natural to users, dependable across devices, and strong enough to meet modern security standards.

Duo Passwordless Push delivers that experience. Trust stays anchored to the device, creating consistency across browsers and sessions. New endpoints can establish trust quickly and securely from day one. At the same time, administrators gain granular controls to shape the experience according to their security requirements.

These enhancements make Duo Passwordless Push a robust, scalable foundation for organizations ready to embrace a true passwordless future.

To get started, visit our Passwordless Quick Start Guide and documentation.

Interested in learning more about how Duo helps defend against modern phishing attacks? Get the free guide to Building End-to-end Phishing Resistance or try it for yourself with a free trial of Duo IAM and Passwordless today.

What is Duo Passwordless Push?

Duo Passwordless Push allows users to authenticate without entering a password by verifying their identity through a push notification to the Duo Mobile app. It combines device trust verification with user approval to provide a secure, phishing-resistant login experience for applications protected by Duo Single Sign-On (SSO).

What about Passwordless Windows Logon?

The passwordless capabilities discussed in this post apply to web-based applications protected by Duo Single Sign-On (SSO), where users authenticate through a browser. Duo also offers Passwordless OS Logon feature for Windows, which eliminates passwords at the Windows desktop login screen itself. To learn more about Passwordless Windows Logon, visit here.

How does Duo Desktop improve passwordless device trust?

Duo Desktop stores device trust server-side and ties it to the endpoint rather than relying on a browser cookie. This means trust persists across browsers, survives cookie clearing, and carries over automatically when users switch between browsers on the same device.

How do I establish passwordless trust on a new laptop?

When a user signs in from an unrecognized endpoint, Duo prompts them to enter a Duo Mobile one-time passcode followed by Bluetooth proximity verification. This confirms that the user's registered mobile device is physically nearby, establishing device trust securely without requiring a password.

What is Bluetooth proximity verification in Duo?

Bluetooth proximity verification is a security feature that confirms a user's registered Duo Mobile device is physically near the endpoint during authentication. Duo Desktop and Duo Mobile handle the Bluetooth handshake automatically in the background, requiring no manual device pairing from the user.

Can I disable browser cookies for Duo Passwordless Push?

Yes, administrators can disable browser cookies as a trust signal through Duo policy controls. With Duo Desktop handling device trust at the endpoint level, cookies are no longer necessary. Disabling cookies prevents stolen or replayed cookies from satisfying the device trust check for passwordless push.

What is the difference between cookie-based and device-based trust in Duo?

Cookie-based trust relies on a browser cookie to recognize a device, which means trust is lost when cookies are cleared, browsers are switched, or a new device is used. Device-based trust through Duo Desktop ties recognition to the endpoint itself and stores it server-side. This approach provides consistent trust across browsers and sessions without depending on cookies.

The pace of innovation with agentic AI is genuinely staggering, and if you're a security leader trying to keep up, you are not alone in feeling like the ground is shifting beneath your feet. Every week there is news about new model updates, tooling, and capabilities for agentic AI.

Somewhere in your environment right now, an AI agent is almost certainly operating without a proper identity, a defined owner, or any meaningful access controls. Developers are already connecting agents to production systems without looping in IT.

This is exactly why we built Duo Agentic Identity.

AI agents aren't productivity tools. They're autonomous actors that query databases, trigger workflows, send communications, and make decisions—capable of operating at machine speed and without human oversight. That's enormously powerful. It's also a security challenge your existing tools were never designed to handle.

Every agent is effectively some level of privileged identity with access far beyond what normal users have." - CISO, Technology sector

Agentic AI breaks the core assumptions of your current identity stack.

1. Identities operate at human speed and they are static. A human identity is defined at onboarding and updated infrequently. Agent identities are the opposite. They spin up at machine speed and are continuously evolving, shaped by changing tasks, new workflows, and model updates.

2. Credentials are issued centrally and managed deliberately. Agents often inherit credentials from the LLM contexts they operate in, reuse tokens scoped for their human principals, or self-provision access through flows designed for human login. The credential chain is murky at best, brittle and insecure at worst.

3. Access permissions can be relatively broad and long-standing. Coarse-grained access is more permissible when humans (who in most cases exhibit good judgement) are behind the wheel.

Non-human identity (NHI) governance tools exist, but they were designed for service accounts and API keys—static, predictable entities. They weren't built for the per-action, per-session enforcement that agentic AI demands.

The result is a widening gap between how fast organizations are adopting agents and how well those agents are governed. We need to fill that gap.

Most security teams are already stretched thin; organizations must manage human identity programs while trying to make sense of a rapidly evolving agentic landscape.

That's why Duo Agentic Identity is designed to meet you where you are. Whether you're just beginning to inventory your agents or already running them in production, we've built a path forward that doesn't require you to have everything figured out before you start.

What this moment requires is a platform that finds agent activity, governs agent identities end-to-end, and enforces least-privilege authorization at the level of individual actions—built on the identity and network foundation you already have.

"The first thing for us is discoverability. That's 100% the number one requirement." - Security Architect, Travel sector

Visibility into agentic activity is foundational. Most organizations already have agents running that no one in IT approved, owns, or can account for.

Duo Agentic Identity extends Cisco Identity Intelligence to provide a dynamic inventory of active AI agents across your environment. Unlike periodic scans, this is a continuous check; the moment an agent starts operating, it appears in your identity inventory.

Critically, because Duo Agentic Identity is built on the Cisco platform—which spans both identity and network—the solution can surface agents that have never formally registered with your identity provider (IdP). Traditional identity tools see what authenticates against them. Cisco sees what communicates across your infrastructure. That makes true shadow agent detection possible, and it's an architectural advantage of our approach.

"Agent identities need to be first-class non-human identities, with tight controls around privileges and what they have access to." - CISO, Healthcare sector

Every agent operating in your enterprise needs a proper identity lifecycle: onboarded with clear accountability, monitored during operation, and governed throughout its existence.

Duo Agentic Identity builds on Duo Directory to provide a foundational directory where agents are registered as distinct identity objects—not service accounts, not proxies of their human operators. This development doubles down on our native support of OAuth 2.1 and Model Context Protocol (MCP) to ensure that agents can effectively run with Duo. Each agent is mapped to a human owner, assigned to groups for policy enforcement, authenticated at access and fully logged from the moment it is onboarded.

The result: Every action is traceable to a sponsor. And when an agent's work is done, lifecycle visibility gives your team the confidence to know that access has been removed.

"Access policies for agents need to be least privileged." - CISO, Retail sector

Overprivileged agents are among the highest-risk conditions in any agentic deployment. And in an agentic context, least privilege needs to be a per-action constraint, evaluated at the level of each individual tool call.

Duo Agentic Identity enforces this control through an MCP gateway—a control point between your AI agents and the tools and systems they interact with. MCP is emerging as a standard interface through which agents discover and invoke enterprise tools. Rather than relying on each tool server to enforce access controls correctly, the gateway intercepts every request, evaluates it against Duo's fine-grained authorization engine, and permits or blocks the action before it reaches the target system.

Policies map specific agent identities and groups to specific tool calls, all while enabling granular control over scope, conditions, and permitted operations.

The agentic identity market is filling with specialized tools. Solutions may extend existing NHI governance, ZTNA functionality, or Privileged Access Management (PAM) features. Each addresses real problems. None addresses the full scope.

The reason is architectural. Governing agentic identity effectively requires visibility at two layers simultaneously: the identity layer, where credentials are issued and agents are authorized, and the network layer, where agent communication and enforcement actually occur. Most tools operate at one or the other.

Cisco operates at both layers, and that convergence is what makes it possible to surface shadow agents, enforce policy consistently, and govern across a wide breadth of agentic deployments.

The promise of agentic AI is real: faster operations, smarter automation, and capabilities that can genuinely transform how your teams work. But that value is only safe when it's built on a foundation of trust between humans and the agents acting on their behalf.

The organizations that will manage agentic AI risk effectively are the ones establishing governance frameworks now, before agents proliferate to the point where retroactive governance becomes a remediation project.

Duo Agentic Identity is here to help you build that foundation—at your pace, and with the confidence that you're not going it alone.

Learn more about Duo Agentic Identity here.

As security threats become more sophisticated, the context of an authentication event matters just as much as the success of the event itself.

This is where Authentication Method Reference (AMR) comes into the picture. We are excited to discuss the integration of AMR support into Duo SSO, a new feature designed to provide granular visibility, enhance security control, and significantly streamline the user experience for your workforce.

Authentication Method Reference (AMR) is a standard that allows Identity Providers (IdPs) to share specific details about how a user authenticated during a session.

Without AMR, an identity provider simply tells an application, "This user is verified." With AMR, the IdP communicates exactly how verification happened, such as:

• "This user verified using a password"

• "This user verified using a biometric factor"

• "This user completed multi-factor authentication"

Duo SSO now supports AMR in both SAML and OIDC protocols, moving towards a more nuanced authentication framework that provides additional visibility and context.

Major platforms no longer treat MFA as optional. A prime example occurred on February 3, 2026, when Salesforce began enforcing mandatory MFA for direct logins to combat compromised credentials and account takeovers. Google Cloud has announced similar measures are being rolled out to all users.

If your organization uses SSO to access these platforms and others, this presents a challenge. It is not enough for the IdP to simply log the user in; the IdP must signal that MFA was performed to satisfy these requirements. Otherwise, your users may be blocked from access or forced to register for a separate, redundant MFA method with the service provider.

We expect to continue seeing this trend, with more service providers adopting similar requirements in the future. AMR in Duo SSO ensures that you can meet these evolving third-party mandates without adding friction for your users.

Consider the experience when logging into Salesforce after the MFA mandate took effect. If the IdP does not send the AMR values, Salesforce assumes that MFA did not happen. This triggers a redundant “double prompt” scenario: the user performs MFA to satisfy the SSO requirement but is immediately forced by Salesforce to register or authenticate again.

AMR eliminates this redundancy. By passing precise authentication details via the OIDC ID Token or the SAML AuthNContext portion of the assertion, Salesforce recognizes that a strong MFA method was already used during the SSO flow. It will then dynamically skip the second prompt, creating a frictionless experience for your users without compromising security or increasing help desk tickets.

AMR support represents a shift from static authentication to dynamic, context-aware security. By implementing standards-compliant AMR mappings, Duo SSO ensures that you can meet rigorous security requirements while keeping the user experience simple and straightforward.

Enable AMR values for both new and existing Duo SSO integrations. Duo maps your authentication methods to standard AMR values automatically.

To get started:

• Review the Duo SSO documentation for configuration steps.

• See the knowledge base article for platform-specific guidance.

New to Duo? Start a free trial to see how Duo SSO simplifies authentication for your workforce.

I recently presented a webinar called "Compliance Made Simple with Cisco Duo for Public Sector." The audience included government IT teams, K-12 technology leaders, and law enforcement agencies.

These organizations share something in common with small and mid-size businesses: limited staff, strict requirements, and users who don't want security slowing them down.

As I prepared for that session, I realized the compliance challenges public sector teams face are nearly identical to what SMBs experience: whether you handle payment card data, work with government agencies, support healthcare patients, or simply need to satisfy your cyber insurance provider, the requirements all come down to the same four questions.

The barriers to success are the same. And the solutions that work are the same.

Ready to see how Duo simplifies compliance for your organization? Start your free trial and experience it yourself.

Strip away the jargon and every compliance requirement asks:

1. Who is the user?

2. What device are they on?

3. What policy applies?

4. Can you prove it?

No matter how many pages the compliance document contains, it always comes back to these four. The rest is formatting.

When I share this with IT administrators, I see relief on their faces. Compliance feels overwhelming because the documents are written in language that looks like English but somehow isn't. Breaking it down to four questions makes the path forward clear.

Once you understand the four questions, you need controls to answer them. I organize these into three components:

• Identity controls

• Device controls

• Access policies with audit capabilities

Compliance frameworks now require multi-factor authentication (MFA) for both privileged and non-privileged users. Static passwords alone no longer meet modern compliance standards. MFA is not optional for regular users. It is required for everyone who accesses sensitive systems.

Cisco Duo addresses identity requirements through a wide range of authentication methods.

• Duo Push provides fast, familiar authentication for smartphone users, with options for number-matching and proximity-based verification.

• Hardware tokens serve field workers and anyone without a smartphone.

• Time-based one-time passwords (TOTP) and FIDO2/WebAuthn support offer additional options based on your security requirements against replay resistance.

See how Duo aligns with NIST 800-63-3 AAL2/AAL3 requirements for phishing-resistant authentication.

The adoption piece is also critical here. I've seen MFA rollouts fail because users fought the change. Duo succeeds because it stays out of the way. Duo Push takes seconds, and the experience feels familiar. If your MFA solution requires a 40-page deployment guide and a week of training, adoption is already in trouble.

Compliance frameworks now require endpoint validation and patching verification before granting access, making device trust essential. Auditors increasingly ask about endpoint posture, and "we authenticated the user" is no longer a complete answer.

Duo Device Health checks operating system version, patching status, encryption, and screen lock settings at every login. When a device doesn't meet requirements, Duo guides users to fix the issue themselves. This "self-remediation" process means fewer help desk tickets for IT teams already stretched thin.

This also solves a common problem for organizations dealing with bring-your-own-device (BYOD) environments. You can't install mobile device management (MDM) software on personal devices, but you're still responsible when those devices access your network. Duo validates device posture without requiring MDM installation. Users keep control of their personal devices while you maintain visibility into security posture.

Compliance frameworks don't just ask whether you authenticated someone; they ask under what conditions. This is where context-based access policies become essential.

Duo lets you apply policies based on user role, device type, location, and network. A contractor accessing sensitive data from an unmanaged device might face stricter requirements than a full-time employee on a company laptop. With Duo, you define the rules based on your risk tolerance.

The audit piece completes the picture. At some point, someone will ask: who accessed this system, from where, on what device, and under what policy? Duo logs all authentication events with this detail. During an audit, you pull the report. During a security incident, you investigate quickly instead of reconstructing events from scattered sources.

When I ask customers why they chose Duo, the answer isn't technical. They tell me their users didn't fight it, their help desk tickets went down, and their audits got easier. For a small IT team, this matters more than any feature list.

I genuinely believe Duo makes the compliance journey simpler for organizations of any size. I've seen it work for public sector teams with the strictest government requirements and the smallest staff. The same approach works for small and mid-size businesses facing similar challenges.

The frameworks all ask the same four questions. The controls break down into three manageable components. And Duo deploys in hours, not weeks.

For a deeper dive into the four questions every auditor asks, watch the full replay of my webinar, Compliance Made Simple with Cisco Duo.

Start your free trial of Cisco Duo and see how Duo helps simplify compliance for your organization.

Most major compliance frameworks now require MFA for all users, not just administrators. These include CJIS (Criminal Justice Information Services) for law enforcement, NIST (National Institute of Standards and Technology) guidelines for government contractors, CMMC (Cybersecurity Maturity Model Certification) for defense suppliers, PCI DSS 4.0 (Payment Card Industry Data Security Standard) for organizations processing credit cards, and FFIEC (Federal Financial Institutions Examination Council) guidelines for financial institutions. Many cyber insurance policies also require MFA as a condition of coverage.

Focus on the four questions every framework asks: who is the user, what device are they on, what policy applies, and can you prove it. Choose tools that address these questions without requiring dedicated expertise to manage. Duo deploys in hours and reduces help desk tickets rather than increasing them.

Device trust means validating that a device meets security requirements before granting access to sensitive systems. Compliance frameworks now require endpoint validation including patching status and encryption. Duo Device Health checks these factors automatically at each login without requiring MDM installation on personal devices.

Two-factor authentication (2FA) requires exactly two factors to verify identity. Multi-factor authentication (MFA) requires two or more factors. In practice, the terms are often used interchangeably, though MFA can include additional factors for higher security environments.

Duo logs all authentication events including user identity, device information, location, and which policy was applied. These detailed logs help you answer auditor questions about who accessed systems and under what conditions. During security incidents, the same logs enable faster investigation and response.