DEV Community: Thinus Swart

Passkey Adoption Is Rising, but Is It Worth It Yet?

Thinus Swart — Fri, 02 Oct 2026 08:54:16 +0000

Passkeys are fast becoming an appealing alternative to passwords. Built on standards developed by the FIDO Alliance and supported by companies like Apple, Google, and Microsoft, passkeys allow users to authenticate with biometrics, device PINs, or hardware-backed credentials instead of remembering passwords.

For enterprises, there are some compelling arguments for switching to passkeys: stronger protection against phishing attacks and a promised, improved user experience. However, adopting passkeys also raises some questions around legacy systems, device management, recovery workflows, and rollout strategies.

This article explains what passkeys are, how synced and device-bound passkeys differ, the operational challenges to consider, and where passkeys offer advantages over traditional passwords. In short, you’ll learn whether passkey adoption is truly worth it yet.

What Are Passkeys?

Passkeys are a passwordless authentication method that uses public-key cryptography to verify a user’s identity. Instead of creating and storing a traditional password, a user’s device generates a cryptographic key pair: a private key that stays securely on the device and a public key that is shared with the application or service.

When the user signs in to an application or a website, a challenge, that is, a random cryptographic string, is sent to their device. The user unlocks access to the private key stored on their device using a biometric factor like a fingerprint or face scan, or a device PIN. The private key then signs the challenge, which is sent back to the application or website for verification. The following diagram shows this sign-in flow from challenge to verified access.

Because the private key never leaves the device and there is no shared secret to steal, passkeys are far more resistant to phishing, credential theft, and password reuse attacks than traditional passwords.

Passkeys are built on standards developed by the FIDO Alliance and the World Wide Web Consortium (W3C), allowing them to work across modern browsers, operating systems, and devices. Major platforms such as Apple, Google, and Microsoft have integrated passkey support directly into their ecosystems, helping to accelerate adoption across both consumer and enterprise environments.

Different Types of Passkeys

Broadly speaking, you will encounter two main types: synced passkeys and device-bound passkeys.

Synced passkeys

Synced passkeys are designed for convenience and portability. These passkeys are securely synchronized across a user’s devices through a cloud ecosystem such as Apple iCloud Keychain or Google Password Manager. This allows users to enroll a passkey on one device and use it on another device connected to the same account.

Synced passkeys can significantly improve the user experience and reduce onboarding friction. Employees can move between laptops, phones, and tablets without repeatedly registering new credentials. However, organizations might have concerns about control and recovery, particularly in regulated environments where credentials being synchronized through personal cloud accounts could introduce governance or compliance challenges.

Device-bound passkeys

Device-bound passkeys remain tied to a specific device or hardware authenticator and are not synchronized elsewhere. Examples include credentials stored in hardware security keys, such as Yubico, or TPM-backed credentials managed directly on enterprise-controlled devices.

They provide stronger control over where credentials are stored and are often preferred in high-security environments. If an attacker compromises a cloud account, they do not also gain access to the credentials because the passkey never leaves the original device. The tradeoff, however, is a loss of usability and convenience. Replacing lost devices, onboarding additional devices, or recovering credentials can become more operationally complex for both users and IT teams.

What Are the Main Benefits of Using Passkeys in the Enterprise?

The biggest benefit for considering passkeys is risk reduction.

Because authentication is tied to a set of cryptographic credentials, rather than a shared secret, you can dramatically reduce your users' exposure to phishing campaigns and other credential-related attacks. For phishing in particular, since the private key is bound to a specific web domain, it cannot be used to authenticate the user on a different domain.

Passkeys can also improve your efficiency. Password resets are probably one of the more common helpdesk requests in many companies. Reducing the reliance on passwords can lower your support overhead. Your users will also appreciate the smoother sign-in experience.

Finally, the switch to passkeys definitely aligns more closely with modern security strategies. Companies are actively pursuing zero-trust architectures and stronger MFA adoption. Passwordless initiatives like passkeys fit neatly into those efforts, and can help enterprises modernize their authentication strategy.

What Are Some of the Main Challenges of Using Passkeys?

In spite of the benefits, switching to passkeys is not as simple as just enabling a new login option.

Many organizations have older applications and internal systems that do not support passkeys and might need to be retrofitted to do so. Third-party platforms also might not support passkeys yet, so you are stuck with using passwords on those platforms until they decide to support them.

In reality, this means that enterprises would probably need to manage a hybrid authentication model during any transition period.

Recovery and lifecycle management also plays a much bigger role with passkeys. When employees lose a device or leave the company, IT teams need clear processes for credential recovery, re-enrollment, and revocation. These workflows can be more complex than traditional password reset processes.

Because passkeys are more than likely device-bound, there is no central credential to reset. Instead, IT teams must verify the user's identity through a separate, out-of-band process before issuing a new enrollment, and any previously registered passkeys on lost or decommissioned devices need to be explicitly revoked.

Finally, organizations need to decide whether they prefer device-bound or synced passkeys, and whether different choices should apply to contractors and remote employees.

What About Legacy Systems?

If you are considering implementing passkeys for your organization, legacy systems are probably going to be one of the bigger hurdles. Older applications might not support modern authentication standards like WebAuthn or FIDO2.

That does not always mean that passkeys are off the table. You can implement identity platforms or single sign-on (SSO) platforms in front of legacy applications to handle the authentication in a more modern way.

In practice, most organizations will likely operate hybrid authentication environments for some time, using passkeys where they fit naturally while maintaining alternative authentication methods for systems that cannot support them yet.

Consider a Phased Rollout

For most organizations, a phased rollout is usually the most practical approach to any new implementation, but especially for passkeys. Rather than forcing the entire company to migrate immediately, it is a good idea to start with smaller user groups or lower-risk applications.

A gradual rollout allows IT and security teams to evaluate the user experience at multiple points during the process. This can help to identify compatibility issues, and to refine existing recovery and support processes before you expand to a larger audience.

Passkeys are likely to coexist with passwords for some time, especially if legacy systems are involved. A phased rollout will help organizations to modernize any internal applications and systems they might have under their control.

Passkeys vs. Passwords

Passwords remain an embedded part of enterprise environments everywhere. Despite their weaknesses, they offer flexibility and a universal compatibility that systems and users understand. Given that you will likely still have to rely on passwords for some time, you might be weighing up whether passkeys deserve a place in your authentication strategy.

This is not simply a case of "new versus old". Passkeys were created to solve many of the security and usability problems that passwords have struggled with traditionally, as can be seen in the pros and cons of both authentication methods.

	Pros	Cons
Passwords	Universally supported by practically any system Familiar to users and systems alike Easier to centrally control and reset Does not require modern devices or hardware Simpler to use in legacy environments	Vulnerable to phishing attacks Users often create weak or reused passwords MFA adds friction and can still be bypassed
Passkeys	Strong resistance to credential theft and phishing Faster and smoother login experience Reduces password resets and support overhead No passwords for users to remember	Legacy systems may not support them Losing a device can cause significant headaches Enterprise rollouts require planning and user education Synced passkeys could raise governance concerns

So, Is Passkey Adoption Worth It?

In many cases, the answer is "yes", but with an important caveat: the value you might derive from switching to passkeys depends heavily on your company's infrastructure and security priorities.

For enterprises that are already investing in modern identity platforms, zero-trust initiatives and managed devices, passkeys are a natural fit and can provide meaningful security and usability improvements for large parts of your organization.

The strongest argument for passkeys is that they directly address many of the weaknesses that have plagued passwords for years. Passkeys reduce exposure to phishing and credential theft. Passkeys in general also make the authentication process feel smoother for most users. No need to remember long passwords, or open your password manager for the umpteenth time.

With all that said, that does not mean passkeys are a magic replacement for all your authentication woes. Enterprises still need to think carefully about recovery workflows, device management and legacy application support. You will need to have governance policies and employee training guides in place before you transition to passkeys.

Passkeys are not an "all or nothing" decision to make, but something that requires a gradual and strategic adoption plan. They are probably worth considering if your organization answers "yes" to at least two of these statements:

You want stronger protection against phishing and credential-related attacks.
You manage corporate devices for your employees.
You are already in the process of modernizing your IAM infrastructure.
You want to reduce password-related support costs and friction.
So passkeys might not completely replace passwords overnight, but for many enterprises, they are a mature enough technology to justify consideration as part of a long-term authentication plan.

Passkeys Are a Strategic Decision

The question of whether to adopt passkeys is less about whether they are inherently good or bad, and more about whether your organization is ready to support them effectively. Factors like device management, governance policies, and infrastructure readiness play an important role in figuring out whether passkeys will provide value in your environment.

For many companies, the path forward should be a gradual one: Introduce passkeys where they make the most sense, while continuing to support traditional authentication methods where necessary. Adoption should continue to grow across third-party platforms and other enterprise tooling too, and you can enable passkeys on these platforms as they become available.

Passkeys are less of an experimental feature like they were a few years ago, and more of a serious consideration for a long-term authentication strategy.

LLMjacking and the Hidden Cost of a Stolen API Key

Thinus Swart — Fri, 02 Oct 2026 08:31:17 +0000

For the past few years, one topic has constantly been on the minds of tech professionals around the world: AI.

AI is no longer just another piece of the tech stack but is fast becoming its foundation. Major business features, like customer support and data analysis pipelines, are being shifted to Large Language Models (LLMs), and businesses are more dependent on LLMs every day. That dependency has not gone unnoticed by attackers. As LLMs become more central to core business processes, they have become a valuable target in their own right.

This article explains how LLMjacking works, the potential risks and costs associated with an attack, and what you can do to detect and prevent it.

What Is LLMjacking?

LLMjacking involves attackers hijacking access to your LLM. Although the widespread adoption of LLMs is a relatively recent development, LLMjacking itself is just a different spin on a familiar attack: Gaining access to stolen or exposed credentials. Before the LLM era, criminals used to look for AWS or GCP access keys, which could potentially give them access to compute resources, storage, and sensitive company information.

The repercussions from stolen and exposed credentials are bad enough, but LLMjacking has the potential to cause significantly more harm (financial or reputational) to both an organization and its clients. LLM usage is often metered and expensive, so abuse can translate directly into financial impact. If the key is tied to custom models, internal prompts, or sensitive data pipelines, the risk is no longer solely about compute resources. Unlike a stolen cloud key, a compromised LLM credential can give an attacker access to far more than raw data.

What Harm Does LLMjacking Cause?

The impact of an LLMjacking incident goes beyond unexpected API usage or inflated billing. It can very quickly escalate into a significant financial loss, disruption of day-to-day operations, and exposure of sensitive company or customer data.

Understanding these risks in detail is important because the potential consequences extend across multiple aspects of your business.

Financial impact of LLMjacking

This is usually the first place where you notice that "something is wrong". If you see the impact of LLMjacking in your bills, it is likely that the attack has already done significant damage. An attacker with unfettered access to your LLM API could easily have used it to spin up spam email templates, phishing sites, and even malware for their own nefarious purposes.

If you have usage and billing limits, you might think you are safe. There is only so much an attacker could do with your LLM, right? However, any downstream agentic processes or automated workflows dependent on the LLM will also be affected. This could have an even bigger financial impact on the organization, especially if those processes are tied to critical business functions.

Malicious use of custom models

Some organizations rely heavily on custom models, usually trained on internal documents and business processes to help the model better understand how your organization operates. Increasingly, these kinds of models are being used for new and existing employees as a kind of "wiki". If you are not sure what to do with a specific document or which employee to speak to about a specific situation, just ask the LLM using the custom model.

Should an attacker gain access to this model, however, they could gain knowledge about your organization that was never intended to be public. This kind of information could be used to further extend their foothold on your network, or it could allow an attacker to sell this information on the dark web.

Data poisoning

In some environments, these same custom models are constantly being refined and trained using new organizational or financial data. Should an attacker gain access to the training data or the method used to train your custom models, it can create opportunities for data poisoning.

An attacker could gradually influence the model over time to provide misleading or biased responses to employees. While this is a more time-consuming exercise, it allows them to nudge decisions, surface false information, or steer internal processes. Any changes made to the model are usually very subtle and therefore difficult to detect.

Different Attack Vectors

As discussed before, LLMjacking is not really something new. These attack vectors are similar to the ones already employed by attackers for getting AWS/GCP/Azure access. The difference is that these API keys to your LLMs have the potential to create more harm for your organization.

In practice, LLMjacking typically involves an attacker obtaining an API key through phishing, source code leaks, misconfigured environments, or exposed client-side code.

Good old phishing

Despite increasingly sophisticated AI-assisted attacks, attackers still rely on one of the oldest tricks in the book: convincing someone to just hand over their credentials. Phishing campaigns remain a highly effective way to gain access to LLM resources, as these campaigns target people rather than technology.

A well-crafted phishing page is probably the easiest way that most attackers would gain access to your credentials. All of the old tactics still work: creating a false sense of urgency or spoofing platform notifications, all of which are designed to pressure a user into acting quickly.

Bad cloud or application configurations

Misconfigured cloud environments continue to be one of the easiest ways for attackers to obtain sensitive credentials, and LLM integrations are no exception. API keys are often stored in environment variables, configuration files, container images, CI/CD pipelines, or logging systems that were never meant to be publicly accessible. Overly permissive S3 buckets, an exposed Kubernetes dashboard, or a poorly secured Git repository can hand attackers everything they need without requiring them to exploit a vulnerability directly.

The speed at which LLM integrations are being deployed in the modern tech stack makes the potential impact of this attack vector even worse. Teams will frequently prioritize function over security best practices. This is exactly how credentials end up getting leaked, giving potential attackers free, unadulterated access to your LLMs.

How Do You Monitor and Detect LLMjacking Attacks?

Detecting an LLMjacking incident is less about spotting a single obvious breach (although you should still be on the lookout for those) and more about identifying unusual patterns of usage.

Stolen API keys are often used in ways that mimic legitimate usage, which could make it harder for traditional security monitoring tools to spot the anomalies.

Baseline your organization's LLM usage first

Before you can detect abnormal behavior, you need to know what "normal" looks like for your organization. This means establishing a baseline of API request volumes, token consumption, and common API endpoints. This baseline should also be established across different time periods. Do you normally have usage spikes on month-end? What about every second Tuesday?

A solid baseline can help distinguish between organic usage changes and potential abuse. This baseline should be used to constantly compare against current usage patterns, and anomalies should be investigated as soon as possible to determine whether it was legitimate usage spikes or something more nefarious.

Monitor billing usage alerts

A billing usage alert will probably be the first sign of something other than "normal" happening inside your environment. If attackers are blending in and abusing your LLMs in a "low and slow" manner, you might not be able to pick it up.

However, most attackers will probably try to use your LLM resources as much as possible, for fear of losing access before they have been able to do what they need to do. This will inevitably trigger billing usage alerts, in which case, you should investigate and act as soon as possible.

How Do You Defend Against LLMjacking?

Defending against LLMjacking is largely about making the credentials harder to obtain in the first place. Since the attack typically relies on valid API keys rather than exploiting the model itself, traditional firewalls and other security hardware do not really feature here. Instead, effective defense relies on a combination of strong credential management, tight access controls, and continuous visibility into how those credentials are being used across your systems.

Enforce good credential hygiene

This is one of the most effective ways to limit the impact of an LLMjacking incident. It reduces the window of opportunity an attacker has if one of your keys is exposed. Regularly rotating API keys ensures that any leaked credentials have a limited lifespan.

Workload-specific keys add another important layer of containment. Instead of one shared credential granting broad access across multiple services, each application, service, or environment gets its own narrowly scoped identity. This should make abuse much easier to detect and isolate, since unusual usage can be traced back to a specific workload rather than blending into general traffic.

Workload-specific keys also have the added benefit of reducing the blast radius of a compromised key. These keys should only have access to specific endpoints for a specific set of operations.

Apply the principle of least privilege

Workload-specific keys are one way of achieving the principle of least privilege. Applying the principle of least privilege is really about resisting the temptation to give every integration a "just in case" level of access. If a single API key can reach multiple models, environments, or downstream systems, whoever steals it effectively inherits far more capability than that key should ever have had in the first place.

These same principles should be applied to your human users as well. Does Carol from marketing really need access to production prompts, customer data pipelines, and your fine-tuned legal summarization model? Probably not. Again, by tightly scoping permissions to specific workloads, endpoints, and even models, you ensure that a compromised key will limit the capabilities an attacker might gain from that key.

Basic security principles

Sometimes we forget that the basics can also help to protect you from LLMjacking attacks. LLMjacking is not a fancy new exploit that threatens to bring down your entire organization. The following points will help strengthen your overall security posture and help you detect and prevent LLMjacking incidents.

Use a proper secrets management platform, like Hashicorp Vault. This is especially useful for automating the rotation of workload-specific keys so as to minimize the usefulness of a compromised key.
GitHub enables push protection by default on all repositories, blocking commits containing secrets before they ever reach your codebase. Make sure it has not been disabled in your repository settings. This does not mean secrets cannot slip through. If that does happen, treat that secret as compromised and rotate it immediately.
Centralize your audit and access logs, for example, using a SIEM solution. This can help to create your initial baseline as well as monitor for anomalies, all from a centralized location. ## LLMjacking Is New; The Vulnerabilities It Exploits Are Not Resource hijacking is a familiar story to many a cybersecurity professional. Attackers steal credentials and exploit them for their own gain at the victim's expense. LLMjacking is just one of the newer chapters in that story, and one with potentially higher stakes than what came before it. With LLMjacking, attackers get the same level of access as your systems and employees. This can lead to financial harm and risks exposing your company's and customers' sensitive data.

This threat is particularly concerning because of how deeply LLMs are embedded in modern tech stacks. They are no longer isolated tools, but components that influence decisions, automate processes, and interact with data in real time.

Defending against LLMjacking does not require newfangled security mechanisms; it requires getting the basics right. Treat those API keys as high-value assets, limit their scope, and monitor their usage with intent. While the technology behind those keys is new, the weak points being exploited are well known and well understood.