DEV Community: Applied IAM

RBAC vs ABAC vs PBAC: Which Access Control Model Should You Actually Use?

Applied IAM — Mon, 27 Jul 2026 00:00:00 +0000

Most organizations settle the role-based versus attribute-based question early, usually in favor of roles, and then spend the next several years quietly working around the decision. Policy-based access control has entered the conversation because that workaround period has become expensive.

The three models are often presented as a progression — RBAC is old, ABAC is better, PBAC is newest — which is misleading. They answer different questions, and most mature programs run more than one at the same time.

RBAC: access by job function

Role-based access control grants permissions to roles, and roles to people. A claims adjuster gets the claims adjuster role. When someone changes jobs, you swap the role.

It works because it matches how organizations actually describe themselves. Auditors understand it. Managers can review it. It is straightforward to certify, which is why it remains the backbone of most identity governance programs.

Where it breaks is scale and nuance. Every exception becomes a new role. A claims adjuster in California who handles commercial policies and needs temporary access during quarter-end is not the same as a claims adjuster in general — so you create a role for it. Repeat that a few hundred times and you have role explosion: more roles than people, nobody sure which ones are still needed, and a certification campaign that nobody can meaningfully review.

ABAC: access by attributes and context

Attribute-based access control evaluates characteristics instead of memberships. Department, location, clearance level, device posture, time of day, data classification. Access is granted when the attributes line up.

This handles the nuance RBAC cannot. Rather than a role for California commercial claims adjusters, you write a rule: users in the claims department, in the commercial line, in the California region, can access matching records.

The trade-off is that ABAC is only as good as your attribute data. If HR records are stale, if department codes are inconsistent between systems, if nobody owns data classification, the model produces confident and wrong decisions. ABAC failures are also harder to explain to an auditor: "why does this person have access" becomes an evaluation you have to reconstruct, not a membership you can point at.

Getting attribute quality right is the same discipline as access certification — if nobody owns the underlying data, neither model can be trusted.

PBAC: access as a governed policy layer

Policy-based access control is less a third alternative than a shift in where the decision lives. Instead of embedding logic in roles or in application code, PBAC centralizes it into policies that are written, versioned, tested and enforced consistently across systems.

A PBAC policy can reference roles and attributes — that is the point. What changes is that the rule exists in one governed place rather than being reimplemented in every application by whoever built it.

The driver is environmental. Access decisions now have to be consistent across SaaS, cloud infrastructure, internal apps and increasingly machine and AI workloads. Encoding the same intent separately in a dozen systems guarantees drift. PBAC exists because that drift became the risk.

Its cost is real: it needs policy authorship as a discipline, an enforcement layer that every system can consult, and someone who owns the policy set. Organizations that adopt it without those things end up with a policy engine nobody maintains.

How the three compare

	RBAC	ABAC	PBAC
Decision basis	Role membership	Attribute evaluation	Centrally governed policy
Strongest at	Auditability and review	Context and fine-grained control	Consistency across many systems
Fails when	Exceptions multiply into role explosion	Attribute data is stale or unowned	No one owns policy authorship
Review difficulty	Low — memberships are visible	High — decisions must be reconstructed	Moderate — policies are readable but need expertise
Typical fit	Most organizations, as the base layer	Sensitive data, regulated context, fine-grained needs	Multi-cloud and multi-app estates needing consistency

What good actually looks like

In practice the strongest programs we work on are layered rather than pure:

RBAC as the base. Broad, stable, coarse-grained access assigned by job function. This is what gets certified during access reviews, because it is the layer humans can genuinely review.
ABAC for the edges. Context-sensitive conditions applied on top — region, data classification, device posture — rather than spawning another hundred roles.
PBAC when consistency becomes the constraint. Once the same access intent has to hold across cloud, SaaS and internal systems, centralizing it stops being architectural preference and starts being risk management.

The failure mode we see most often is not picking the wrong model. It is picking one and treating it as complete: pure RBAC that has quietly become a thousand roles, or an ABAC rollout that stalled because nobody would own the attribute data.

Choosing where to start

Three questions get most organizations to an answer.

Can you explain your current access to an auditor without building a spreadsheet? If not, the problem is not your model — it is visibility, and RBAC hygiene comes first.

Are your exceptions growing faster than your headcount? Role explosion is the signal that you need attributes or policy, not more roles.

Does the same access rule exist in more than three places? That is the practical threshold where policy-based control starts paying for itself.

One area worth checking separately: these models were designed around human users, and most environments now contain far more service accounts and machine identities than people. Whichever model you choose, it will need to answer for those too — and most implementations quietly exclude them.

If you are working out which layer to fix first, that is the kind of question our free identity audit is built to answer.

User Access Reviews: Why Access Certification Fails and How to Fix It

Applied IAM — Mon, 27 Jul 2026 00:00:00 +0000

There is a familiar moment in most access certification campaigns. A manager receives 400 entitlements to review, recognizes perhaps thirty of them, and approves everything in under fifteen minutes. The campaign completes. The evidence goes to the auditor. Nothing about the organization's actual access risk has changed.

The control was performed. It was not exercised. And because the evidence looks identical either way, this can continue for years before anyone notices.

What an access certification is supposed to do

A user access review asks a specific question: does this person still need this access, and can someone who understands the work confirm it?

That framing matters, because it identifies the two ways reviews fail. Either the reviewer does not understand what they are approving, or the review does not result in anything being removed. Both produce clean paperwork.

The regulatory pressure is real — SOX, PCI DSS, HIPAA and most cyber-insurance questionnaires all expect periodic access certification. But the reason to do it properly is more practical. Access accumulates. People change roles and keep what they had. Projects end and their access does not. Without periodic removal, entitlements only ever grow.

The four things that make reviews work

Reviewers who recognize what they are looking at. This is the single biggest determinant. "Reviewer" defaults to line manager, but a line manager often cannot assess application entitlements. Application owners usually can. Splitting campaigns by who genuinely has context — managers for coarse business roles, application owners for technical entitlements — changes outcomes more than any tooling decision.

Entitlements described in business language. A reviewer presented with FIN_GL_JE_POST_02 will approve it. Presented with "post journal entries to the general ledger", they may not. Translating technical entitlements into plain descriptions is unglamorous work and it is most of the value.

Scope small enough to be real. A campaign covering every entitlement in the estate guarantees rubber-stamping. Risk-based scoping — privileged access, segregation-of-duties conflicts, sensitive data, anything changed since last review — produces smaller campaigns that reviewers actually complete.

Revocation that happens automatically. If a reviewer clicks "revoke" and that generates a ticket someone processes later, a meaningful share never gets processed. The loop has to close in the platform. Reviews that do not remove access are theater.

How the IGA platforms handle certification

Certification is the core of identity governance, and it is where these platforms genuinely differ. We implement across all of them.

Platform	Certification approach	Best suited to
SailPoint	The most mature campaign engine — risk-based scoping, delegation, role mining, extensive audit evidence	Large enterprises with complex application landscapes and heavy audit load
Saviynt	Cloud-native governance with analytics-driven review and converged application access governance	Cloud-first organizations modernizing governance without an on-premises footprint
Microsoft Entra ID Governance	Access reviews for Entra groups, roles and applications, often already licensed	Microsoft-centric estates proving the control before wider investment
Okta Identity Governance	Review workflows tied closely to Okta's access management and app catalog	Organizations already standardized on Okta for workforce access

The pattern here mirrors privileged access: the strongest platform is the one that matches your estate and your capacity to run it. A tier-one governance platform that nobody operates produces worse outcomes than a modest one that runs every quarter.

Running your first campaign

If you are starting from spreadsheets, resist the urge to certify everything.

Pick one high-risk scope. Privileged accounts, or access to one regulated application. Something where removal is obviously valuable.
Identify the right reviewers before the tooling. If you cannot name who understands each entitlement, the campaign will not work regardless of platform.
Translate the entitlements. Plain-language descriptions for everything in scope. This is the work that determines whether reviewers engage.
Close the revocation loop. Confirm that a revoke decision actually removes access, end to end, before the campaign runs.
Measure the revocation rate. A campaign that removes nothing is not a pass — it is a signal that reviewers are not engaging. A healthy first campaign in an environment that has never certified typically removes a meaningful share of what it reviews.

That last metric is the honest test. Auditors increasingly ask not just whether reviews happened, but what changed as a result.

Where this connects

Access certification does not stand alone. It depends on knowing what entitlements exist and what they mean, which is why it usually surfaces gaps in joiner-mover-leaver automation and role design at the same time. Sectors with layered external access — financial services with vendor and broker access, healthcare with clinical rotations and locums — tend to feel this first, because their access changes faster than annual review cycles can track.

It also has the same blind spot as most identity controls: certification campaigns are built around people, and service accounts rarely have an owner willing to attest to them. In most environments they are the largest population of uncertified access.

If your reviews are running but nothing is being removed, that is a diagnosable problem. It is the kind of thing our identity governance work starts by measuring, and what a free identity audit is built to surface.

What to Look for in an IAM Implementation Partner

Applied IAM — Fri, 24 Jul 2026 00:00:00 +0000

The Choice That Matters More Than the Platform

Organizations spend months evaluating identity platforms — CyberArk versus the field, SailPoint versus Saviynt, which PAM tool has which feature. That scrutiny is reasonable. But the platform decision is often less consequential than a second one that gets far less attention: who actually implements it.

A capable platform deployed badly delivers less than a modest platform deployed well. Most identity programs that stall don't stall because the software was wrong — they stall because the implementation was under-scoped, half-finished, or handed over without the operational plumbing to keep it running. Choosing the right partner is how you avoid that.

Here's what actually separates a good IAM implementation partner from a risky one.

Specialists, Not Generalists

Identity security is deep and unforgiving. The difference between a tool that's merely installed and one that genuinely protects you lives in the details — vault structure, session policy, role design, the order operations happen in. A generalist IT services firm that does identity as one line item among many rarely has that depth.

Look for a partner whose center of gravity is identity and access management specifically. Certifications on the platforms they deliver are a baseline signal — a CyberArk Certified Delivery Engineer, for instance, has demonstrated real competence rather than a sales relationship. Ask how many implementations they've actually delivered on the platform you're buying, and in environments like yours.

Delivery Experience, Not Just Licensing

There's a meaningful difference between a partner who can sell you a platform and one who can deploy it. Plenty of resellers can get you a license. Far fewer can architect the deployment, integrate it with your directory, SIEM, and ITSM, discover and onboard the accounts nobody documented, and get it to a state your team can actually run.

When you're evaluating a partner, push past the sales conversation into the delivery conversation. How do they scope discovery? How do they phase a rollout? What does handover look like? A partner who leads with licensing and gets vague about delivery is telling you where their real capability ends.

A Plan for Day Two

This is the single most common failure point, and it's worth weighting heavily. A deployment isn't finished when the software is installed. It's finished when your team can operate it — when there are runbooks, when responsibilities are owned, when the platform is a managed system rather than one engineer's side project.

Ask any prospective partner directly: what happens after go-live? A good answer includes documentation, knowledge transfer, and either a clean handover to your team or a managed-service option to run it for you. A partner with no day-two story is likely to leave you with a deployment that quietly drifts and decays.

Regulated-Industry Fluency (If That's You)

If you operate under compliance obligations — PCI-DSS, SOX, HIPAA, NYDFS, FERPA, NIST — your implementation needs to be built against those frameworks from the start, not retrofitted. Evidence collection should be baked into the rollout so audit questions get answered from the platform rather than reconstructed from spreadsheets later.

A partner who has delivered in regulated environments will talk fluently about mapping controls to the frameworks you report against. One who hasn't will treat compliance as your problem to sort out afterward.

Honest Platform Advice

Be wary of a partner who recommends the same platform to everyone, or who only delivers the one product they resell. The right platform depends on your environment, your risk, and your team — and a partner worth hiring will tell you when a cheaper or simpler option fits you better, even if it earns them less.

The tell is whether they start from your risk or from their product. A partner who assesses your actual exposure before recommending anything is giving you advice. A partner who leads with a product is giving you a pitch.

The Cost Question

"How much does it cost to work with an IAM implementation partner?" is a fair question, and the honest answer is that it depends — on scope, on how many accounts and systems are in play, on whether you want a clean handover or ongoing managed operations. Any partner who quotes a firm number before understanding your environment is guessing.

What's more useful early on is a scoping conversation that turns the vague question into a real one: what needs doing, in what order, and what the highest-risk gaps are that justify moving first.

Where We Fit

Applied IAM is a boutique identity security consultancy — specialists rather than generalists, certified on the platforms we deliver, and structured around finishing the job through to day-two operations. We deliver across CyberArk, Keeper, and the wider identity stack, and we recommend based on your environment rather than a quota.

If you're weighing a program and want an objective read on where to start, a free identity security audit or a direct conversation is the fastest way to turn the question into a plan.

IAM vs IGA: The Difference That Shows Up at Audit Time

Applied IAM — Fri, 24 Jul 2026 00:00:00 +0000

Two Terms, Constantly Confused

Few pairs of terms in identity security get blurred as often as IAM and IGA. They sound similar, they overlap, and plenty of people use them interchangeably. But they answer two genuinely different questions, and treating them as the same thing tends to create a gap you only discover at audit time.

Here's the cleanest way to tell them apart.

IAM Answers "Can This Person Get In?"

Identity and access management (IAM) is about access itself. It verifies that someone is who they claim to be, and it grants them the right level of access at the moment they log in. Single sign-on, multi-factor authentication, directory management, and session policies all live here.

When IAM is working, the right people get into the right applications without friction, and the wrong people don't get in at all. It's the runtime engine of identity — the muscle that enforces access in real time. Its goal is secure access with as little friction as possible.

IGA Answers "Should This Person Have This Access?"

Identity governance and administration (IGA) sits on top of IAM and adds a governance layer. It's less concerned with the moment of login and more concerned with whether the access someone holds is appropriate — and whether you can prove it.

IGA manages the full identity lifecycle: onboarding, role changes, and offboarding. It runs access certifications, where owners periodically review and confirm who should still have what. It enforces policy like segregation of duties, so that one person can't, say, both approve and process a payment. And it produces the evidence trail that lets you answer an auditor's questions from a report instead of a scramble.

If IAM is the muscle, IGA is the brain — the layer that defines what access should exist and continuously checks that reality still matches.

Where the Gap Bites

Here's the scenario that makes the difference concrete, and it's extremely common.

You rolled out SSO across the company. You turned on MFA. You integrated your identity provider with most of your SaaS apps. On the IAM side, you're in good shape. Then an auditor asks a simple question: who has access to what, and is that access appropriate?

And suddenly you're pulling four spreadsheets and chasing three managers who haven't reviewed access in months. That gap — between "we control access" and "we can prove access is appropriate" — is exactly the gap between IAM and IGA.

Strong authentication doesn't tell you whether a finance analyst who moved to marketing still has access to the general ledger. It doesn't flag the contractor whose account was never deactivated, or the accumulated permissions someone picked up over five years of role changes. That's overprovisioning and orphaned access, and it's risk you're carrying without seeing it. IAM won't catch it. Governance will.

They're Layers, Not Rivals

The important thing is that this isn't a choice between IAM and IGA. IGA doesn't replace IAM — it depends on it. Without the authentication and authorization that IAM provides, there's nothing for governance to govern. And without governance on top, IAM quietly drifts out of alignment with your policies and compliance obligations over time.

A mature identity program needs both: IAM to enforce access in real time, and IGA to validate that access against least privilege and regulatory requirements on an ongoing basis. One reduces friction; the other reduces risk. Run together, they're what lets you both operate smoothly and answer for it when someone asks.

Where to Start

Most organizations we work with have more IAM maturity than IGA maturity — solid SSO and MFA, weaker governance. That's usually where the audit findings cluster: access reviews that don't happen, deprovisioning that lags, entitlements nobody can explain.

If that sounds like your environment, our identity governance work is built around closing exactly that gap — turning "we think access is fine" into "we can prove it." A free identity security audit is a straightforward way to see where your gaps actually are before committing to anything.

Definitions informed by current industry references on IAM and IGA.

How Hard Is It to Actually Roll Out CyberArk Across a Distributed Workforce?

Applied IAM — Fri, 24 Jul 2026 00:00:00 +0000

A Fair Question With an Honest Answer

Teams evaluating CyberArk often ask a very practical version of the question: how easy is it, really, to roll this out across a large, distributed workforce — multiple sites, remote admins, third parties, thousands of accounts?

The honest answer is that it's very doable, but not in a single sweep. The rollouts that go badly almost always share one root cause: someone tried to deploy everything, everywhere, at once. The rollouts that go well phase the work by risk. Here's what that actually looks like.

Why "All at Once" Fails

A distributed workforce multiplies every variable. Different sites have different systems. Remote administrators connect over different networks. Third-party contractors need scoped, temporary access. Service accounts are scattered across environments, and many were never documented in the first place.

Trying to onboard all of that in one phase means the project's complexity peaks before anyone has seen a working result. Momentum stalls, stakeholders lose confidence, and the deployment becomes the thing everyone avoids touching. This isn't a CyberArk-specific failure — it's what happens to any large controls rollout attempted big-bang.

The fix is to make risk, not org-chart completeness, decide the order.

Phase by Risk, Not by Population

A rollout that works usually moves in waves:

Wave one: the highest-risk accounts. Domain administrators, infrastructure root credentials, and the handful of accounts that could do the most damage if compromised. This is a small population with an outsized risk profile, so vaulting these first drops your real exposure in the first few weeks rather than at the end of a year-long program. It also produces a visible early win.

Wave two: application and service accounts. The credentials that software uses to talk to other software — often undocumented, often over-privileged, and a common path for lateral movement. Discovery is the hard part here, because you're finding accounts nobody wrote down.

Wave three: broader privileged access and endpoint privilege. Local admin rights, wider administrative populations, and the longer tail of privileged users across sites.

At each wave, the population is small enough to manage and the risk reduction is immediate. You're never staking the whole program on one enormous cutover.

The Distributed-Specific Parts

For a spread-out workforce, two things matter more than they would in a single-site deployment.

Remote and third-party access should run through brokered sessions , not VPN-plus-shared-credentials. When an external administrator connects, the session is mediated, isolated, and recorded — so access is attributable to a named person and revocable the instant it's no longer needed. This is usually what makes distributed rollouts workable rather than chaotic.

Discovery is a project in its own right. Before you can secure privileged and service accounts, you have to find them, and in a distributed environment they hide in places nobody's looked in years. Budgeting time for discovery up front prevents the most common mid-rollout surprise.

Where Rollouts Actually Stall

When we get called into a CyberArk deployment that's stuck, it's rarely the product. It's almost always one of three operational gaps:

Onboarding stopped after the first easy wave, because nobody owned the discovery of the remaining accounts.
Session management was deployed but never enforced, so administrators kept a bypass route.
No runbooks were handed over, so the platform quietly became one engineer's side project instead of an operated system.

Each of these is fixable without starting over. But each is an operations problem, not a technology problem — which is why "how hard is the rollout" is really a question about how well the program is structured, not about the software.

The Short Version

Rolling out CyberArk across a distributed workforce is very achievable. It fails when it's attempted all at once and succeeds when it's phased by risk — highest-danger accounts first, discovery treated as real work, remote access brokered rather than trusted, and day-two operations handed over properly.

That phased, operations-first approach is exactly how our CyberArk implementation engagements are structured. If you've got a deployment that's stalled — or one you haven't started — a conversation about where you are is the fastest way to find the next move.

CyberArk vs Okta: Why You Probably Need Both, Not Either

Applied IAM — Fri, 24 Jul 2026 00:00:00 +0000

The Question That Comes Up in Every Evaluation

"For privileged access management, is Okta or CyberArk the better choice?" We hear some version of this constantly — from CISOs, IT directors, and security architects who are mid-evaluation and trying to narrow a shortlist.

It's a reasonable question. It's also, most of the time, the wrong one. CyberArk and Okta get shelved next to each other in comparison charts as if they're interchangeable, but they were built to solve different problems. Choosing between them often means choosing to leave one of those problems unsolved.

Here's the distinction that clears most of the confusion up.

Different Tools for Different Jobs

Okta is an identity and access management (IAM) platform. Its job is the front door: verifying that someone is who they claim to be, then getting them into the applications they're allowed to use. Single sign-on, multi-factor authentication, and user provisioning across your SaaS stack are its center of gravity. When Okta is working well, the right people reach the right apps without friction.

CyberArk is a privileged access management (PAM) platform. Its job is much narrower and much deeper: securing the small number of accounts that can change systems, reach sensitive data, or switch off security controls. Vaulting those credentials, isolating and recording privileged sessions, and rotating passwords automatically are what it does. When CyberArk is working well, an attacker who gets a foothold still can't reach the accounts that would let them do real damage.

One industry way of putting it: IAM is the muscle that enforces access, and identity governance is the brain that decides what access should exist. PAM is a third thing again — the reinforced vault around your most dangerous keys. Okta secures the broad identity layer for your whole workforce. CyberArk secures the narrow, high-risk privileged layer underneath it.

They're not substitutes. They're layers.

Why "Just Pick One" Creates a Gap

Say you standardize on Okta alone. Your workforce gets clean SSO and MFA — genuinely valuable, and a real security improvement. But your domain administrators, your service accounts, your infrastructure root credentials, and the access keys that quietly run your automation are still sitting there. Okta can authenticate the human who logs in, but it isn't built to vault a service account's credential, broker an admin session so it's recorded, or rotate a database password every time it's used. That's the privileged layer, and it's exactly where serious breaches escalate.

Now say you standardize on CyberArk alone. Your most dangerous credentials are locked down properly. But you've still got thousands of ordinary employees who need smooth, secure access to hundreds of everyday applications — and CyberArk was never designed to be your day-to-day SSO and provisioning engine for the whole workforce.

Each tool, used alone, leaves the other's problem open. That's why running both is common rather than redundant. In practice they integrate cleanly: Okta authenticates a user into a privileged workflow, and CyberArk then controls and records what happens inside it.

One 2026 Wrinkle Worth Knowing

There's a development that sometimes muddies these conversations. As of February 2026, CyberArk is a Palo Alto Networks company, following a roughly $25 billion acquisition. It's a significant shift for the vendor landscape.

For the practical comparison, though, not much changes. CyberArk remains the privileged access leader, and its vaulting, session isolation, and credential controls work the way they always have. Okta remains the broad identity and access platform. The acquisition changes who owns CyberArk — not what job it does in your environment.

How to Actually Decide

The honest answer to "Okta or CyberArk" is usually "both, for different reasons" — but the more useful question is what are you trying to fix first?

If your immediate gap is workforce access — too many passwords, inconsistent MFA, slow onboarding and offboarding — that's an IAM problem, and an identity platform is where you start.

If your immediate gap is privileged access — admin accounts nobody's tracking, service accounts nobody documented, audit findings about who can touch critical systems — that's a PAM problem, and that's where privileged access management earns its place first.

Most enterprises end up needing both. The question is sequencing, not brand loyalty, and the right order depends on where your actual risk and audit exposure sit today.

That's the assessment we help teams work through — mapping your real exposure before anyone spends money on a platform. If you're weighing where to start, our CyberArk implementation practice and a free identity security audit are both good places to begin the conversation.

Comparison context drawn from industry analysis of the CyberArk and Okta platforms.

WP-SHELLSTORM: What an Exposed Hacker Server Teaches Us About Credential Theft at Scale

Applied IAM — Fri, 10 Jul 2026 00:00:00 +0000

A Careless Operator, A Very Revealing Server

Sometimes the most instructive security incidents are the ones where attackers expose themselves. According to reporting by The Hacker News, a cybercrime crew left one of its own servers publicly accessible — no password, no access controls — for approximately three weeks. Two independent research teams, SOCRadar and Ctrl-Alt-Intel, discovered the open directory and found roughly 800MB of operational material inside: exploit scripts, webshells, scan logs, and a detailed command history.

The operation, tracked as WP-SHELLSTORM, reportedly functioned as a webshell access brokerage — breaking into websites at scale, planting hidden backdoors, and packaging that access for resale. The primary targets were WordPress sites running outdated plugins, though Joomla installations also appeared prominently in the crew's target lists.

The scale sounds alarming at first: more than 1.4 million domains reportedly appeared across the crew's target files. But researchers were careful to distinguish between sites that were scanned and sites that were actually compromised. Ctrl-Alt-Intel's deduplicated count found roughly 25,000 sites with confirmed compromise evidence; SOCRadar put active webshells at just over 5,700. Being on an attacker's scan list is meaningfully different from being breached.

The Credential Harvest Nobody Led With

The WordPress backdooring drew the headlines, but the earlier phase of this operation is arguably more relevant to enterprise security teams.

According to SOCRadar's findings, before the noisy, high-volume WordPress campaign, the same crew conducted a quieter operation in early May 2026 against corporate Java systems. Reportedly, they pulled configuration files from systems across companies in fintech, e-commerce, logistics, gaming, and electronics. What came out of those systems is the part worth dwelling on:

Cloud access keys for AWS, Alibaba Cloud, Oracle, Tencent, and DigitalOcean
Database passwords stored in configuration files
RSA private keys for payment services

The entry point, reportedly, was CVE-2021-29441, an old and well-documented flaw in Nacos, a configuration management server. The vulnerability allows an attacker to bypass authentication entirely by manipulating a single web request header. It was patched years ago, and yet it reportedly delivered 613 configuration files from 11 systems.

SOCRadar's analysis described the sequencing as deliberate: harvest high-value corporate credentials first, then scale into the higher-volume backdoor work. Whether or not that interpretation is correct, the pattern is a familiar one in incident response — configuration files and secrets stores are frequently underestimated as targets , and their exposure often goes undetected far longer than endpoint or identity provider compromises.

What Identity and Access Teams Should Take Away

Several practical lessons emerge from the WP-SHELLSTORM operation that apply well beyond WordPress administrators.

Exposed secrets in configuration files are a critical risk surface. Cloud keys, database credentials, and private keys stored in application configuration files represent a class of secret that many organizations do not rotate on any regular cycle, and often do not monitor for misuse. If a Nacos instance — or any configuration server — was ever internet-accessible or ran an unpatched version, every credential that passed through it should be considered potentially compromised and rotated accordingly. This is precisely the use case that secrets management tooling is designed to address: keeping credentials out of flat configuration files in the first place, and enforcing rotation policies that limit the window of exposure.

Patch velocity matters, even for "old" CVEs. CVE-2021-29441 is a five-year-old vulnerability. Its continued usefulness to attackers in 2026 reflects an enduring gap between disclosure and remediation across many organizations, particularly for infrastructure components that are less visible than front-end applications.

Access granted through a webshell is functionally privileged access. Once a webshell is running on a server, the attacker can read files, execute commands, and move laterally — capabilities that closely mirror what a privileged administrator account would provide. Detecting unexpected processes, unusual file patterns, or anomalous network connections from web servers should be part of any organization's ongoing monitoring posture, not just a post-incident exercise.

Unpatched plugin ecosystems are an access-brokerage supply chain. The fact that a crew can build a sustainable business around automated exploitation of known, public CVEs in popular plugins — then resell that access — means the downstream risk extends beyond the compromised site itself. If a web server contains application credentials, session tokens, or API keys (and most production servers do), a webshell on that server is a credential-theft event, not merely a website defacement.

Reporting: Source

The Rogue Agent Vulnerability: What AI Platform Flaws Mean for Identity and Data Security

Applied IAM — Wed, 08 Jul 2026 00:00:00 +0000

What Happened

Researchers at Varonis reported a vulnerability in Google Cloud's Dialogflow CX service — an enterprise conversational AI platform used to build virtual agents for customer support, healthcare, financial services, and other sensitive workflows. The flaw, which Varonis named "Rogue Agent," was reported to Google Cloud in November 2025. An initial patch arrived in April, with a full fix deployed in June.

According to Varonis, the vulnerability stemmed from how Dialogflow CX handles "Code Blocks" — a feature that embeds custom Python logic into conversation flows. All agents within the same Google Cloud project that use Code Blocks reportedly share a common Cloud Run execution environment managed by Google. Within that environment, researchers found it was possible to overwrite a key file responsible for executing Python code, effectively injecting malicious logic that persisted across user sessions.

Critically, Varonis noted that these modifications reportedly did not appear in logs, making the activity invisible to defenders.

The Access Control Problem at the Core

Stripped of the AI-specific context, this is a recognizable identity and access management problem: an overly permissive execution environment, insufficient isolation between tenants, and a writable system file that should not have been writable.

A few elements stand out from an IAM perspective:

Shared execution environments amplify blast radius. Because all agents in the same Google Cloud project reportedly shared the same Cloud Run instance, a single compromised or misconfigured agent could affect every other agent in that project. This is the cloud equivalent of lateral movement — one weak point becomes a platform-wide exposure.
Permission to configure Code Blocks was the entry condition. According to Varonis, the attack path required that Code Block configuration permissions be enabled. That is a meaningful reminder that feature-level permissions — not just resource-level access — carry real risk and deserve the same scrutiny as administrative roles.
Service account tokens were reachable. Varonis also found that the Instance Metadata Service within the Cloud Run environment could reportedly be queried to retrieve access tokens for a Google-managed service account. In cloud environments, metadata services are a well-known lateral movement vector; this finding underscores that AI workloads are not exempt from that threat model.

What This Means for Organizations Using AI Platforms

Enterprise AI platforms are increasingly processing sensitive data — customer conversations, financial queries, healthcare intake workflows. The Dialogflow CX case is a reminder that these platforms inherit the same access-control disciplines that apply to any other privileged system.

Practical considerations for security and IT teams:

Audit who holds feature-level permissions in AI platforms. The ability to configure Code Blocks, connect to external APIs, or modify agent logic should be treated as a privileged capability. Apply least-privilege principles and review those permissions with the same rigor as cloud IAM roles.
Treat AI workload identities as privileged identities. Service accounts used by AI platforms — and the tokens they can generate — should be inventoried, scoped narrowly, and monitored. Unrestricted outbound network access from an AI execution environment is a significant risk surface.
Verify logging coverage for AI platform activity. The reported absence of log entries for file modifications in this case is a stark illustration of a detection gap. Before assuming your AI platform activity is auditable, confirm what is and isn't captured.
Apply your cloud security posture standards to AI services. VPC Service Controls, workload isolation, and network egress restrictions are controls that exist precisely to contain this kind of lateral movement. Varonis noted that the vulnerability could reportedly bypass VPC Service Controls — reinforcing that those controls need to be correctly configured and regularly validated, not assumed to be working.

The Broader Pattern

As organizations embed AI into customer-facing and internal workflows, the attack surface for identity and access abuse grows accordingly. The Rogue Agent vulnerability is notable not because AI platforms are inherently insecure, but because they are being adopted quickly, often by teams whose primary focus is functionality rather than security architecture.

The identity discipline that applies to databases, APIs, and cloud infrastructure applies equally here: know who — and what — has access, enforce least privilege, ensure auditability, and isolate workloads appropriately. AI agents that process sensitive conversations are, from a security standpoint, privileged systems and should be governed as such.

Reporting: Source

81 Million Password Spray Attempts Against Azure CLI: What the MFA Gaps Tell Us

Applied IAM — Wed, 01 Jul 2026 00:00:00 +0000

What Happened

Cybersecurity firm Huntress recently reported a large-scale password spray campaign targeting Microsoft 365 environments through the Azure CLI. According to the report covered by SecurityWeek, researchers observed more than 81 million login attempts against their customers between June 12 and 21. By the end of that window, 78 user accounts across 64 organizations had reportedly been compromised — at a rate of two to four accounts per day, with a notable spike around June 22 when 23 businesses were affected in a single day.

Huntress attributed the bulk of the activity to an autonomous system linked to internet hosting provider LSHIY LLC. The firm said it reported the malicious behavior through LSHIY's abuse mechanism but received no reply. Notably, Huntress also observed that credential spray attack volume across its customer base had grown by more than 155 times over the prior six months — a stark indicator that this style of attack is accelerating, not fading.

The OAuth ROPC Blind Spot

What makes this campaign particularly instructive is how attackers reportedly bypassed multi-factor authentication. The method at the center of the campaign was the OAuth Resource Owner Password Credentials (ROPC) flow — a legacy authentication method that was deprecated in OAuth 2.1 precisely because it lacks support for modern security controls like MFA and single sign-on.

In practical terms, ROPC passes credentials directly to a token endpoint without triggering an interactive MFA prompt. That means an attacker armed with a valid username and password can obtain an authentication token without the user ever being asked to approve a second factor — even if MFA has been deployed.

The attacks were reportedly fueled by compromised password combo lists, underscoring the enduring risk that reused or previously exposed credentials pose to enterprise environments.

Where MFA Policies Fell Short

Huntress's analysis of compromised organizations revealed a range of MFA configuration weaknesses:

MFA was not enforced across all cloud applications
Enforcement applied only to certain user groups, leaving others unprotected
MFA was required only for logins from non-trusted locations
MFA policies existed in configuration but were never actually enforced
Eight of the affected businesses had no MFA policy whatsoever

Huntress was careful to note that the takeaway should not be that MFA is ineffective overall. Rather, the lesson is that MFA policies must be deliberately scoped to cover the specific authentication flows in use — including legacy flows like ROPC that bypass standard interactive prompts.

This is a meaningful distinction for security teams. A policy that enforces MFA for browser-based logins but leaves service tokens or legacy auth flows uncovered can create a false sense of protection. Attackers are clearly aware of these gaps and are exploiting them at scale.

Credential Hygiene and Policy Coverage: The Combined Defense

This campaign illustrates two compounding vulnerabilities that frequently appear together: weak or reused passwords and incomplete MFA coverage. Addressing either one alone leaves the other as an exploitable path.

Credentials that appear in combo lists — typically assembled from prior breaches — are only useful to an attacker if they still work. Organizations that enforce unique, strong passwords for every account and monitor for credential exposure on the dark web significantly narrow the attack surface before a spray attempt even begins. Tools purpose-built for enterprise password management and credential monitoring, including those in Keeper Security's portfolio, are designed specifically to address this layer of risk.

Beyond credential quality, this incident reinforces the importance of treating MFA as a policy discipline, not just a feature toggle. Security teams should audit which authentication flows are active in their environments, verify that conditional access policies cover all of them — legacy flows included — and regularly test enforcement rather than assuming configuration equals protection.

Password spray attacks succeed through volume and patience. The defenses that stop them are less about any single control and more about ensuring that every layer of authentication coverage is both correctly configured and consistently applied.

Reporting: Source

Data Breach Prevention in 2026: How Stolen Credentials Fuel Breaches — and How Keeper Stops Them

Applied IAM — Thu, 25 Jun 2026 00:00:00 +0000

In June 2026, researchers at Cybernews uncovered an exposed database holding roughly 24 billion records — the majority believed to be infostealer logs of stolen usernames, passwords, and the services they unlock. It wasn't a single company being hacked. It was a compilation of credentials harvested from countless devices and prior leaks, sitting on an unsecured server for anyone to find.

That single discovery captures the defining security story of 2026: the breaches making headlines aren't sophisticated zero-day exploits. They're logins. As one analysis of the month's incidents put it, attackers didn't break in — they logged in.

For any organization, that reframes the entire problem. Firewalls and endpoint tools matter, but the front door most attackers walk through is a valid credential. Strong data breach prevention in 2026 starts with controlling passwords, secrets, and privileged access. This is exactly the ground Keeper Security covers — and as a Keeper partner, it's what Applied IAM deploys and runs for clients every day.

How do data breaches actually happen?

Strip away the headlines and most modern breaches follow one of a few credential-driven paths:

Infostealer malware. A user installs a cracked app or clicks a malicious download, and silent malware scrapes every password saved in their browser. Those logs are bundled and sold — the raw material behind that 24-billion-record trove.

Password reuse and credential stuffing. People reuse the same password across dozens of sites. When one site leaks, attackers replay those email-and-password pairs against banking, email, and corporate logins at scale. This is credential stuffing, and it works because reuse is so common.

Weak passwords. Sometimes it's almost comically simple. In 2026, a flaw in a McDonald's hiring chatbot reportedly exposed data on tens of millions of job applicants — and researchers got in using the password "123456".

Standing privilege and third-party access. Once inside, attackers look for over-privileged accounts and inherited vendor access to move laterally. Several 2026 incidents — from a PayPal Working Capital breach to a claimed intrusion at Adidas via a licensing partner — traced back to access that was broader than it needed to be. Our finance and retail Blind Spot Briefs walk through the same pattern in earlier incidents.

The thread connecting all of these is identity. Stop the credential abuse and you stop most of the breach.

What actually prevents credential-based breaches

If credentials are the attack surface, prevention comes down to a handful of disciplines:

Unique, strong passwords everywhere — so one leaked site can't unlock the rest.
Continuous dark web monitoring — to know the moment a credential is exposed, not months later.
Multi-factor authentication and passwordless — so a stolen password alone isn't enough.
Least privilege and privileged access management — so a compromised account can't reach everything.
Secrets management — so API keys and database passwords aren't hardcoded in plaintext.
A zero-trust, zero-knowledge foundation — so even your security vendor can't see your secrets.

Most organizations agree this is the direction. Keeper's own research found that 86% of IT and security leaders say their organization would benefit from a PAM solution, yet 46% still struggle to manage privileged access consistently. The gap between knowing and doing is where breaches happen.

How Keeper prevents data breaches

Keeper Security addresses the credential problem end to end, on a zero-trust, zero-knowledge platform that protects access for people, machines, and increasingly AI agents. Here's how its pieces map to the attack paths above.

Enterprise Password Manager — kills reuse and credential stuffing. Every user gets an encrypted vault that generates and stores a strong, unique password for every account. When no two passwords match, a single leaked site can't cascade into account takeover. Because the vault is zero-knowledge, not even Keeper's own employees can see what's inside.

BreachWatch — dark web monitoring that catches exposure early. BreachWatch continuously checks the passwords in your vaults against a database of over a billion breached credentials, and alerts users and admins the moment a match is found so they can change it before attackers strike. It does this without ever exposing the passwords themselves, using a double-hashed, zero-knowledge design — so admins see who's at risk without ever seeing the credentials.

KeeperPAM — shrinks the blast radius. When an account is compromised, privileged access decides how far the damage spreads. KeeperPAM unifies password management, secrets management, connection management, zero-trust network access, and remote browser isolation in one cloud-native platform, with session recording and just-in-time access that eliminate standing privilege.

Keeper Secrets Manager — removes hardcoded secrets. Developers leak credentials too, in source code and CI/CD pipelines. Keeper Secrets Manager vaults and rotates API keys, database passwords, certificates, and tokens so they're never sitting in plaintext. Keeper recently launched Universal Secrets Sync to push rotated secrets across AWS, Azure, and Google Cloud automatically and eliminate credential drift.

Put together, these close the exact gaps the 2026 breaches exploited: no reuse, fast exposure alerts, no standing privilege, and no plaintext secrets.

Tools are only half the answer

Buying a platform isn't the same as being protected. The organizations that actually reduce breach risk are the ones that roll these controls out cleanly — vaults adopted company-wide, BreachWatch alerts that reach the right admins, PAM policies that match how teams really work, and secrets pulled out of code without breaking pipelines.

That's where Applied IAM comes in. As a Keeper partner, we help organizations design, deploy, and run Keeper across password management, dark web monitoring, secrets, and privileged access — so the protection is real, not just licensed. We can also run it for you day to day through managed IAM services. The credentials behind the next breach are already out there. The question is whether they'll still open anything that matters.