Category Archives: Uncategorized

Using LLMs for KYC. What Could Go Wrong?

The title of this post uses acronyms for brevity, but the full version is “Using Large Language Models for Know Your Customer. What Could Go Wrong?”

Biometric Update links to a TrendAI post that demonstrates how the use of a large language model to analyze document data is a vulnerability to prompt attacks.

“In a real-world stack built with FastAPI, Claude Code, and a SQLite MCP backend, his team embedded malicious instructions inside a passport so that the AI agent followed them and leaked other customer records directly into the verification page.”

Google Gemini. I tried to create the image with a fake too-short onion address but Google Gemini prohibited that.

What does this mean?

“The takeaway here is that if your AI can read documents and call tools, your documents can potentially become executable attack surfaces even when guarded with strict schemas.”

Something a human wouldn’t do.

Putting the Tires Before the Purpose of Your Drive

So I had to fulfill a medical appointment and got into my car WITH TIRES, started it, and positioned THE TIRES so that I would head north, then west, toward the medical facility. Once I got to the parking lot I parked my car WITH TIRES and went inside. Less than a half hour later I exited, walked to my car WITH TIRES, and drove home. (Did I mention that my car has TIRES?)

Google Gemini.
Google Gemini.

Close to a Milestone

One of Bredemarket’s clients is microscopically close to achieving an important milestone with a major customer. As project manager I’m performing the issue tracking and am happy. It is premature to announce this customer milestone, but hopefully the day will come.

The only drawback was that a last-minute Bredemarket / client / customer call prevented me from attending Tuesday’s live iProov / Ingenium webinar on independent testing to standards such as NIST SP 800-63-4 and CEN/TS 18099. But that’s why webinars have replays.

The Bredemarket post below is not directly related to the webinar, but is tangentially related since it discusses independent testing.

iProov’s Four Questions on Independent Testing

Recent Product Marketing Posts from John E. Bredehoft at Bredemarket

I just updated Bredemarket’s product marketing information page. It doesn’t list everything I’ve written about product marketing, but it touches on a good portion of my posts.

If you haven’t kept up, here are some of the latest posts from March, April, and May of this year.

You can see the entire product marketing information page here.

On Ethics in Identity and Healthcare

I almost asked Google Gemini to perform a completely warped action.

I almost asked Gemini to write a post, in the style of Bredebot, explaining how ethics is detrimental to business.

But I didn’t write such a standalone post. Instead I asked Gemini to write a single paragraph.

While ethics is fundamentally viewed as a cornerstone of long-term brand equity, from a purely short-term, transactional perspective, it can be framed as a significant operational burden. In a hyper-competitive market, adhering to rigorous ethical standards often acts as a self-imposed “tax” that competitors may simply bypass. Strict compliance with environmental regulations, fair wage practices, and transparent sourcing can inflate overhead costs, leading to higher price points that may alienate price-sensitive consumers. Furthermore, ethical considerations can paralyze speed-to-market; while a competitor might prioritize rapid scaling through “growth hacking” or aggressive data harvesting, an ethically-bound company may lose its first-mover advantage by pausing for privacy audits or impact assessments. In this light, ethics is seen as a friction point that restricts a firm’s agility, limits immediate profit margins, and creates a strategic disadvantage against “bad actors” who prioritize raw efficiency over moral sentiment.

But even when receiving this instruction, Gemini emphasized that the advantage is “short-term” and “transactional.”

I assert that it’s especially transactional for companies that deal with private data-personally identifiable information (PII), protected health information (PHI), or its variants. Because if a company with your private data behaves unethically, you will be rightfully outraged.

Which is why companies such as Paravision and Reality Defender emphasize ethics.

Paravision in 2023:

“Whether it’s in facial recognition technology, hiring processes, or healthcare diagnostics, the consequences of biased AI can be far-reaching. Paravision heavily invests into broad and diverse training datasets to fight bias, and we must remain vigilant and ensure that AI systems are developed with fairness and equity in mind, and commit to improving the performance of AI algorithms across all demographics.”

Reality Defender in 2026:

“The committee’s job isn’t to bless what we ship, but to push back on it. This pushback includes (but is not limited to) operational questions, how we communicate uncertainty in a verdict, how we handle false positives at scale, and who has access to flagged content (and for how long).

“It also includes harder questions. What duty do we owe a worker authenticated through RealMeeting who didn’t choose to be authenticated? What happens when a regulator asks for our verdicts as evidence in a proceeding? How do we draw the line when a customer wants to use detection in a way we don’t think is appropriate?”

How does your identity or health vendor handle ethical issues? Or is a short-term and transactional benefit good enough?

The CMO’s Guide to the Invisible Gears: Version Names vs. Version Codes

Look, I’ve been in the trenches of tech marketing since before biometrics were more than a fingerprint on a scanner and identity meant more than just a username. After decades of watching products launch, pivot, and occasionally crash into the side of a mountain, I’ve noticed a recurring blind spot in the C-suite. We spend millions on the “What” and the “Why,” but we often trip over the “How”.

Today, we’re talking about something that sounds like it belongs in a basement server room: the difference between Version Names and Version Codes. If you’re a CMO at a tech firm, you might think this is “dev stuff”. It’s not. It’s the difference between a seamless MDM (Mobile Device Management) rollout and a support ticket bonfire that consumes your entire Q3 budget.

The Name is for the Humans; The Code is for the Machine

Think of the Version Name as the flashy suit your product wears to the gala. It’s “v2.4.1” or “The Phoenix Update”. It’s what we put on the landing pages, the press releases, and the App Store descriptions. It’s a string of characters meant to communicate progress and marketing hierarchy to people.

The Version Code, however, is the actual DNA. It’s an integer—a simple, positive whole number. For example, while the Version Name might be “3.0.0,” the Version Code is “42”. The machine doesn’t care about the dots or the cool names; it just looks at the number. If the new code is greater than the old code, the system recognizes an upgrade. If not, as far as the operating system is concerned, nothing happened.

Why Your MDM Strategy is Crying

Here is where the rubber hits the road for enterprise tech. Your customers aren’t just downloading your app from a couch; they are deploying it to 50,000 managed devices via an MDM provider like Jamf, Intune, or AirWatch. These systems are cold, logical, and deeply unimpressed by your branding.

If your engineering team increments the Version Name from “2.1” to “2.2” but forgets to bump the Version Code from “105” to “106,” the MDM will see “105” already exists on the device and simply stop. It won’t push the update. Your “New & Improved Identity Protocol” sits in a digital warehouse because the gatekeeper thinks it already has the latest goods. We’ve all seen marketing consultants act like wildebeests charging blindly into a river, treating their wombat-like customers as if they’ll just figure it out—but in the enterprise world, that’s a recipe for churn.

The Golden Rule: Marketing owns the Version Name (the story). Engineering owns the Version Code (the reality). If they don’t sync, your MDM deployment is DOA.

Identity and Security Implications

In the world of biometrics and secure identity—my old stomping grounds—this isn’t just a minor glitch; it’s a security risk. When you’re pushing a critical patch to a face-matching algorithm or a FIDO2 implementation, “Version Name” confusion can lead to fragmented security postures. Half your fleet is on the old code but reporting the new name. That is a nightmare for compliance audits and a playground for bad actors.

The CMO’s Checklist for Versioning

You don’t need to be a coder, but you do need to ask the right questions during the go-to-market sync:

  • Is the Version Code incremented? Ensure that every public-facing “Version Name” change is backed by a unique, higher integer in the code.
  • MDM Compatibility Testing: Did we test the deployment in a managed environment, or just on a personal iPhone?
  • Internal Alignment: Does the Product Marketing Manager know the difference? If they don’t, they can’t communicate the technical requirements to the customer’s IT admins.

At the end of the day, our job as CMOs is to build trust. Trust is built on reliability. When an enterprise customer hits “Deploy” on your software, they need to know it will actually land on the devices. Understand the invisible gears, and you’ll stop the friction before it starts.

iProov’s Four Questions on Independent Testing

I hope you’re sitting down for this…but vendors make assertions that favor themselves. Or in this case “favour,” because the vendor in question is iProov.

The English company shared four questions on independent testing of vendor claims, and I think we can all predict how iProov would answer these four questions.

But that doesn’t negate the importance of the questions.

  1. Which independent lab(s) tested the system? Not just a vendor red team, or a partner story. An accredited third party.
  2. Against which standard? ISO/IEC 30107-3, CEN/TS 18099, FIDO Face Verification, or a combination? Defending against the full attack spectrum matters.
  3. At what level? Substantial, High? If the level isn’t listed, be sure to ask why.
  4. When? Standards evolve. Threat models evolve faster. Certifications can age quickly.

Yes, you can claim that customer testing is more important than independent testing.

And some have claimed that independent testing is flawed because it doesn’t test properly. (One semi-related example: because FBI EBTS Appendix F assumes that the fingerprints contact the capture surface, it is useless for contactless solutions. The powers that be are working on an alternative.)

But if your solution doesn’t have independent test or conformance results, you’d better have a good reason.

Your Personal Cybersecurity Diagnostic

I’ve deprioritized Substack and therefore don’t see Erich Winkler’s posts any more, but I do receive his Decoded Security emails.

And a recent one announced a quiz.

“Most people drift through cybersecurity without a clear direction.

“They watch random YouTube videos. They start certifications they never finish. They burn months going nowhere.

“Sound familiar?

“It is called the Cybersecurity Path Finder.

“A 60-second diagnostic that gives you a personalized reading list from the Decoded Security archive based on your background, your goals, and where you are right now.”

You can take the quiz yourself at https://quiz.decodedsecurity.com/