Security | Threat Detection | Cyberattacks | DevSecOps | Compliance

If your identity governance program feels like a relic from a simpler time, you’re not alone. Traditional identity governance and automation (IGA) was built for a world where job titles told the whole story. A software engineer was a software engineer; a sales rep was a sales rep. Assigning access was intended to be as simple as slotting people into predefined roles.

Most security teams cannot confidently answer a simple question: who has access to which cloud resources right now? Human identities and accounts now span across thousands of services, subscriptions, and SaaS platforms. The result is a vast, decentralized environment riddled with “unknown unknowns” that security teams cannot fully map, and that traditional security controls weren’t designed to address. Attackers count on these identity blind spots.

Security teams are under more pressure than ever, reacting at human speed while systems, identities, and AI agents operate at machine speed. In this episode of Security Matters, host David Puner sits down with cybersecurity leader and former FBI executive MK Palmore to explore why defenders struggle to keep pace and what it takes to regain control.

In today’s smart factories, production doesn’t go quiet at shift change. Behind the scenes, modern manufacturing systems never cease. They continuously exchange data, adjust software and processes in real time, and allow vendors to connect remotely to monitor performance or deliver updates. As these interactions multiply, the number of identity-driven points grows just as quickly.

Most organizations have gotten very good at protecting the front door. We invest heavily in single sign-on (SSO), mandate multi-factor authentication (MFA), and lock down who can log in, from where, and under what conditions. We do everything to ensure that the right user has the right access. But one critical question often still goes unanswered: What really happens after someone logs in?

When a production line stops, the clock starts ticking. In manufacturing environments I’ve worked in, every minute of downtime can translate into missed delivery commitments and revenue you’ll never see again. How long that outage lasts will be decided in the first few minutes, when identity ownership and decision authority are still being sorted out. That authority gap is easy to underestimate. Manufacturing leaders already plan extensively for physical disruption.

In my experience working inside banks, identity security can be like plumbing: when it’s working, no one wants to talk about it. When there’s an incident, an audit, or a regulator—suddenly everyone wants to understand how it works. Artificial intelligence (AI) brings the same “no one cares until everyone does” energy, but with face-melting velocity. Today, AI is embedded across large parts of the financial services industry, and it has been around for more than 25 years.

For years, identity has been treated as a supporting function, authenticating users, gating access, and satisfying audit requirements. Important, but rarely foundational. That era is over. In modern enterprises, identity has become the infrastructure on which critical systems depend. Every workload, certificate, API, automated process, and AI-driven action must rely on identity to operate safely and predictably. When identity fails, those systems become exposed—and often stop behaving as expected.

CyberArk founder and executive chairman Udi Mokady returns to Security Matters at a transformational moment—now as part of Palo Alto Networks, following the acquisition’s close on February 11. In this far‑reaching conversation, Udi and host David Puner explore why identity has become the attack vector for modern enterprises, driven by an unprecedented surge in human, machine and AI‑powered identities that attackers increasingly exploit.

As AI systems are used in our day-to-day operations, a central reality becomes unavoidable: AI doesn’t configure itself and must be set up with human approval and oversight. It requires engineers and developers to configure it. Developers need privileges to access and implement components, agents, tools, and features of the platforms. But developers don’t just have these privileges unconstrained… right? Where trust and privileges exist, someone will try to abuse them.