A little over two years ago, someone told me that the idea we had at Internet Security Auditors was impossible: a PAN scanner that would run on every system we could imagine, with the technical ability to search for data in any object a system holds, and with 100% of the functionality on every system, all the way to a powerful GUI for managing findings that could grow into finding tagging, remediation and more.
Turning impossible things into reality is thrilling, and this era makes it more possible than ever.
Behind it lie a year and a half of continuous development, more than twenty releases and hundreds of intermediate builds. The product is tested in our own lab of more than thirty machines, against a corpus of thousands of files designed to break the scanner, and with full scans of real machines. And it no longer stays in the lab: the proofs of concept and the exercises at the customers where it is being used are delivering good results. What follows is what that journey has left us.
Being present on those systems is not enough if you arrive with a cut-down version. The challenge was to arrive with everything: the same engines, the same interface and the same report as on a Windows laptop. And building for them takes a different craft: different architectures, compilers and toolchains specific to each platform, libraries that are not always packaged for them, and test machines you cannot get with a click.
CardExpose Scanner ships as a native binary for fifteen combinations of operating system and architecture. The latest to join are OpenVMS on x86-64 and z/OS on IBM Z.
Linux compatibility: Any distribution from the RHEL and Oracle Linux 7 generation onward.
The important word is “binary”. Each platform receives a single executable that you copy and run, with all its engines inside, including the OCR models and the content classifier's signature database. There is no installer, no runtime, and no dependencies to resolve. And it runs in standalone mode on every platform, with no installation of any kind and no need for the Agent or the Console. For a production server with a change-control policy, that is the difference between being able to audit it tomorrow and being able to audit it next quarter.
The price of that decision is that the project's technical bar is set by what all of them have in common. Every line of code has to compile and behave the same across fifteen combinations of system, architecture and compiler, and not only on the latest version of each system, but on the ones customers actually run in production.
The first uncomfortable lesson came early: building in fifteen places does not guarantee the same product in fifteen places. A library at the same version on every platform can be built with different capabilities on one of them, and a version inventory will not show it. Since then, each binary's capabilities are not declared: they are verified on the binary itself, platform by platform, and each platform's software bill of materials (SBOM) is checked against what actually ships inside.
The graphical interface travelled with the rest. The same binary works as a command line on a server with no graphical environment and opens a window on a workstation that has one, also on AIX and Solaris SPARC, and on IBM i, OpenVMS and z/OS through an X server with X11 forwarding. On big-endian architectures, such as IBM Z, SPARC or Power, we had to solve details that no x86 machine ever reveals. It is the kind of work that separates “it compiles” from “it looks right”.
The latest to arrive, OpenVMS on x86-64, is a milestone for a different reason. It is neither a Unix nor a Linux: it has its own file system, its own command interpreter and its own conventions, and its x86-64 version is still young. Even so, what runs there comes from the same code revision as every other platform. It was also the first destination on our roadmap to stop being a plan and become reality.
z/OS, on IBM Z, is the other milestone, and the one that weighs most for the financial sector. It is the reference operating system of banking, the one that carries a large part of the core banking and payment-processing workloads. Until now we reached IBM Z through Linux; now the scanner runs on z/OS itself, with its own file system, its data sets and its native EBCDIC, and it comes from the same code revision as every other platform.
The first decision that makes it possible is not to trust the file extension. Each object is classified by its content at the moment it is opened, with a signature database that ships inside the binary, and that classification decides which engine analyzes it. A .bak that is really a ZIP is opened as a ZIP. A file with no extension that is an email message is analyzed as email. A .dat that is a SQLite database is read table by table.
The regular-expression engine behind that classification is guaranteed linear-time and is the same on all fifteen platforms. The same file is classified the same way on AIX as on Windows, and no content, however pathological, can degrade classification to exponential time: ReDoS attacks are ruled out by design.
The second decision is that classification is applied at every level, not just the first. Let's follow one object. An email inside a PST contains a ZIP; the ZIP contains a docx; the docx has an embedded screenshot showing a card. The scanner extracts the message, classifies the attachment, opens the ZIP, recognizes the docx as an office document and not as a raw ZIP, extracts its text, finds the image and runs it through OCR.
Each member goes to its engine, down to a configurable depth, and the final finding knows where it came from: invoices.pst::Inbox/msg1!/attachment.zip!/contract.docx. Protection against decompression bombs does not depend on size on disk: a small ZIP that expands to tens of gigabytes is stopped by what it decompresses, not by what it occupies.
With that foundation, widening the surface was a matter of adding engines, and each has its own nuance. PDF is processed along three axes so that OCR is not paid for where it is not needed: native text always, OCR of embedded images, and rasterization of the full page only when it holds no substantial text. Local databases (SQLite, dBASE and FoxPro, Access from version 97 to the current one, including protected MDB files, and MongoDB dumps) are read cell by cell, and a binary cell that contains a PDF is analyzed as a PDF.
Remote databases (SQL Server, MySQL, PostgreSQL, Oracle, DB2, Firebird, MongoDB and Redis) are opened read-only. The scan refuses to start if the user has write permissions, unless expressly authorized, and on SQL Server it avoids locking the production tables being audited.
EBCDIC code pages: CP037 · CP273 · CP277 · CP278 · CP280 · CP284 · CP285 · CP297 · CP500 · CP870 · CP1047
Images go through OCR, through barcode and QR decoding, and through a metadata reader that searches EXIF, XMP and comments without decoding a single pixel. Audio goes through a DTMF tone detector, because that is where a PAN keyed into an IVR ends up. Executables are analyzed by their data regions, without interpreting machine code as text. And the encodings include eleven EBCDIC code pages and COMP-3 packed decimals, which is how COBOL stores a card number in a record.
Then there is what is no longer a file. Disk images and virtual disks (EnCase E01, VMDK, VHD, VHDX, VDI, raw images, and OVA, OVF and vbox containers) are opened without privileges and walked from the inside, recognizing the usual file systems: NTFS, FAT and exFAT, ext2/3/4, UFS, HFS+. Each file found keeps its provenance, along the lines of image.e01::part0/Documents/file.txt.
On the live system, with elevation, the scanner recovers deleted files by reading the file system's metadata table, carves embedded files out of raw data, analyzes the Windows, macOS and Linux recycle bins recovering the original name and deletion date, and inspects NTFS Alternate Data Streams. Shadow copies are enumerated and scanned on Windows, macOS, ZFS, btrfs, LVM and AIX, with an EDR-friendly mode enabled by default. A scanner that sets off the customer's EDR is not a useful scanner.
On IBM i the concept of “object” means something else, and the scanner respects it. Besides the integrated file system, it reads physical-file members, SAVFs (including SAVFs inside SAVFs), data areas, message queues, output-queue spool, journal receivers and user spaces. And, optionally, the object's metadata: description text, member text, column headings and spool user data.
OpenVMS x86-64 also plays by its own rules, and the scanner respects them just as it does those of IBM i: it is not a Unix under another name. Arriving there with the same engines as on every other platform, and not with a cut-down version, was part of the challenge.
z/OS likewise has its own rules, and the scanner respects them too. Neither is it a Unix under another name: alongside its Unix file system live native data sets, and the EBCDIC encoding and COMP-3 packed decimals we mentioned earlier are everyday business here.
A scan like this reads, by definition, content that nobody has validated: corrupt, truncated or outright hostile files. And some of the libraries that interpret complex formats, faced with such input, do not return an error: they kill the process.
For that, the scanner relies on several layers of protection that work together and are always on, with no configuration. A hostile file does not bring the scan down: it is set aside, documented, and the walk goes on. An interruption does not lose the work done: the scan continues where it left off. A huge file that advances slowly is not mistaken for a stuck one. And resource consumption adapts to the machine it runs on, so that auditing a production server does not put it at risk.
The file-system walk follows the same principle. A directory without permissions, a link that loops, or a network mount that does not respond are declared, and do not stop or falsify the rest. This matters more than it seems: a walk that stops at the first directory without permissions can end “successfully” having looked at a fraction of the disk. A scanner that returns “all good” having looked at a fraction is worse than none.
Reasons for not analyzing: quarantine · encrypted · corrupt · permissions · size · unsupported
Hence the accounting rule that closes every scan. What was declared at the start is reconciled with what was analyzed, what could not be analyzed and what was filtered, and the sum has to add up. If it does not, a coverage gap is recorded. The report classifies each omission by its reason, including BitLocker or LUKS volumes and password-protected ZIPs, which are detected and declared. There are no silent omissions.
Having their source code is what made the first impossible possible. Where no package exists for AIX, for SPARC or for IBM i, it is built from source, with the same revision and the same capabilities as on the rest of the platforms. Without that code, this product would not have reached those platforms whole.
Open-source libraries inside the product: 70+; Vulnerabilities identified in their code: 50+.
And it also let us give something back. A PAN scanner opens, by definition, content that nobody has validated, so we audit the code of the libraries we integrate with the same rigor as our own. In that process we identified more than 50 vulnerabilities across some twenty projects. We have documented them and are passing them to their maintainers through coordinated disclosure, so that the fix reaches everyone who uses that code, not just us.
We do not detail them here. Each one will be made public once its project has had the chance to fix it.
Built-in brands: Visa · Mastercard · Amex · Discover · JCB · Diners · Maestro · UnionPay · and custom rules
The search tolerates the separators and encodings with which a card number appears in practice, and discards fragments of longer numbers. What survives passes the Luhn algorithm and each brand's rules.
For each finding a severity is computed that takes into account the brand, the surrounding context (an expiry date, a CVV or a cardholder nearby), the file type and where it sits. A number inside a data table or a binary drops in priority, but it is still delivered. All of that classifies; none of it discards.
Test cards documented by the brands are segregated, not discarded. A 4242 4242 4242 4242 is detected, flagged, counted separately and labeled as a test card. Hiding them from the listing is a presentation option; the scan total does not change. The same contract applies to the analyst's triage: findings marked as false positives in the GUI are kept, and the full report and the triaged view of the same scan remain comparable. The PAN comes out masked by default, also within the context that surrounds it.
That is how we built our test corpus: thousands of files grouped into families, from text in every encoding to office documents, PDF, email, databases, images, handwriting, audio, binaries, nested containers, disk images and IBM i objects. Most come from a reproducible generator that plants the numbers and keeps a record of each one. That record is the ground truth, and it is never derived from what the scanner itself finds. Measuring yourself against your own output is measuring yourself against yourself.
Each file type has at least three variants: one with cards, which measures detection; another without them, which measures false positives; and a damaged one, which measures whether the scanner survives. On top of that come the extreme cases a scanner rarely sees in a demo: deeply nested containers, impossible nestings that the scanner has to cut off without losing control, numbers that look like cards and are not, and real files from production environments.
With that corpus we put CardExpose up against another widely used commercial scanner, on the same files and the same ground truth.
The other scanner found half. CardExpose, almost nine out of ten. And for every file that only the other tool saw, CardExpose found more than twenty that it did not.
That was the moment we knew we had achieved something very powerful. Not so much because of the difference as because of where it was: CardExpose won in every file family except handwriting, where neither reaches, and in audio the other tool found nothing.
And the corpus was not used just once. It grows with every new format, it is run on every platform, and releases are also closed with full scans of real machines. A result is only worth something if it is the same on every platform and holds from one version to the next.
From the journal come the reports in HTML, JSON, PDF and CSV, regenerable at any time without scanning again, and the events to Splunk, syslog or CEF, through which only the masked PAN travels.
Everything, command line, interface and reports, speaks six languages: Spanish, English, German, French, Italian and Portuguese.
The Agent is a resident service that launches the scanner, collects its progress and findings as they appear, and delivers them to the Console over an encrypted, authenticated channel. It stores what is pending if it loses connectivity, updates itself, and can discover the network from where it sits.
The Console is the central management. It automatically deploys and updates the agents and the scanner on the hosts, also in air-gapped environments. It discovers the assets to be audited, including those that live in the cloud. It schedules scans with policies per asset group, collects the results from each host and consolidates them into a central findings repository, always with the PAN masked. All this for multiple organizations in a single installation, with roles and per-asset scopes, and with an audit log that allows no modification or deletion.
The License Server closes the circle. The license is validated locally, offline and with no demo mode, and is bound both to the machine it was issued for and to the binary delivered to each customer.
Turning impossible things into reality is thrilling, and this era makes it more possible than ever.
The result is not just that it turned out to be possible: it turned out to be incredibly better.
When someone tells you something is impossible, it pays to ask which part exactly. Here the answer had three parts, and each was impossible for a different reason. This article tells how each one came apart, and what it means for anyone who has to find an organization's cardholder data.Behind it lie a year and a half of continuous development, more than twenty releases and hundreds of intermediate builds. The product is tested in our own lab of more than thirty machines, against a corpus of thousands of files designed to break the scanner, and with full scans of real machines. And it no longer stays in the lab: the proofs of concept and the exercises at the customers where it is being used are delivering good results. What follows is what that journey has left us.
Impossible 1 of 3: Every system
Cardholder data piles up wherever payments are processed, and many organizations process them on platforms that are neither Windows nor Linux on x86: AIX on Power, Solaris on SPARC, IBM i, OpenVMS, z/OS, Linux on IBM Z. These are living platforms, with recent versions and in full production, and they carry some of the most critical systems of a bank or a payment processor.Being present on those systems is not enough if you arrive with a cut-down version. The challenge was to arrive with everything: the same engines, the same interface and the same report as on a Windows laptop. And building for them takes a different craft: different architectures, compilers and toolchains specific to each platform, libraries that are not always packaged for them, and test machines you cannot get with a click.
CardExpose Scanner ships as a native binary for fifteen combinations of operating system and architecture. The latest to join are OpenVMS on x86-64 and z/OS on IBM Z.
Linux compatibility: Any distribution from the RHEL and Oracle Linux 7 generation onward.
The important word is “binary”. Each platform receives a single executable that you copy and run, with all its engines inside, including the OCR models and the content classifier's signature database. There is no installer, no runtime, and no dependencies to resolve. And it runs in standalone mode on every platform, with no installation of any kind and no need for the Agent or the Console. For a production server with a change-control policy, that is the difference between being able to audit it tomorrow and being able to audit it next quarter.
The price of that decision is that the project's technical bar is set by what all of them have in common. Every line of code has to compile and behave the same across fifteen combinations of system, architecture and compiler, and not only on the latest version of each system, but on the ones customers actually run in production.
The first uncomfortable lesson came early: building in fifteen places does not guarantee the same product in fifteen places. A library at the same version on every platform can be built with different capabilities on one of them, and a version inventory will not show it. Since then, each binary's capabilities are not declared: they are verified on the binary itself, platform by platform, and each platform's software bill of materials (SBOM) is checked against what actually ships inside.
The graphical interface travelled with the rest. The same binary works as a command line on a server with no graphical environment and opens a window on a workstation that has one, also on AIX and Solaris SPARC, and on IBM i, OpenVMS and z/OS through an X server with X11 forwarding. On big-endian architectures, such as IBM Z, SPARC or Power, we had to solve details that no x86 machine ever reveals. It is the kind of work that separates “it compiles” from “it looks right”.
The latest to arrive, OpenVMS on x86-64, is a milestone for a different reason. It is neither a Unix nor a Linux: it has its own file system, its own command interpreter and its own conventions, and its x86-64 version is still young. Even so, what runs there comes from the same code revision as every other platform. It was also the first destination on our roadmap to stop being a plan and become reality.
z/OS, on IBM Z, is the other milestone, and the one that weighs most for the financial sector. It is the reference operating system of banking, the one that carries a large part of the core banking and payment-processing workloads. Until now we reached IBM Z through Linux; now the scanner runs on z/OS itself, with its own file system, its data sets and its native EBCDIC, and it comes from the same code revision as every other platform.
Impossible 2 of 3: Any object
A PAN is not a string in a text file. It is a BLOB cell in a database, an attachment inside a PST, a scanned PDF that contains only images, the recording of an IVR call where the customer keyed in their card, a deleted file of which only the inode remains, a shadow copy from three months ago, a physical-file member in EBCDIC, or a virtual disk forgotten in a backup. If the scanner does not reach there, the audit certifies what it has not looked at.The first decision that makes it possible is not to trust the file extension. Each object is classified by its content at the moment it is opened, with a signature database that ships inside the binary, and that classification decides which engine analyzes it. A .bak that is really a ZIP is opened as a ZIP. A file with no extension that is an email message is analyzed as email. A .dat that is a SQLite database is read table by table.
The regular-expression engine behind that classification is guaranteed linear-time and is the same on all fifteen platforms. The same file is classified the same way on AIX as on Windows, and no content, however pathological, can degrade classification to exponential time: ReDoS attacks are ruled out by design.
The second decision is that classification is applied at every level, not just the first. Let's follow one object. An email inside a PST contains a ZIP; the ZIP contains a docx; the docx has an embedded screenshot showing a card. The scanner extracts the message, classifies the attachment, opens the ZIP, recognizes the docx as an office document and not as a raw ZIP, extracts its text, finds the image and runs it through OCR.
Each member goes to its engine, down to a configurable depth, and the final finding knows where it came from: invoices.pst::Inbox/msg1!/attachment.zip!/contract.docx. Protection against decompression bombs does not depend on size on disk: a small ZIP that expands to tens of gigabytes is stopped by what it decompresses, not by what it occupies.
With that foundation, widening the surface was a matter of adding engines, and each has its own nuance. PDF is processed along three axes so that OCR is not paid for where it is not needed: native text always, OCR of embedded images, and rasterization of the full page only when it holds no substantial text. Local databases (SQLite, dBASE and FoxPro, Access from version 97 to the current one, including protected MDB files, and MongoDB dumps) are read cell by cell, and a binary cell that contains a PDF is analyzed as a PDF.
Remote databases (SQL Server, MySQL, PostgreSQL, Oracle, DB2, Firebird, MongoDB and Redis) are opened read-only. The scan refuses to start if the user has write permissions, unless expressly authorized, and on SQL Server it avoids locking the production tables being audited.
EBCDIC code pages: CP037 · CP273 · CP277 · CP278 · CP280 · CP284 · CP285 · CP297 · CP500 · CP870 · CP1047
Images go through OCR, through barcode and QR decoding, and through a metadata reader that searches EXIF, XMP and comments without decoding a single pixel. Audio goes through a DTMF tone detector, because that is where a PAN keyed into an IVR ends up. Executables are analyzed by their data regions, without interpreting machine code as text. And the encodings include eleven EBCDIC code pages and COMP-3 packed decimals, which is how COBOL stores a card number in a record.
Then there is what is no longer a file. Disk images and virtual disks (EnCase E01, VMDK, VHD, VHDX, VDI, raw images, and OVA, OVF and vbox containers) are opened without privileges and walked from the inside, recognizing the usual file systems: NTFS, FAT and exFAT, ext2/3/4, UFS, HFS+. Each file found keeps its provenance, along the lines of image.e01::part0/Documents/file.txt.
On the live system, with elevation, the scanner recovers deleted files by reading the file system's metadata table, carves embedded files out of raw data, analyzes the Windows, macOS and Linux recycle bins recovering the original name and deletion date, and inspects NTFS Alternate Data Streams. Shadow copies are enumerated and scanned on Windows, macOS, ZFS, btrfs, LVM and AIX, with an EDR-friendly mode enabled by default. A scanner that sets off the customer's EDR is not a useful scanner.
On IBM i the concept of “object” means something else, and the scanner respects it. Besides the integrated file system, it reads physical-file members, SAVFs (including SAVFs inside SAVFs), data areas, message queues, output-queue spool, journal receivers and user spaces. And, optionally, the object's metadata: description text, member text, column headings and spool user data.
OpenVMS x86-64 also plays by its own rules, and the scanner respects them just as it does those of IBM i: it is not a Unix under another name. Arriving there with the same engines as on every other platform, and not with a cut-down version, was part of the challenge.
z/OS likewise has its own rules, and the scanner respects them too. Neither is it a Unix under another name: alongside its Unix file system live native data sets, and the EBCDIC encoding and COMP-3 packed decimals we mentioned earlier are everyday business here.
Impossible 3 of 3: 100% of everything, on every system, and reliable
Having the same functions on fifteen platforms is a necessary condition. The sufficient one is that a scan over terabytes of untrusted content finishes and tells the truth about what it has covered. This turned out to be the real impossible one, and the one that taught us the most.A scan like this reads, by definition, content that nobody has validated: corrupt, truncated or outright hostile files. And some of the libraries that interpret complex formats, faced with such input, do not return an error: they kill the process.
For that, the scanner relies on several layers of protection that work together and are always on, with no configuration. A hostile file does not bring the scan down: it is set aside, documented, and the walk goes on. An interruption does not lose the work done: the scan continues where it left off. A huge file that advances slowly is not mistaken for a stuck one. And resource consumption adapts to the machine it runs on, so that auditing a production server does not put it at risk.
The file-system walk follows the same principle. A directory without permissions, a link that loops, or a network mount that does not respond are declared, and do not stop or falsify the rest. This matters more than it seems: a walk that stops at the first directory without permissions can end “successfully” having looked at a fraction of the disk. A scanner that returns “all good” having looked at a fraction is worse than none.
Reasons for not analyzing: quarantine · encrypted · corrupt · permissions · size · unsupported
Hence the accounting rule that closes every scan. What was declared at the start is reconciled with what was analyzed, what could not be analyzed and what was filtered, and the sum has to add up. If it does not, a coverage gap is recorded. The report classifies each omission by its reason, including BitLocker or LUKS volumes and password-protected ZIPs, which are detected and declared. There are no silent omissions.
What we owe to open source
There is a part of this story that is not ours. The engines that read PDF, images, audio, office documents, compressed archives, email, databases and forensic file systems rest on dozens of open-source libraries, maintained for years by communities that are often made up of very few people.Having their source code is what made the first impossible possible. Where no package exists for AIX, for SPARC or for IBM i, it is built from source, with the same revision and the same capabilities as on the rest of the platforms. Without that code, this product would not have reached those platforms whole.
Open-source libraries inside the product: 70+; Vulnerabilities identified in their code: 50+.
And it also let us give something back. A PAN scanner opens, by definition, content that nobody has validated, so we audit the code of the libraries we integrate with the same rigor as our own. In that process we identified more than 50 vulnerabilities across some twenty projects. We have documented them and are passing them to their maintainers through coordinated disclosure, so that the fix reaches everyone who uses that code, not just us.
We do not detail them here. Each one will be made public once its project has had the chance to fix it.
What is a finding, and what is not
With all that surface, the obvious risk is drowning the analyst. The answer was not to filter more, but to classify better and never discard.Built-in brands: Visa · Mastercard · Amex · Discover · JCB · Diners · Maestro · UnionPay · and custom rules
The search tolerates the separators and encodings with which a card number appears in practice, and discards fragments of longer numbers. What survives passes the Luhn algorithm and each brand's rules.
For each finding a severity is computed that takes into account the brand, the surrounding context (an expiry date, a CVV or a cardholder nearby), the file type and where it sits. A number inside a data table or a binary drops in priority, but it is still delivered. All of that classifies; none of it discards.
A false positive costs one click in review. A false negative is a card nobody will ever see again.Magnetic stripes are detected by structure, not by pattern. Track 1 and Track 2, per ISO/IEC 7813, require the complete track: the already-validated PAN attached to its sentinel and the expiry date in its position. For PCI DSS, track data is Sensitive Authentication Data, which may never be stored after authorization, and for that reason it receives the maximum severity and its own flag in the report.
Test cards documented by the brands are segregated, not discarded. A 4242 4242 4242 4242 is detected, flagged, counted separately and labeled as a test card. Hiding them from the listing is a presentation option; the scan total does not change. The same contract applies to the analyst's triage: findings marked as false positives in the GUI are kept, and the full report and the triaged view of the same scan remain comparable. The PAN comes out masked by default, also within the context that surrounds it.
How we knew it was better
A PAN scanner cannot be evaluated with a customer's data, because nobody knows how many cards are in it. To measure it you need the opposite: a set of files where every card has been placed on purpose and you know exactly where it is.That is how we built our test corpus: thousands of files grouped into families, from text in every encoding to office documents, PDF, email, databases, images, handwriting, audio, binaries, nested containers, disk images and IBM i objects. Most come from a reproducible generator that plants the numbers and keeps a record of each one. That record is the ground truth, and it is never derived from what the scanner itself finds. Measuring yourself against your own output is measuring yourself against yourself.
Each file type has at least three variants: one with cards, which measures detection; another without them, which measures false positives; and a damaged one, which measures whether the scanner survives. On top of that come the extreme cases a scanner rarely sees in a demo: deeply nested containers, impossible nestings that the scanner has to cut off without losing control, numbers that look like cards and are not, and real files from production environments.
With that corpus we put CardExpose up against another widely used commercial scanner, on the same files and the same ground truth.
The other scanner found half. CardExpose, almost nine out of ten. And for every file that only the other tool saw, CardExpose found more than twenty that it did not.
That was the moment we knew we had achieved something very powerful. Not so much because of the difference as because of where it was: CardExpose won in every file family except handwriting, where neither reaches, and in audio the other tool found nothing.
And the corpus was not used just once. It grows with every new format, it is run on every platform, and releases are also closed with full scans of real machines. A result is only worth something if it is the same on every platform and holds from one version to the next.
The evidence
Everything above ends up in the scan journal: an encrypted record bound to the license and to the machine where the scan was run. If the scan is interrupted, it resumes from there without repeating what was already done.From the journal come the reports in HTML, JSON, PDF and CSV, regenerable at any time without scanning again, and the events to Splunk, syslog or CEF, through which only the masked PAN travels.
Everything, command line, interface and reports, speaks six languages: Spanish, English, German, French, Italian and Portuguese.
The Suite
The scanner is deliberately simple in its relationship with the world: it is not a resident service and exposes no network interface. It validates its license, scans, writes the journal and the report, and exits. Everything else is done by three more components, and the scanner works with or without them: in standalone mode, the binary and its license are all it takes.The Agent is a resident service that launches the scanner, collects its progress and findings as they appear, and delivers them to the Console over an encrypted, authenticated channel. It stores what is pending if it loses connectivity, updates itself, and can discover the network from where it sits.
The Console is the central management. It automatically deploys and updates the agents and the scanner on the hosts, also in air-gapped environments. It discovers the assets to be audited, including those that live in the cloud. It schedules scans with policies per asset group, collects the results from each host and consolidates them into a central findings repository, always with the PAN masked. All this for multiple organizations in a single installation, with roles and per-asset scopes, and with an audit log that allows no modification or deletion.
The License Server closes the circle. The license is validated locally, offline and with no demo mode, and is bound both to the machine it was issued for and to the binary delivered to each customer.
What is still growing
The original idea spoke of reaching every imaginable system and of a GUI that could grow toward finding tagging, remediation and other functions. Finding triage is already part of the scanner; this is what is coming.
[Roadmap] More systems: HPE NonStop and Stratus VOS
Taking the same code to AIX, to Solaris on SPARC, to IBM i, to IBM Z, to OpenVMS and now to z/OS without giving up any function taught us something more valuable than the list of platforms itself: the code is truly portable. It has compiled and behaved the same on big-endian architectures, with different compilers and in environments with their own rules, such as those of IBM i, OpenVMS or z/OS.
That is the road we are following, and OpenVMS and z/OS have already confirmed it. The next destinations are HPE NonStop and Stratus VOS, platforms that run first-tier payment systems, and where finding out where the cardholder data is matters as much as anywhere else. The goal is the same as ever: the complete product, not a cut-down version.
And a special thank-you to the manufacturers who have collaborated with us on the port to their respective platforms. Arriving with the whole product on systems with their own rules is not done without their help.
[In design · 2027] Remediation
With one decision already made: it will run only from graphical environments, with a recovery copy and an auditable record of every action, and with no command-line option. A scanner that deletes data in production with a flag is an incident waiting to happen.
It will be available during 2027, both in the Scanner's graphical interface and through the Console, so that whoever manages the findings of an entire organization can remediate them from the same place where they review them.
[In testing · Q4 2026] CEIA, CardExpose's artificial intelligence
A full scan of a server can return more than a million findings, and nobody reviews a million of anything. In our tests, CEIA turns a scan of more than a million findings into a little over a thousand cases that deserve real analysis. It is the difference between an impossible review and one that fits in the calendar. And for a customer who scans every week, that saving repeats every week: time is money.
Everything happens inside the customer's network: the model runs on their own machines and not a single piece of data leaves it. CEIA also widens what can be found: it adds reading of handwritten text, exactly where no scanner we have measured reaches today, and of card numbers dictated aloud in recordings. It is already in testing, where it classifies better than the deterministic rules we use today, and it will be available in the last quarter of 2026.
Whoever said “impossible” was not wrong about the difficulty. They were wrong about the method. None of the above came from a brilliant architecture idea. It came from measuring every capability on every machine, from measuring ourselves against a ground truth that did not depend on us, from treating every omission as a gap that must be declared, from leaning on the work of the community and giving back what we found, and from refusing to let “it works on Windows” be a synonym for “it works”.
The result is a binary that you copy to an AIX, a Solaris SPARC, an IBM i, an OpenVMS or a z/OS machine, and it finds the same PAN, with the same provenance and the same report, as on a Windows 11 laptop. And the list of systems is not finished yet.
That is what has been incredibly better.
