When breach becomes personal. CISOs, identity failures and the road to continuous governance

Today, identity and access management failures can swiftly end careers. CISOs are no longer just protecting the company. They’re also defending their own reputations and even personal liability. As Aram Andreasyan, Head of Solutions at Cerbos, puts it, the accountability model in security has shifted from the organization to the individual CISO.

In years past a breach was “just” a corporate crisis, but now breaches often follow the security leader in the form of blame, termination, or legal consequences. Surveys back this up: over half of CISOs fear they’d be fired for a breach on their watch, and 40% worry they might even be held personally liable. The result is a new culture of personal risk-awareness among security chiefs. This shift is the focus of a recent conversation we had with Giao Nguyen, IAM advisor at 1Kosmos, who brings decades of IAM experience to bear on why identity has become such a pressure point.

Why is identity at the center of this shift? Gartner has famously predicted that by 2023, 75% of security failures would result from inadequate management of identities, access, and privileges. In other words, if you get IAM wrong, everything else in security can crumble. Meanwhile, breaches tied to identity issues tend to be costlier than average incidents - one report found 44% of organizations say an identity-related breach cost more than a typical data breach.

It’s not surprising, then, that CISOs feel the spotlight on them personally. When identity controls fail, they are often the ones answering to the board, or even to regulators. Giao notes that modern CISOs fully understand this expanded responsibility. Their job isn’t just cyber defense anymore - it’s also protecting their own credibility and “personal branding” as security leaders. In the conversation, Giao stressed that today’s CISOs approach decisions with a dual mindset: What’s the risk to the company? And what’s the risk to me personally if I get this wrong?

 

The hidden challenges of modern IAM programs

If strong IAM is so clearly vital, why do so many programs struggle or stall? Aram and Giao point to a perfect storm of funding constraints, organizational blind spots, fragmented tools, and cultural roadblocks that IAM leaders must navigate.

Many CISOs inherit under-resourced IAM programs - small teams, legacy tech, years of accumulated technical debt. As Aram observed, some were “set up for failure” long before the current CISO took the helm. Pushing for improvements means fighting uphill for budget and priority. And if IAM was previously neglected, there will be no quick fix; even a chief executive can’t turn a ship on a dime in a large enterprise. Giao noted that time is often the scarcest resource - security changes are slow, even when the CISO has a clear vision and mandate.

One big challenge is organizational culture. IAM issues are as much about people and process as technology. For example, data hygiene in identity systems is a chronic problem. It’s easy to assume that “the tools” will take care of identity data quality, but in reality most organizations have identity data scattered across dozens of systems. (In fact, the average enterprise uses over 10 separate identity tools.) When those sources are out of sync, you get conflicting information about who has access to what. Bad data leads to bad dashboards, bad risk scores, and failed audits - garbage in, garbage out. Giao emphasized that fixing this is a leadership issue above all. “If the top doesn’t care about data, then why should I care?” he says - meaning senior management must set the tone for clean, connected IAM data. In many companies, this culture isn’t in place; IAM teams end up trying to reconcile messy data from myriad sources without executive support. It’s an uphill battle that leaves glaring blind spots.

Then there’s the fragmentation of IAM tooling. Enterprises often accumulate identity systems over years: an HR directory here, a legacy LDAP there, a cloud SSO, multiple admin consoles, etc. Aram recounted a conversation with one IAM executive who said, “I’ve got 45 different identity tools... I know who the users are, but I have zero visibility into what they actually do once they’re inside.” This is sadly common. When you have a patchwork of identity silos, it’s difficult to enforce consistent policies or monitoring. An admin may have to look in five different places to piece together a user’s access history. That makes it easy to overlook risks and hard to answer basic governance questions. Giao notes that IAM teams are often asked to do more with less - more integrations, more controls - but without the budget to consolidate or properly staff these efforts. In short, underfunding + tool fragmentation = major blind spots. The CISO might not even know about an exposure until an audit or incident forces it to light.

Organizational silos add another layer of difficulty. Effective IAM spans HR, IT, security, application owners, compliance, etc., but those teams don’t always communicate well. CISOs often have to build alliances across departments just to get basic information. Giao explained that many security leaders proactively reach out to other teams asking, “Hey, what’s going on in system X? How are we managing Y?”. They do this because they know there may be problems in those areas, but they lack direct visibility. Sometimes the response is “We think it’s fine”, until an incident proves it wasn’t. The reliance on other teams, and the need to “beg, borrow, and steal” data, is a clear sign of immature IAM governance. It also ties back to culture: if other departments don’t see security as a shared responsibility, the CISO’s job gets exponentially harder.

 

Weak onboarding & identity verification: A new frontline for attackers

One particularly worrisome blind spot discussed by Aram and Giao is the onboarding and identity proofing process for new employees or contractors. In an era of remote work and virtual hiring, threat actors are finding ways to exploit weaknesses at the gate. Nation-state attackers have literally posed as job candidates to infiltrate organizations. Giao referenced recent cases of North Korean operatives using deepfakes in video interviews - essentially puppeteering fake personas to get hired at IT companies. It sounds like spy fiction, but it’s real. If a fake candidate slips through HR’s identity verification and lands a job, they become an insider with valid credentials - a perfect beachhead for espionage or theft.

So how prepared are companies for deepfake-enabled insider threats? “Unfortunately, not very,” says Giao. Many organizations are still focused on the “regular” IAM to-do list - provisioning, SSO, password management, etc. - and haven’t invested in robust identity verification for hiring. They might copy a driver’s license and call it a day.

Smaller firms often assume they can’t afford advanced vetting services. But this complacency is risky. Giao points out standards like NIST 800-63 that define levels of identity assurance - for instance, verifying a passport and Social Security number might give higher assurance than just a driver’s license. Yet many companies don’t rigorously enforce such checks. With remote onboarding now common, it’s easy to onboard a “person” who isn’t who they claim to be. If that initial identity proofing is weak, everything built on top of it (accounts, access, trust) is on shaky ground.

The consequences are very real. We’re seeing a rise in synthetic employees - fake identities crafted to secure jobs at target companies and then exploit internal access. Some high-profile breaches and espionage cases in recent years started exactly this way. The attackers might spend months or years cultivating a fake persona, complete with social media profiles and credentials, just to land a position. Once inside, they can exfiltrate data or carry out sabotage, often under the radar. It’s a long con, but potentially hugely damaging. This threat isn’t limited to nation-states either; organized cybercriminals and fraud rings are employing similar tactics, using whatever stolen or faked IDs will get them in the door.

To combat this, forward-thinking IAM teams are starting to adopt layered identity verification and adaptive onboarding checks.

Static one-time checks don’t cut it anymore. Instead, organizations are adding things like: document verification combined with live face matching, checks against known fraud databases, even deepfake detection screenings for video interviews. They’re also monitoring for anomalies in the first weeks of access - for example, if a new hire suddenly downloads an unusual amount of data or accesses systems unrelated to their role, that’s a red flag to investigate. Aram noted that device fingerprints, geolocation, and behavioral analytics can be used during onboarding and beyond to continually validate that a user is genuine. In essence, companies need to adopt a “trust but verify” mindset with new identities, especially in remote hiring. Zero trust principles start at Day 0 of employment: never assume the person is legit just because they submitted some documents; use tech and process to gain higher assurance.

The good news is that some enterprises are investing here. Giao mentioned that better-funded organizations are experimenting with deepfake detection services and more adaptive identity proofing as part of their IAM program. They recognize that the cost of a fake hire could far exceed the cost of preventive controls. After all, one malicious insider - even a low-level one - can open the door to massive damage if unchecked. As an industry, we are learning that identity attacks aren’t just about login credentials; they can begin upstream in the hiring pipeline. For CISOs, this means expanding the scope of IAM to include HR processes and working closely with talent acquisition and HR teams. Security awareness now needs to include “how to spot a deepfake applicant” alongside “don’t click suspicious links.”

 

Privilege creep, orphaned accounts & breaches hiding in plain sight

Not all threats are as exotic as deepfakes. In fact, some of the scariest IAM failures are utterly mundane - the result of slowly accumulated access and neglected accounts. Aram called this out succinctly: “The biggest risks are generally not sophisticated. They’re boring, they’re everywhere, and they hide in plain sight.”

One classic example is privilege creep. Over years at a company, employees collect entitlements like badges - access to this system, that database, this new app - and rarely does anyone go back to revoke what’s no longer needed. It’s easier to grant a new permission than to audit old ones. The result is that a typical employee who’s been around a while can end up with far more access than their current role requires. Giao noted this is partly an organizational maturity issue around identity governance. Companies that lack a strong governance process (often those at lower IAM maturity levels) don’t enforce reviews of whether Alice still needs access to System X after she changed jobs two years ago.

How bad is the privilege creep problem? Studies have found that over 90% of identities are using less than 5% of the permissions they have. That’s a staggering inefficiency and a security time-bomb - all those unused permissions are potential entry points for an attacker. Why do organizations struggle to rein this in? Giao highlighted a few reasons:

• Group-based access grants. Many companies use AD or SSO groups to assign access, and over years they accumulate thousands of groups. It becomes unclear what each group really does. People fear that deleting an old group might break something unknown, so they let it linger.

• Homegrown access solutions. Some firms have bespoke databases or scripts for managing permissions. These often lack documentation and oversight, becoming “black boxes” no one wants to touch as staff change.

• Lack of process. If there’s no rule that says “Remove project access when the project ends,” then guess what - it doesn’t get removed. Giao gave the example: if someone stays with a company for Project A (6 months) and then moves on, they often retain access to Project A’s systems indefinitely. Without automated workflows or diligent managers, those privileges just stay hanging out there.

• Fear of breaking things. This is huge. Both IT admins and business owners are often hesitant to revoke anything unless they are 100% sure it’s safe. The downside of a broken business process looms larger in their mind than the abstract security risk of excess access. Thus, “let sleeping privileges lie” becomes the unspoken policy.

The risk is that these orphaned and over-provisioned accounts provide an attacker with a buffet of options if they penetrate the perimeter. All it takes is a stolen credential or compromised machine for an inactive account, and the attacker suddenly has the keys to a lot more than anyone realized.

Insider threats exploit this too. A disgruntled employee might notice they still have access to a sensitive system and use it with malicious intent. Giao shared a real incident from his consulting experience: A company had a service account with an innocuous name that no one fully understood, something like “DC_sync.” It turned out that account had domain admin access to all critical servers, and was primarily used by one old-timer admin. Because it was “working,” they never questioned it - until an audit revealed that the account was actively being used to exfiltrate company data. What happened? A change in leadership had upset the IT admin, who stayed on just long enough to quietly siphon data using that over-privileged service account and sell the data outside. This insider breach only came to light after significant loss, and it hinged entirely on unmonitored, excessive privileges granted years prior.

Sadly, that story is not an isolated case. Service accounts and generic accounts are especially notorious. Often nobody “owns” these accounts in a business sense, so they persist under the radar. They may have static passwords that never changed, or broad rights set when they were created. Attackers know to look for these. For example, the infamous SolarWinds attack and others have shown how attackers gravitate to dormant or unprotected accounts once inside, using them to escalate privileges and move laterally. It’s much easier to hide by using a legitimate (but forgotten) credential than by exploiting a zero-day exploit. That’s why Aram quipped that the worst breaches often aren’t using cutting-edge malware at all - they’re simply “identity done wrong”.

To tackle privilege creep and stale access, organizations need to shift toward continuous visibility and clean-up. Instead of the old-school “annual access review”, which everyone hates and often rubber-stamps, modern IAM programs aim for ongoing detection of excessive or unused access. This might involve tooling that flags when a user hasn’t logged into a system for 90 days, or when a service account hasn’t been used in 6 months. Those become candidates for review or removal. Better yet, automation can revoke them following a notification. Giao mentioned the value of dynamic authorization and policy-based access - for instance, using a system like Cerbos to enforce rules that automatically expire access after a project end-date, or require re-approval for dormant permissions. By embedding logic that “if Project = finished, then disable related roles”, you can preempt a lot of privilege creep.

This is where the industry is heading: using just-in-time access, ephemeral credentials, and fine-grained policies to ensure privileges don’t outlive their purpose. It’s the principle of zero standing privilege - nobody should have more access than necessary at any time, and if they do, it should be automatically curtailed. It’s easier said than done, especially in complex enterprises, but every step in that direction reduces risk.

As Giao noted, many current Identity Governance & Administration tools still rely heavily on static roles and groups. To truly solve privilege creep, organizations will need to complement those with adaptive, context-based authorization that can scale across applications and cloud platforms without a proliferation of static roles. The good news: solutions like attribute-based access control and policy engines, such as Cerbos, are increasingly available to fill this gap.

 

Why “Zero Trust” and adaptive identity are hard in practice

By now, most security leaders accept the zero trust mantra: “Never trust, always verify” for every access decision. So why do so many organizations still struggle to implement zero trust principles, especially around identity? Aram asked Giao whether companies are truly embracing on-demand, adaptive models or if zero trust is still just talk. Giao’s take: conceptually, leaders get it. But complexity is the enemy of execution. Zero trust as a concept has been around for over a decade, but operationalizing it means rethinking how access is granted everywhere.

One big realization is that identity is now the new perimeter. In a world of cloud services, remote work, and SaaS, you can’t fall back on network segmentation alone. Your users and their devices are the boundary, so you need to verify each user’s identity, context, and intent on an ongoing basis. This is why adaptive authentication and authorization have become so important. As Giao put it,

A candid admission: no matter how good our tech is, the human element - whether it’s users falling for phishing, admins misconfiguring an access rule, or developers sharing credentials - introduces variability and risk. Zero trust is difficult because it has to account for this messy human factor, not just tidy network diagrams.

Implementing adaptive identity controls means building systems that can adjust on the fly to risk signals. Many organizations want this: who wouldn’t prefer an approach where high-risk actions get extra checks and low-risk ones get seamless access? In fact, adaptive MFA (multifactor authentication) is one of the more popular starting points: for example, only prompt for MFA if the user is coming from a new device or unusual location. Cloud providers and IAM vendors now offer conditional access policies to enable this. Giao noted that MFA fatigue and prompt-bombing attacks (where users get spammed with auth requests) have driven companies to pursue smarter authentication flows. He’s seen organizations tuning their MFA triggers so that if all signals are normal (same device, typical behavior), the login sails through - but if something is off, step-up challenges kick in. Some are even moving toward risk scoring every login: e.g., if risk score is low, don’t annoy the user; if medium, challenge them; if high, block the attempt.

The technology for adaptive IAM is evolving quickly. Machine learning and analytics can evaluate dozens of factors about a login or access request in real time: device health, user behavior patterns, resource sensitivity, and so on. The result is a dynamic policy decision rather than a static yes/no. For instance, an adaptive system might allow a known developer to access a staging environment from home without MFA on a weekday (normal behavior), but if the same credential tries to access a production server at 2 AM from a foreign IP, it gets automatically flagged and blocked pending additional verification. This is essentially putting zero trust into practice - continuously verifying that each action is appropriate, not just authenticating the user once at login.

So, why isn’t everyone doing this already? Several reasons:

• Legacy systems. Older apps may not support modern identity protocols or contextual checks. If your core HR system can only handle username/password, it’s hard to insert adaptive rules without placing a proxy or wrapper around it.

• Tooling gaps. As Gartner has pointed out, traditional IGA and PAM tools weren’t designed for fine-grained, cloud-speed entitlement decisions. Newer tools like Cloud Infrastructure Entitlement Management are emerging to fill this need, but many organizations are still figuring out what mix of tools covers all their bases.

• Skill and mindset. Designing adaptive policies requires a different way of thinking. Security teams need to define what “normal” looks like and what signals to trust. It’s part analytics, part policy, part business logic. Not all teams have data scientists or advanced analytics readily working on IAM risk scoring.

• Cultural resistance. Zero trust often means saying No (or at least Not without conditions) to things that used to be open. Some IT and business folks resent the extra hoops, especially if early implementations were clunky (e.g., an overzealous system that kept blocking employees from doing their jobs due to false positives). Getting buy-in for adaptive controls requires demonstrating that they improve security and user experience, by removing friction when risk is low.

Giao observed that many organizations remain in a theoretical phase with zero trust - they’ve adopted the language and maybe implemented pieces, but haven’t fully operationalized it across the board. However, the tide is turning. He notes that leaders today are well aware of what needs to be done; it’s more a matter of execution complexity than ignorance. Identity being the new perimeter is not news to them. The challenge is integrating human behavior, which is hard to control or predict, into the security model. “It’s not just a setting in a firewall. You can’t simply tick a box for zero trust,” as Giao says - it requires continuous effort and adaptation as your environment and users change.

Ultimately, the organizations that succeed with adaptive IAM will be those that treat it as a program, not a project. There’s no “finish line” where you declare zero trust done; it’s about building a muscle that constantly adjusts access based on context. That means investing in the right platforms - those that can ingest context and enforce policies in real time, and in people who can tune and maintain the system. It’s a journey of maturity - often tying closely with the IAM governance maturity of the org.

 

The disconnect between IAM tools and true governance

Speaking of maturity, Aram and Giao spent time on a striking paradox: enterprises have more IAM tools than ever, yet still struggle with basic governance and audit readiness. Many CISOs deploy IDaaS, SSO, PAM solutions, IGA suites - you name it - believing these will automatically solve their problems. But technology alone doesn’t equal maturity. When audit time comes, logs are fragmented across those tools, decisions aren’t tied to clear policies, and suddenly the organization is scrambling in fire-drill mode.

Does this sound familiar? It’s the last week of the quarter, auditors ask for proof of who approved which access, and security teams are frantically pulling data from multiple systems into spreadsheets. Despite all the fancy IAM products, audit evidence isn’t readily available in one place. Governance processes, like review sign-offs, attestation of least privilege, etc., might still live in emails or ticketing systems separate from the IAM enforcement tools.

The core issue is often data quality and integration. If each tool is an island, there’s no single source of truth for “who has access to what and why.” As Aram quipped, governance is sometimes thought of as boring paperwork, but in reality it comes down to data coherence. Without reliable identity data and activity logs, even the best policies on paper can’t be proven. Giao echoed that CISOs are usually aware they have these blind spots. Few are genuinely shocked when an audit finds gaps; more often, they knew about the gaps but hadn’t gotten the funding or internal cooperation to fix them beforehand. It’s not that they were hoping to “coast on hope” forever - it’s that until a breach or audit failure forces the issue, they might prioritize other fires. Nonetheless, when things blow up, the CISO wears it, prepared or not.

A telling statistic Aram shared: on average, only 12% of organizations fully trust the quality of their identity data. That means nearly 9 out of 10 companies know their IAM records (e.g. who holds what role, which accounts are active) could be incomplete or outdated. This directly undermines governance. Imagine trying to certify access quarterly when you’re not even sure the user lists are right - it becomes a checkbox exercise at best. Or consider trying to enforce least privilege when your inventories of privileges are wrong. Bad data -> bad decisions.

Giao’s perspective is that fixing this requires top-down emphasis and possibly investment in identity data hygiene tools or initiatives. Some forward-leaning organizations are starting to dedicate efforts to clean up identity directories, reconcile duplicates, purge old accounts, and map entitlement catalogs more accurately. It’s not glamorous work, but it pays off at audit time.

Another disconnect is between having tools vs. using them well. Giao mentioned that some companies deploy an IGA suite, but only leverage it to meet the bare minimum compliance (e.g., they run the reports the auditor wants to see, but they don’t actively use those reports to manage risk daily). In other words, they might check the box for SOX or HIPAA by saying “we have access reviews,” but internally everyone knows those reviews are perfunctory. The ROI of governance can be hard to quantify, so businesses sometimes aim to do just enough to satisfy requirements. Giao observed that it’s rare for companies to go beyond what regulations strictly require in identity governance. Why? Because going beyond - e.g., implementing true continuous monitoring, real-time access certifications, etc., costs more and the business may not see immediate value. This is the classic compliance vs. security conundrum - doing the minimum might pass audits, but it doesn’t necessarily mean you’re secure.

Yet, relying on audits alone is risky. If a serious incident happens, the fact that you were “compliant” won’t save you from scrutiny. Many breaches have occurred in companies that had passed audits just fine, because audits often check process adherence, not real-world effectiveness. This is why CISOs increasingly push for “audit-ready” posture at all times, not just a mad rush prep once a year. Giao noted that the best outcome is when an audit is almost a non-event: if you have continuous governance, then producing evidence should be as simple as exporting a report, not a heroic data hunt.

Some organizations are reaching this point by integrating their IAM tools so that, for example, every access change is tied to a ticket or request, which is logged and easily reportable. When an auditor asks “why does Jane have access to System X?”, the answer can be retrieved in minutes: “Here’s the request from her manager, approved on this date, enforced by our system.” In many companies, answering that simple question currently could take days!

So what can CISOs do to close the tooling-governance gap? A few strategies emerged from the discussion:

• Invest in identity data integration. Ensure all those identity stores and admin consoles feed into a central inventory or IAM “source of truth.” Whether via an identity data fabric or a clever use of your SIEM/monitoring tools, you need a unified view. This also means cleaning up that data (remove duplicates, map out orphan accounts).

• Implement continuous controls. For example, some are using CIEM solutions to continuously scan cloud permissions and flag anomalies, or automated user access reviews that run monthly on a rolling basis instead of yearly all at once. This smooths out the work and catches issues sooner.

• Collaborate across teams. Giao stressed the importance of building relationships so that other departments willingly cooperate in governance efforts. For instance, ensuring HR promptly communicates employee status changes to IAM, or that app owners are engaged during access certification. When security is seen as a partner rather than an enforcer, data tends to flow more freely.

• Maximize use of existing tools. Many IAM suites have capabilities that are underutilized. It may be possible to configure your current IGA/PAM solution to automate more evidence collection or enforce policy links, without buying a new product. Sometimes it’s just a matter of turning on a feature or writing a script to connect two systems.

The bottom line is, governance has to be continuous to be effective. Point-in-time snapshots, whether an annual audit or a quarterly review, leave long windows where things can drift. And attackers only need one window of opportunity. This is why more advanced programs strive for a “live” governance model, where at any given moment you have an accurate picture of identities and their access, and any policy violations or risk indicators trigger an alert or action in real time. It’s an ideal to work toward. As Giao said, CISOs know governance is a must - the debate is mainly about how much to invest and how far to go depending on the organization’s risk profile. A tech startup might not need, or afford, the same rigor as a bank, but every company can adopt a mindset of continuous improvement in IAM governance.

 

Building continuous governance and a resilient IAM culture

If there was one overarching theme of Aram and Giao’s discussion, it was moving beyond a static, reactive IAM approach to a dynamic, continuous one. This means not just implementing one-off fixes, but establishing a culture and system of ongoing governance and monitoring. For CISOs, the goal is to reduce risk exposure in real time rather than in hindsight. So what does continuous governance actually look like?

At its heart, it’s about ensuring that every access change, every policy exemption, every new entitlement gets evaluated and logged when it happens. And that the organization maintains a steady state of compliance without the big spikes of effort. In practical terms:

• Real-time access change logging. Whenever a user is granted or removed from a role, group, or permission, that event is recorded with metadata - who approved it, ticket number, etc. Nothing slips through unnoticed.

• Policy ties and triggers. Each decision is tied back to a policy. For example, “Devin’s access was removed after 90 days of inactivity per policy ABC.” This makes audits trivial because you can show the policy and the enforcement evidence side by side.

• Automated remediation. If a violation occurs, say a user somehow accumulates an SOD conflict or an account goes stale, the system flags it and potentially fixes it - e.g., by removing the excess access or at least alerting the responsible manager immediately, not next quarter.

• Continuous monitoring. This extends to watching user activity patterns for anomalies, as well as scanning configurations for drift from baseline. It’s akin to the difference between a burglar alarm (real-time alert) vs. an annual door lock inspection (point-in-time).

All this requires tight integration and possibly an “orchestration” layer over your IAM components. Some call this an identity fabric, which Gartner defines as a blend of modular IAM capabilities stitched together. The orchestration is what weaves those pieces into a cohesive whole. Increasingly, vendors and open-source projects are providing identity orchestration frameworks that can help here.

From a people standpoint, continuous governance demands collaboration. A CISO can champion it, but success means making it a shared responsibility across IT, security, HR, and app owners. One positive sign is that auditors themselves are evolving - many now favor a cooperative approach of finding and closing gaps, since everyone knows no environment is perfect. Giao mentioned that unless an auditor is extremely strict, they will often work with you to remediate issues rather than immediately drop the hammer. So having an internal culture of “let’s fix this together” goes a long way. Teams should feel comfortable reporting a potential issue proactively, rather than hiding it until it’s discovered by audit.

To gauge where you stand, Aram asked Giao how often he actually sees companies reach a mature state of auditability and logging. Giao’s answer: it varies widely, and often correlates with industry and regulation. Highly regulated sectors such as finance and healthcare tend to be further along because they’ve been forced to by compliance. They may have continuous control systems to meet year-round regulator scrutiny. In contrast, a tech startup might be at a basic level of maturity and only perform ad-hoc checks. The key is to align your efforts with your risk environment - if you handle sensitive data or critical infrastructure, you need to invest more in continuous governance. If not, you still should improve over time, but the urgency is relative.

For any CISO looking to champion this evolution, a smart approach is incremental wins. Giao recommended not trying to boil the ocean at once. Identify one or two high-risk areas or “easy wins” and start there. For example, maybe you have an epidemic of orphaned SaaS accounts - start by implementing a process to regularly clean those up. Perhaps via an integration that pulls last login info and auto-deactivates stale accounts, with notifications to owners. Or if developers have broad admin rights in production, maybe tackle that with a just-in-time privilege solution for that particular use case. Each win will build confidence and reduce risk, which can then justify further investment.

Finally, improving IAM is a journey, not a destination. It requires continuous feedback loops. This is where a lot of organizations bring in metrics and KPIs for their IAM program - e.g., track the number of privileged accounts, track how long deprovisioning takes after terminations, track how many policy violations are found and fixed each month. If those metrics trend in the right direction, you know you’re building a healthier system. If not, you adjust course. The CISO should regularly brief the rest of the C-suite on these metrics, translating them into business risk terms: “We reduced dormant accounts by 80%, which directly lowers our likelihood of an insider incident”. This keeps everyone aligned that IAM governance isn’t just a cost center but a business enabler: fewer incidents, smoother audits, and even efficiencies like removing unused SaaS licenses.

 

TL;DR:

In summary, the conversation between Aram Andreasyan and Giao Nguyen painted a vivid picture of the realities IAM leaders face in 2026:

• Breach accountability is personal. CISOs must treat IAM failures as existential threats to their career, and act accordingly by shoring up identity controls.

• IAM programs struggle due to underfunding and silos. Success requires executive support, cultural change, and breaking down data/tooling fragmentation.

• New identity threats are emerging. From deepfake job applicants to nation-state imposters, the onboarding process needs security reinforcement.

• Old threats still lurk. Privilege creep and unmonitored accounts are causing “low-hanging fruit” breaches. Fundamental housekeeping can’t be ignored.

• Zero Trust is a journey. Adaptive, context-aware IAM is the future, but it takes time to implement and requires aligning people and tech to new models.

• Tools ≠ maturity. Having IAM products isn’t enough; you need good data and continuous processes. Aim for continuous governance so you’re always audit-ready and risk-aware.

• CISOs can lead the change. By collaborating across the org and focusing on incremental improvements, security leaders can steadily close gaps and reduce exposure.

Ultimately, building a robust IAM program is about enabling the business safely. It’s not just security for security’s sake. When done right, IAM improvements remove obstacles (e.g. automated onboarding gets people access faster) and protect what matters (ensuring only the right folks get to the right data at the right time). As Giao noted, a mature IAM setup even allows IT to become an enabler rather than a constant gatekeeper, because many controls are automated and reliable, IT can spend more time on strategic work and less on firefighting access issues.

For CISOs and compliance heads reading this, the takeaway is: invest in identity, invest in governance, and do it continuously. The threats will keep evolving, but a strong IAM foundation - adaptive, well-monitored, and backed by executive commitment - is one of the best defenses you can build. And remember, you’re not alone in this. Lean on expert communities, learn from peers - many CISOs are more than willing to share war stories and solutions, and don’t hesitate to bring in outside help for assessments or operations if needed. The stakes warrant it.

 

A quick word on Cerbos and enterprise authorization

One recurring theme in modern IAM is the move toward dynamic, policy-based access controls - exactly the space that Cerbos focuses on. Cerbos is an authorization platform for enterprise software and AI, that externalizes access policies from application code, making it easier to implement contextual, just-in-time permissions in your services.

Instead of hardcoding who can do what, teams define human-readable policies (e.g., “managers can approve expenses up to $5,000” or “analytics service accounts can read data only from their assigned project”) and Cerbos evaluates these at runtime. This kind of attribute based access control approach is key for adaptive IAM, because it lets you enforce fine-grained rules that take into account user roles, risk scores, resource types, and more - all without changing your application logic.

By adopting a solution like Cerbos, organizations can more easily implement zero trust principles in their software: every access request is evaluated against policy, with context, every time. It also greatly aids in auditing and governance. Since policies are centralized and decisions are logged, you gain a clear trail of why access was granted or denied, and you can update rules in one place to affect all apps consistently. Cerbos is built to be developer-friendly and scalable, so it can fit into modern cloud-native stacks and support high-throughput authorization checks.

If you’re looking to strengthen your dynamic authorization capabilities as part of the journey to continuous IAM governance, check out Cerbos - it might just be the accelerator your team needs to move from theory to practice in policy-driven access control.