Here is a habit we see in good engineering teams more than in bad ones. They buy or build a capable piece of technology, and then they describe the technology as if it were the outcome. Three examples, each from a client that was technically strong.
A signed token is not possession
A challenger bank launched a corporate API: account data, transfers, webhooks. Every request carried a token signed with the client’s private key, bound to a certificate the bank’s own authority had issued at onboarding, plus a shared secret and a hash of the request. Onboarding itself required the mobile app’s two-factor login. Good cryptography, carefully done.
The bank’s question, in writing: does this count as strong customer authentication under PSD2? The answer took three versions and a close reading of the regulatory technical standards, and it was no. Knowledge was met, by the onboarding secret. Independence of the factors was met. Possession was not. A private key file can be copied freely, and an IP allow-list does not bind it to a person. The regulation puts the duty to prevent copying on the bank, not on the customer. There was no dynamic link to the amount and the payee either.
The design was comparable to the dedicated corporate protocols the regulator accepts under the exemption for professional users, and that is where it landed. But “comparable to an exempted protocol” is a very different sentence from “strong customer authentication”, and it would have been cheaper to know which one you were building before launch.
A scanner is not vulnerability management
A manufacturing group with twenty plants bought a vulnerability scanner after a year of intrusions. The proof of concept put nine hundred agents on sixteen sites and produced, for the first time, a count. Several of the reference policies we have reviewed for payments companies make the same distinction, and it is the right one: scanning is a tool, vulnerability management is a process with owners, risk analysis and deadlines.
The scanner told the group it had about two hundred vulnerabilities per workstation. It did not tell anyone who was responsible for the number going down, by when, or what happened when a site missed the deadline. Those were written afterwards: a group policy, timelines by severity, an exception process with compensating controls. The scanner’s dashboard looked the same before and after. The control only existed after.
The scanner’s dashboard looked the same before and after. The control only existed after.
A web application firewall is not a patched website
The same group’s corporate website, running on a content management system several versions out of date, was quietly turned into a relay for pirated sports broadcasts. A search for the company’s name showed “this site may be hacked” next to the result. The web agency offered ten days of work with no commitment to a result. A second agency found that upgrading would break the site.
So a web application firewall went in front of it. It stopped the abuse. It was also, and everyone involved knew it, a way of not fixing the website. A firewall in front of unpatched software is a control against the attacks it knows about, for as long as someone maintains it. The vulnerability is still there, and so is the lesson: the marketing site had no owner in security, and DNS sat with a third provider who took days to make a change.
What people get wrong
They let the tool name the control. “We have MFA” means a product is installed, not that every path into the environment goes through it. “We have a SIEM” means logs are collected, not that anyone reads them. The processor we assessed for 3DS had a content security policy on its pages. It allowed inline scripts, which removes most of the point of having one.
They evaluate the technology instead of the claim. The bank’s cryptography was sound. The question was never “is this secure?” but “does this meet a specific regulatory definition?”, and those are answered differently.