How Enterprises Actually Buy Cybersecurity

 

I have spent twenty years selling enterprise technology, and I have watched the better solution lose more times than I can count. Not to a stronger competitor. To a buying process the vendor never understood.

Worldwide end-user spending on information security is projected to top $240 billion in 2026, by Gartner's latest forecast. That is an enormous market, and most companies competing in it believe they lose deals on features, price, or timing. They are usually wrong. You rarely lose a security deal on the merits alone. You lose it in the gap between how security teams sell and how enterprises actually buy.

Closing that gap is not a technical skill. It is a commercial one, and it can be learned.

How do enterprises actually buy cybersecurity?

Enterprises buy cybersecurity by committee, slowly, and mostly without you in the room. Gartner's 2025 buyer research puts modern B2B buying groups at anywhere from five to 16 people across as many as four functions. In enterprise security, that group often includes a CISO, a security architect, a compliance lead, a procurement officer, a budget owner, and legal, each carrying a different definition of what good looks like. The exact mix shifts with the category and the trigger. An incident, an audit finding, a renewal, a merger, or a board mandate can reshape both who sits on the committee and how fast it moves.

Here is the part sellers underestimate. Gartner's research shows buyers spend only about 17 percent of the purchase journey meeting with potential suppliers, and an even thinner sliver of that with any single vendor when they are comparing several. You are not the main character in this decision. You are a supporting reference the committee consults briefly and then debates without you.

By the time sales enters, the buyer's preference is often already taking shape. 6sense found that the vendor a buying group ranks first at the end of the selection phase goes on to win about 80 percent of the time. That is a broad B2B pattern rather than a security-specific law, but it holds. The real work of selling happens before the first call, in the reputation, the content, and the peer conversations that shaped that ranking.

Now the core mismatch. Security teams and vendors sell the way engineers think, in features, threats, and technical superiority. Enterprises buy the way executives decide, in risk reduction, business enablement, and political cover for the person whose name goes on the decision. Those are different languages. The vendor who speaks only the first one loses to the vendor who speaks both.

Technical validation still matters, and in security it matters a great deal. The product has to clear the architecture review, the integration test, and the security questionnaire. But clearing those gates does not create a budget, a consensus, or a decision the committee feels safe defending. Technical merit gets you considered. It rarely closes the deal on its own.

Why do good security teams and vendors lose winnable deals?

Because their toughest competitor is not another vendor. It is the buyer deciding to do nothing.

The research is blunt about how often that happens. Analyzing more than 2.5 million recorded sales conversations, the team behind the JOLT Effect found that 40 to 60 percent of deals end in no decision, even after the buyer signals a clear intent to purchase. The reason is not laziness or a simple preference for the status quo. In that research, 56 percent of no-decision outcomes traced to fear of making the wrong choice.

That fear has a structural cause. Gartner found that 74 percent of buying teams experience unhealthy conflict during the decision, and that more than three quarters of buyers describe their last purchase as very complex or difficult. A committee that cannot resolve its own disagreement does not pick you or a competitor. It postpones, and the deal quietly dies.

Good security vendors lose winnable deals for a short list of repeatable reasons:

• They sell to the technical champion and never reach the economic buyer who controls the budget.
• They present capabilities instead of quantifying the cost of doing nothing.
• They cannot answer "why now," so the purchase slides to next quarter and then off the table.
• They give the buyer no political cover, no defensible business case or reference story that makes the decision safe to explain to the board, the CFO, or the next audit.
• They treat a rival vendor as the threat, while indecision walks off with the deal.

None of these are product failures. Every one is a translation failure.

What actually closes an enterprise security deal?

You close it by selling the way the enterprise buys. No five moves guarantee a signature, but these do most of the work.

First, translate the risk into a budget consequence the economic buyer owns. A control gap is abstract. A quantified exposure tied to a number on their budget is a decision they can defend. I wrote about this exact failure in Why Identity Risk Loses the Budget Conversation, and it is the most common place a strong security case falls apart.

Second, multi-thread past the champion. If five to 16 people decide and you know one of them, you are not running the deal, you are hoping. Map the group, learn what each person needs in order to say yes, and give them each a reason.

Third, arm your champion for the room you are not in. The committee debates you without you present, and most of those rooms hold real conflict. Your champion is selling on your behalf whether you helped them or not. Hand them the business case, the answers to the hard questions, and the one-page argument they can carry upstairs.

Fourth, build a real reason to act now, and make sure it is real. Regulatory deadlines are the cleanest source of urgency, but only when the buyer understands the scope, the timing, the enforcement exposure, and the work required to comply. A date on its own does not move a committee. The CMMC timeline shift I covered in CMMC Phase 2 Paused: Why the Work Should Not Stop is a live example of a deadline that moved and left buyers unsure whether to act, and that uncertainty stalls decisions.

Fifth, lower the buyer's career risk. This is the counterintuitive one. Where fear of a wrong decision is the obstacle, piling on more evidence of how bad the status quo is tends to backfire. The JOLT research found that leaning harder on the cost of inaction made things worse more often than not. The buyer already believes they have a problem. What they need is confidence that choosing you is the safe move, not another reason to be afraid.

I write about this intersection of cybersecurity and commercial strategy, because in enterprise security they are the same discipline. If your team is working through a stalled deal or a buying process that will not close, connect with me on LinkedIn.

Frequently asked questions

Who actually decides on a cybersecurity purchase?

Rarely one person. Enterprise security deals commonly involve security, architecture, compliance, procurement, finance, and legal. A technical champion often starts the process, but the budget owner has to carry the business case, and procurement, legal, security architecture, privacy, or executive leadership can reshape or stop the decision.

Why do enterprise security deals stall?

Most stall on internal disagreement, not on the product. Gartner found that 74 percent of buying teams hit unhealthy conflict during the decision, and no decision is a leading cause of lost deals. When a committee cannot align, the safest path for its members is to postpone, and postponement usually ends the deal.

What is the biggest mistake security vendors make?

Selling features to the champion instead of selling business outcomes to the whole committee. A champion who loves the product still has to win an argument with a budget owner and a room full of peers. If you have not given that champion a business case and political cover, you have left them to lose the deal on your behalf.

How long do enterprise cybersecurity sales cycles run?

Complex enterprise deals commonly run several months, and often past a year, because every added stakeholder adds research, review, and another chance to stall. The length is a symptom of the committee dynamic, which is why shortening a cycle depends on reducing internal friction rather than pushing harder.

The skill that decides the deal

Cybersecurity is one of the largest and fastest-growing categories of enterprise spending, and the competition for those budgets is fierce. Yet most of the vendors and internal teams fighting for that money are fighting the wrong battle. They sharpen the product when they should be learning the buyer.

The enterprises writing these checks do not buy the best technology. They buy the case they can defend, from the vendor who made the decision feel safe. The teams that win have stopped treating the sale as something beneath the technology and started treating it as the discipline it is. Translate the risk into money, arm the people who decide, and take the fear out of the choice. That is how enterprises actually buy cybersecurity, and it is how you get them to buy yours.

---

Navneet Lounsberry writes on cybersecurity and commercial strategy, drawing on more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

AI Is Writing Your Code and Leaking Your Secrets

 

I use AI to write code, and I am not giving it up. Neither should your engineering teams. Teams are adopting AI assistance to ship faster, and that shift is not reversing. That is exactly why the security problem underneath it deserves a clear look. AI-assisted development can introduce hardcoded secrets and expand the number, privilege, and reach of the non-human identities working across your delivery pipeline. Most organizations are not governing either one, and that gap is where the next wave of breaches is forming.

None of this argues for slowing down. It argues for governing what AI-assisted development creates, so the speed you gained does not turn into exposure you never priced in.

The risk is not one thing. AI-assisted development expands risk in three connected but distinct places. The generated code can carry security defects. Prompts, repositories, logs, and output can expose credentials, in both directions. And the agents reaching your source control, cloud services, and data need identities with carefully bounded permissions. A secret scanner does not fix an over-permissioned agent, and least privilege does not catch insecure application logic. You have to govern all three.

 

How does AI-assisted development expose secrets?

AI-assisted development exposes secrets because the models reproduce the patterns they learned from, and public code is full of hardcoded credentials. When an assistant generates a working example, it can embed an API key, a connection string, or a token directly in the code, especially when the prompt, the repository context, or the surrounding code already normalizes that pattern. The code runs. The secret can ship.

The data released in 2026 shows how fast this grew in 2025. GitGuardian's State of Secrets Sprawl 2026 counted more than 28 million new hardcoded secrets in public GitHub commits during 2025, a 34 percent jump and the largest single-year rise on record. Leaks tied to AI services rose 81 percent in a single year. In the same analysis, commits co-authored by one popular assistant, Claude Code, exposed secrets at 3.2 percent against a 1.5 percent baseline across all public commits. GitGuardian is careful about that number, and so am I. The leak still runs through a human workflow. Developers decide what to accept, edit, or push. The tool did not fail. The process around it did.

Two forces compound the problem. AI increases code volume and change velocity, which makes manual-only review less reliable as the primary control. And the exposure runs in both directions. An assistant can write a secret into code, and a developer can hand one to the assistant, pasting a production log, a config file, or an error trace full of tokens into a prompt. GitGuardian found that roughly 28 percent of secret incidents now originate outside code repositories entirely, in places like Slack, Jira, and Confluence, where credentials get shared during urgent troubleshooting. Any policy that governs only the code misses half the problem.

None of that is a reason to stop. It is a reason to assume AI-assisted work may contain secrets until a scan proves otherwise, and to govern both what the tools can reach and what people can submit.

Every AI coding agent needs a governed identity

Here is the part that sits squarely in my field. AI-assisted development is not only a code problem. It is an identity problem.

Every AI agent that reaches your environment does so through one or more non-human identities: a service account, an OAuth client, an API key, a certificate, or a short-lived token. A coding assistant, a build agent, a deployment bot, each authenticates as something, and the more work you hand it, the more entitlements it accumulates. In agentic and multi-agent workflows, one orchestrator can create or delegate to additional agents, multiplying credentials and audit paths as it goes.

 

This is not a fringe concern. Reports through 2026 put non-human identities at anywhere from around fifty to one hundred times the number of human identities in cloud-heavy environments, with the exact ratio depending on what gets counted. The World Economic Forum has called non-human identities the new frontier of agentic AI risk, and analysts increasingly treat AI agents as a distinct identity type that is neither fully human nor fully machine. I covered the governance side in Non-Human Identities and AI Agents: The New Blind Spot in Your IAM Program, and AI-assisted development is where that blind spot turns operational.

The risk is not limited to the code an assistant suggests. Once an agent can read a repository, call tools, open tickets, invoke CI/CD, or connect through a Model Context Protocol server, it becomes an execution path into the enterprise. GitGuardian found more than 24,000 secrets sitting in Model Context Protocol configuration files on public GitHub, a pattern the setup instructions themselves often encourage. Add prompt injection delivered through a README, an issue, or a dependency's documentation, and the agent's permissions, allowed tools, and data boundaries need the same design discipline you give any privileged workload.

The uncomfortable pairing is this. AI writes code that leaks the very secrets these identities depend on, inside a system where the identities themselves are barely governed. Leaked credential, meet ungoverned identity. That is the attack path.

The productivity is real, so protect it

I want to be direct about where I stand, because the headline can read the wrong way. I am not arguing against AI-assisted development. I am arguing for keeping it.

The teams shipping with AI assistance are faster, and that advantage is not going back in the box. Telling engineers to slow down is both futile and wrong. The organizations that win will adopt aggressively and govern deliberately, and those two things are not in tension. Security is not the brake on AI development. It is what lets you keep your foot on the accelerator without wrapping the car around a tree.

Consider how a mature enterprise already treats any third-party dependency. You do not refuse open-source libraries because some carry vulnerabilities. You scan them, track them, patch them, and keep shipping. AI-generated code deserves the same posture. Treat it as untrusted input from a very fast contributor, verify it, and move on. That is not skepticism about AI. It is how you make AI safe to rely on at scale.

How do you secure AI-assisted development without slowing it down?

You secure it by governing the two things AI development produces, code and identities, with controls that run at machine speed instead of human speed. The goal is not more meetings. It is automation that keeps pace with the tools creating the risk.

A practical program rests on a few moves:

• Scan for secrets continuously, in the pipeline and beyond it. Run detection on every commit and every AI-assisted change, and extend it to the tickets, chat, and logs where secrets also land. Removing a key from code is not enough, since it can be recovered from history, so rotate or revoke it too.
• Give every agent its own scoped identity. No shared keys, no borrowed service accounts, outside narrow legacy exceptions you document and monitor. Each agent gets a named identity with least-privilege access to only what its task requires.
• Prefer short-lived, dynamically issued credentials. Replace long-lived static keys with tokens that expire in minutes where the platform supports it. A leaked credential that has already expired is close to a non-event.
• Keep an owned inventory of non-human identities. Every agent and service account needs a human owner, a documented purpose, and a decommission date. Unowned identities are where risk hides.
• Treat AI output as an untrusted contribution, and do not stop at review. Apply the same supply-chain controls you use elsewhere: dependency and infrastructure-as-code scanning, branch protections, code-owner review for anything touching authentication, authorization, cryptography, payments, data access, or deployment, and an audit trail that ties each material change to a user, an agent, and an identity.

These controls shift the security work from a late, manual gate to an early, automated one, which is the only model that survives contact with AI-speed development. Integrated into developer workflows, they cut late-stage rework instead of adding a release bottleneck, and they keep most of AI's delivery advantage while slashing the cost of remediation.

Detection without revocation is not remediation, and the data proves it. GitGuardian retested credentials it first confirmed valid in 2022 and still found more than 64 percent of them live in 2026. When a secret surfaces, rotate or revoke it, trace where it was used, assess what it could reach, and fix the control at the point it entered the workflow.

Where you sit on this path matters more than doing everything at once:

Stage	Minimum standard
Pilot	Approved tool list, no production secrets in prompts, user-level attribution, basic secret scanning
Team rollout	SSO and SCIM, repository and data-access boundaries, CI secret scanning, branch protections, named owners for service accounts
Enterprise scale	Short-lived federated workload identity, centralized secrets management, agent and tool allowlists, full audit logging, revocation workflows, continuous entitlement review

This is also where the commercial conversation lives, and it is rarely a technical failure that stalls these programs. It is that the person who sees the risk cannot translate it into a consequence the budget holder acts on. I worked through that exact dynamic in Why Identity Risk Loses the Budget Conversation, and it applies directly here. Frame AI governance as protecting the productivity leadership already values, and you get funded. Frame it as a brake, and you do not.

I write about where identity security and commercial strategy meet, because in AI-assisted development they are the same conversation. If your organization is working through this, connect with me on LinkedIn.

Frequently asked questions

Is AI-generated code less secure than human-written code?

Not inherently, but it should not be presumed secure. Results vary by model, prompt, language, task, and review process. A 2026 study across six leading models reported confirmed vulnerabilities in about a quarter of generated samples, while earlier research on one popular assistant found security weaknesses in roughly 40 percent of the scenarios tested. Those figures need their methodology to mean anything, and they do not add up to a universal defect rate. The operational answer is to test and review AI output under the same controls, or stronger ones, that you apply to any untrusted contribution.

What is a non-human identity in AI development?

It is the identity assigned to software, a workload, a service, a bot, a pipeline, or an AI agent, so it can authenticate and act without an interactive human login. Its authenticator might be a service account, a workload identity, an OAuth client, a certificate, an API key, or a short-lived token. The governance questions that matter are who owns it, what it can access, how long it lasts, how its activity is logged, and how it gets revoked.

Can developers paste production code or error logs into a coding assistant?

Only if your organization has approved the tool, understands its data-handling terms, and has defined what may be submitted. Production secrets, customer data, private keys, and regulated information should be blocked or redacted before they reach a prompt. The same policy should cover repository-context features and tool integrations, not just the chat box.

What should happen when a secret shows up in AI-assisted code?

Treat it as an incident, not a text edit. Revoke or rotate the credential, determine whether it was used, assess the access it carried, remove it from active code and configuration, and add or tune the control that should have caught it before production.

How do we let developers use AI without creating security debt?

Automate the controls so they run at the speed of the tools. Scan every change and channel for secrets, scope each agent to least privilege, expire credentials quickly, and review AI output like any third-party dependency. That keeps the productivity while closing the exposure.

The speed is worth keeping

AI-assisted development is one of the most significant productivity shifts enterprise engineering has seen, and the organizations leaning into it are right to. The mistake is treating the speed as free. It arrives with generated code that needs verifying, secrets that need detecting and rotating, and machine identities that need scoping, ownership, and observation, and the companies that build those habits early will keep their advantage while others clean up breaches they could have prevented.

AI is writing your code, and yes, it can leak your secrets. That is a solvable problem, and solving it does not mean making developers wait. Make secure behavior the default: credentials injected at runtime instead of written into code, short-lived access instead of permanent keys, and automated checks that catch problems before production. Govern the identities, protect the context, scan the code and the secrets, and let your teams keep building at the speed the tools finally made possible.

---

Navneet Lounsberry writes on cybersecurity compliance and commercial strategy, most recently with Idenhaus Consulting. She spent more than two decades in enterprise technology sales and business development across IBM, SAP, Manhattan Associates, and UKG.

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne

Why Identity Risk Loses the Budget Conversation

 

By Navneet Lounsberry

---

 

In May 2026, Verizon published the nineteenth edition of its Data Breach Investigations Report. For the first time in the report's history, stolen credentials lost the top spot as the leading initial access vector. Vulnerability exploitation climbed to 31 percent. Credential abuse dropped to 13 percent, down from 22 percent the year before.

I watched that finding travel through the market in about a week. Vendors repositioned. Analysts wrote it up. And somewhere in a budget review, a finance leader pulled up the headline and asked a reasonable question: if identity attacks are falling, why does the identity program need more money this year?

The security team in that room knows the answer. Verizon tracked credential abuse across the full breach chain, not just the front door, and found it present in 39 percent of breaches. The report also introduced a new pretexting category that absorbed some of what previously counted as credential abuse. The headline describes first contact. The 39 percent describes what attackers actually do once they arrive.

Knowing that answer and delivering it are two different skills. Most security teams have the first one. Fewer have the second. That gap explains more stalled identity programs than any technical shortcoming I have seen across twenty years of enterprise selling.

Why does identity security lose the budget conversation?

Identity security loses budget conversations because practitioners describe risk in architectural terms while executives allocate money in consequence terms. The technical description is correct. It simply does not answer the question the person holding the budget is actually asking.

A security architect says the organization runs password hash synchronization with a single Entra Connect server that sits outside the Tier 0 management boundary. Every word of that carries meaning. None of it tells a CFO what breaks, what it costs, or what happens if the company does nothing for another year.

This is not a communication failure in the soft sense. It is a translation failure with a measurable price. Programs that never get funded never reduce risk, and the exposure compounds quietly while the architecture documentation gets more accurate every quarter.

The identity bridge shows the problem clearly

The clearest example I know sits in almost every large hybrid environment: the connection between on-premises Active Directory and Microsoft Entra ID.

What is the identity bridge?

The identity bridge refers to the components that link on-premises identity to cloud identity. In most Microsoft environments that means Entra Connect synchronization servers, pass-through authentication agents, and Active Directory Federation Services where organizations still run federation.

Microsoft does not treat these components casually. Its own documentation classifies Entra Connect servers, AD FS, Entra application proxy, and Active Directory Certificate Services as Control Plane assets, the tier formerly called Tier 0, alongside domain controllers themselves. Microsoft recommends restricting administrative access to these servers to tightly controlled groups, denying NTLM authentication to the Entra Connect server, and hardening the platform to the same standard applied to the directory it serves.

The reasoning is direct. Entra Connect holds privileged access to both sides. It reads objects from Active Directory using a connector account and writes synchronized objects into Entra ID using a dedicated service account. In password hash synchronization deployments it reads Kerberos hash material from the directory. Anyone who controls that server controls the credentials of every synchronized account.

Why do attackers target the identity bridge?

Attackers target the bridge because compromising it converts a local foothold into complete access across both environments, and because the resulting access looks legitimate.

Golden SAML illustrates this better than any other technique. CyberArk Labs first described the attack in 2017. An attacker who obtains the private key of an AD FS token-signing certificate can forge authentication assertions for any user, in any role, against any application that trusts that federation service. The forged token validates correctly against the public key. Multifactor authentication does not apply, because no authentication actually occurs. Conditional Access policies do not apply for the same reason. The relying party cannot readily distinguish the forged assertion from a genuine one.

This is not theoretical. The threat actor behind the SolarWinds intrusion used exactly this technique in the wild, compromising SAML signing certificates and minting valid tokens to reach hosted resources including email. Mandiant documented the technique in further detail in 2021, and its researchers recently found that manual certificate rotation can silently leave active signing keys recoverable from Machine DPAPI, meaning organizations that believed they had rotated remained exposed.

Read that sequence carefully. An attacker who reaches one server bypasses every identity control the organization purchased, and does it in a way that generates authentic-looking activity.

Why does the bridge stay underfunded?

Here is where the commercial problem shows up. The technical case for protecting the identity bridge is overwhelming and publicly documented by the vendor itself. The work still does not get funded, for four reasons that have nothing to do with architecture.

• Nobody senior owns it. The sync server usually belongs to a Windows infrastructure team that reports through IT operations, not security. It sits between two org charts and appears fully in neither.
• No compliance framework names it. Auditors ask about MFA, access reviews, and privileged accounts. Few ask whether the synchronization server carries a Control Plane hardening standard, so the finding never appears on the remediation list that drives spending.
• It never fails loudly. A misconfigured firewall causes an outage. An underprotected sync server runs perfectly for years, right up until it does not.
• It has no business name. Executives fund things they can name. "Entra Connect hardening" is not something a board member can repeat to a peer.

That last point matters most. Budget follows narrative, and the identity bridge arrives without one.

How do you translate identity risk into business language?

Translation is a discipline, not a personality trait. Three moves do most of the work.

Name the consequence, not the mechanism

Executives do not need to understand token forgery. They need to understand what an attacker gains and what the organization loses.

Compare two descriptions of the same risk. The first: an attacker with administrative access to the AD FS server can extract the token-signing certificate and forge SAML assertions that bypass Conditional Access. The second: one compromised server lets an attacker log in as our CFO, from anywhere, without a password, and our multifactor investment does not stop it.

Both statements are true. Only one of them ends with someone asking what it would take to fix.

I want to be precise about what this is not. Translation does not mean simplifying until the claim stops being accurate, and it does not mean reaching for fear. Buyers eventually catch overstated risk, and the credibility loss outlasts the deal by years. The goal is to state the real consequence in the vocabulary of the person deciding.

Attach the risk to something leadership already funds

Unnamed risk competes badly. Risk attached to a funded priority competes well.

Nearly every enterprise currently runs a cloud migration, an ERP program, a merger integration, or a compliance deadline with executive attention behind it. The identity bridge sits underneath all of them. A migration that synchronizes identities into a cloud tenant depends entirely on the integrity of that synchronization. A defense contractor working toward CMMC assessment cannot demonstrate access control over systems where a single server undermines every access decision.

Framing the work as protecting an initiative the organization already committed to does something a standalone security request cannot. It moves the conversation from new spending to protecting existing spending, and those two conversations have very different success rates. I wrote about a related version of this dynamic in CMMC in the Plant, Not the PowerPoint, where compliance programs succeed or fail based on whether they touch operational reality.

Offer the smallest credible first step

Large identity programs stall because they ask for a decision proportional to their scope. Executives approve things they can reverse.

A hardening assessment of three servers is a decision someone can make in a single meeting. A three-year identity governance transformation requires a steering committee, a business case, and a budget cycle. The first one creates evidence that makes the second one easier to approve later.

This sequencing is not a sales technique. It reflects how organizations genuinely absorb change, and practitioners who understand it get more of their work funded than practitioners who insist on the complete program up front.

What buyers actually say when identity risk stalls

Certain objections repeat across industries. Each one signals a specific gap.

When a buyer says they already deployed MFA, they believe they solved the identity problem. They have not heard that token forgery and session theft operate downstream of authentication entirely.

When a buyer says they cannot explain this to their board, they are asking for language, not information. That request deserves a direct answer rather than more technical detail.

When a buyer says the sync server belongs to another team, they have identified an ownership gap that will block the work regardless of how strong the technical case becomes. Somebody has to resolve that before anything else moves.

When a buyer says nothing has happened yet, they are applying the reasonable heuristic that quiet systems are healthy systems. The identity bridge is specifically the place where that heuristic fails, and saying so plainly tends to land.

What this means for commercial teams in cybersecurity

I have spent my career on the commercial side of enterprise technology, at IBM, SAP, Manhattan Associates, UKG, and most recently in identity and access management consulting. The pattern I keep returning to is this: technical depth and commercial effectiveness are not competing skills, and the strongest people in identity security refuse to choose between them.

The sellers who consistently win complex identity deals do not win because they know more about Kerberos than their competitors. They win because they can hold an architecture conversation with a security engineer at nine in the morning and a consequence conversation with a CFO at two in the afternoon, without changing the underlying facts between those two meetings.

That second conversation is where most identity programs live or die, and it receives a fraction of the preparation the first one gets. For anyone building a career in this market, the translation skill compounds faster than any product certification.

That translation skill sits alongside the rest of the commercial toolkit. Full Throttle Media covers the adjacent territory in B2B Displacement Campaigns: Win Competitor Customers, which works the same problem from the account strategy side.

Frequently asked questions

Is the identity bridge only a Microsoft problem?

No. Microsoft environments make it most visible because Entra Connect and AD FS are widely deployed and well documented. Any organization that synchronizes or federates identity between an on-premises directory and a cloud provider carries the same structural exposure, including those running third-party identity providers alongside a legacy directory.

Does multifactor authentication protect against Golden SAML?

No. Golden SAML forges the authentication assertion itself, so the authentication event never occurs in a form that MFA or Conditional Access can evaluate. Protecting against it requires securing the federation infrastructure, controlling and monitoring token-signing certificates, and auditing certificate export and configuration changes.

How should an organization prioritize the identity bridge against other security work?

Prioritize it by blast radius rather than by likelihood. Most security findings expose one system. A compromised synchronization or federation server exposes every synchronized identity across both environments simultaneously, which places it in the same category as a domain controller.

What is the first question a security leader should ask about hybrid identity?

Ask who administers the synchronization and federation servers, and whether those administrators use the same accounts and workstations they use for ordinary IT work. The answer reveals whether the organization treats the bridge as a Control Plane asset in practice or only in documentation.

Did identity risk actually decline in 2026?

The 2026 Verizon DBIR showed credential abuse falling as an initial access vector, partly because a new pretexting category absorbed some incidents previously counted as credential abuse. Across the full breach chain, credential abuse still appeared in 39 percent of breaches. Attackers changed how they get in more than they changed what they do afterward.

The work is a translation problem

The identity bridge deserves attention on its technical merits, and the vendor documentation, the threat research, and the incident history all say so clearly. None of that has been enough on its own, which tells us something worth taking seriously.

Security programs do not fail only because teams miss the risk. They fail because the people who see the risk most clearly describe it in a language the people holding the budget do not speak. That is a solvable problem, and solving it does not require anyone to dilute the technical truth. It requires naming consequences, attaching risk to priorities the organization already values, and asking for a first step small enough to approve.

 

---

About the Author

Navneet Lounsberry brings over two decades of enterprise sales and business development experience across IBM, SAP, Manhattan Associates, UKG, and Idenhaus Consulting, where her work spanned identity and access management and cybersecurity compliance, including CMMC. A Georgia Tech graduate, she writes about how enterprise buyers in regulated industries actually evaluate, procure, and operate compliance programs.

 

 

Copyright © 2026, Full Throttle Media, Inc. FTM #fullthrottlemedia #inthespread #sethhorne