Chapter Five — Warnings, Prevention, and Traceable Security

Documented
Back to The Need to Prevent Counterfeiting

From “Be Careful” to Building a Route That Defends Trust

A shop window carries a notice: “Beware of counterfeit goods.”

The warning is large, complete with an exclamation mark, perhaps with pictures of genuine and counterfeit products side by side. The buyer reads it, nods, and enters. A few minutes later, they face a product with good packaging, a confident seller, and a price slightly below the market rate.

What exactly should they do now?

Open the package? Scan the code? Contact the union? Walk away? Or simply pay while feeling a little more anxious than before?

A warning disconnected from a specific action, a way to check, and a means to report produces anxiety more than prevention. It is like a sign beside a hole that merely says “Be careful.” If someone falls in, at least they cannot say nobody warned them: the sign has discharged its administrative duty.

Counterfeiting prevention does not end with “be careful.” It begins there.

This section is not intended to design an anti-counterfeiting system down to its last technical detail. Its purpose is to identify the components without which no defensible prevention system is complete: warnings, risk assessment, authentication, identifiers, traceability, reporting, response, and the division of responsibility.

Later, in the “Implementation” section, these components will move from concepts to operations: from assessing risk and selecting security layers to identifier design, data management, access control, verification, reporting, incident response, performance indicators, and periodic review.

Here we read the map. There we will follow the route step by step.

Warnings, Prevention, and Follow-Up Are Three Different Things

In everyday language, these terms are sometimes used interchangeably. An awareness campaign is called a “prevention program,” a printed code an “authenticity system,” and an unanswered phone number a “follow-up route.”

But the differences are fundamental.

A warning awakens attention. It says there is a risk and we should pause.

Prevention changes conditions so that deception becomes harder, more expensive, or less profitable.

Follow-up provides the trail needed for examination, response, and responsibility once doubt arises or a violation occurs.

These address three different moments in a risk. A warning should draw attention before a decision or at the point of encounter. Prevention should block part of the counterfeiter's route before the deception succeeds. Follow-up should ensure that doubts or violations do not end without a trace.

A system containing only one is incomplete. Warnings without prevention make people anxious; prevention without follow-up goes silent after its first failure; and follow-up without warnings usually begins when the damage has already traveled a significant part of its course.

Trustworthy security must address all three moments.

What Does a Good Warning Look Like?

A good warning does more than name the risk. It gives the recipient four answers:

  • What exactly is the risk?
  • Which sign should attract their attention?
  • What can they do at that moment?
  • If doubt remains, to which authority should they report it?

“Do not buy counterfeit goods” is about as useful as “Do not make the wrong decision.” People do not deliberately go shopping for a counterfeit. The problem is that, at the moment of decision, deception appears as an opportunity, discount, credible packaging, or seller's recommendation.

A warning must move from generalities to real situations. For medicine, official channels and avoiding unknown sellers matter. For gold, seller identity, invoice, fineness, weight, and the ability to return for follow-up are decisive. For documents, issuer name, number, date, and verification route must be checked. For technical products, the absence of a genuine warranty or an unusual price may justify pausing.

Of course, no sign alone is a verdict of counterfeiting. A low price may have a valid explanation, different packaging is not necessarily counterfeit, and a temporary system outage does not always indicate deception. A warning should not hand its recipient a judge's gavel. It should give them a reason to stop and examine.

There is a gap between “suspicious” and “counterfeit” that must be crossed with evidence.

Prevention Begins with Understanding Risk, Not with Tools

A common mistake is to choose an anti-counterfeiting tool first and then try to connect it to the problem. Holograms have been bought, so they must go somewhere on the product. A QR code is ready, so every package needs one. A system has been built, so customers must somehow learn to use it.

The right question works the other way around: what might be counterfeited, and why would an attacker target it?

ISO 22380 begins at this point too. The standard was developed by the international technical committee ISO/TC 292 on security and resilience. ISO is an international, nongovernmental organization, with experts participating through member countries' national standards bodies. ISO 22380 is therefore neither a country's law nor a security company's instruction, but voluntary guidance for analyzing product fraud risk. It asks organizations to understand types of fraud, potential perpetrators, and material and immaterial losses before designing proportionate measures.[1]

The importance of this approach lies in its apparent simplicity. Before deciding on a code type, hologram color, or printing technology, we must know the attacker's objective, available resources, points of access to goods or data, and the consequences of system failure.

A solution suited to preventing complete packaging imitation may be useless against reuse of genuine packaging. A unique code registered in a system, if easily detached from one product and placed on another, identifies the label more than the product. A system that detects external counterfeiting may be vulnerable to an employee with internal access.

Without understanding the attacker, a security tool merely fights shadows.

A Protection Plan, Rather Than Scattered Purchases of Tools

Understanding risk must become a plan.

ISO 22384, also developed by the international committee ISO/TC 292, concerns designing, implementing, and monitoring a “product protection plan.” It asks organizations to consider threats, risks, and countermeasures alongside the product life cycle, supply chain, production, data management, costs, and brand reputation, and to assess the plan's effectiveness after implementation.[2]

This matters because security does not end at installation.

A hologram difficult to imitate today may be commonplace and inexpensive in a few years. A code suitable for a limited number of products may become a weakness as production grows. A system buyers once used easily may become confusing after an interface change. Attackers do not stand still either: they observe market behavior and new tools, and change their approach.

A protection plan must remain alive. It must know what has failed, which reports recur, and where in the chain fraudsters benefit.

Anti-counterfeiting is not a project inaugurated by cutting a system's ribbon and then left untouched until the anniversary ceremony.

The “Implementation” section will examine the practical details of designing and executing such a plan, from forming a responsible team to assessing attack scenarios, controlling changes, and conducting periodic reviews. Here, we should retain one principle: tools without a plan produce fragmented security.

Layered Architecture: Because No Feature Is Invincible

Professional security is usually not built on one feature. Several layers with different functions work together, not to make packaging busier or technology more expensive, but to prevent one layer's failure from bringing down the whole system.

One layer may be visible to ordinary buyers: packaging, seals, seller details, or a verifiable code.

Another may serve sellers, inspectors, or the distribution chain: batch information, movement records, access restrictions, or controls on identifier quantities.

A third may require laboratory or expert examination: covert features, material composition, technical tests, or forensic analysis.

Each audience needs information and tools suited to its role. Consumers should not need a laboratory to buy medicine, just as specialist inspectors should not rely only on what was designed for the buyer's eye.

The mistake comes when the public-facing layer is presented as the entirety of security. The hologram is visible, so everything must be secure. The QR code responds, so there are no questions left. The package is unopened, so the contents must be what they should be.

The cotton-stuffed champion of anti-counterfeiting has an easy life in a single-layer architecture. Imitating one uniform is enough to play the entire army.

Authentication: A Question That Needs a Credible Answer

Authentication means examining whether a product, document, or data really is what it claims to be. This can involve observation, scanning, data matching, physical features, or specialist testing. But a tool is useful only when its answer can be interpreted and defended.

ISO 22383 was developed for selecting and evaluating authentication solutions for material goods. Rather than prescribe a particular technology, it emphasizes performance criteria and considers goods, components, and associated data throughout the life cycle. It also states that authentication elements should be chosen after assessing counterfeiting risk.[3]

The order matters: risk first, solution second.

Authentication must establish who will conduct the examination, in what setting, with which tools, and when. A solution suitable for a laboratory expert may be useless to a customer in a pharmacy queue. A code readable only by special software is more a catalog feature than a practical tool if sellers and inspectors do not have that software.

The system's response must also mean something. “The code is valid” is not the same as “this product is genuine.” The code may really have been issued but then copied, reused, or attached to another item. A proper response should examine the relationship between identifier, product, status, and history as far as possible.

A system that merely confirms a number's existence may be the world's most courteous phone directory. It is not yet an authenticity expert.

Identifiers, Authentication, and Traceability Are Not the Same

Many projects confuse these three concepts.

An identifier states the name or number under which an object is represented in a system.

Authentication asks whether the object present really is the legitimate object claimed.

Traceability shows when an object passed through a stage, place, or party in the chain.

An identifier can be valid yet attached to a counterfeit. A product can be genuine without its distribution route having been recorded. A traceability system may accurately record every movement, yet if the initial data were false, all it has done is keep a disciplined record of a lie's journey.

Suppose an illegitimate part enters a warehouse with apparently orderly documents and receives a lawful identifier in the system from the outset.

After that, everything is recorded flawlessly: warehouse receipt, dispatch to the distributor, store receipt, and final sale.

The traceability system has missed not a single movement. It has simply tracked, with great precision, something that entered the system with false data from the beginning.

That is the difference between having a trail and having a trustworthy trail.

Tracing a lie does not make it true.

ISO 22378, another standard from ISO/TC 292, provides a framework for identification and authentication systems. It emphasizes managing and checking identifiers, the relationship between unique identifiers and authentication elements, validating participants, inspector access levels, and access histories. It prescribes no particular technology. Its central concern is the trustworthiness of relationships between the object, identifier, system, and those with access to it.[4]

These relationships are where many apparently modern systems are weak. A code exists, but no one knows who issued it. Data are recorded, but it is unclear who can change them. Verification takes place, but its history is not retained. Sellers have access to information that lets them change a product's status without oversight.

Complex technology does not resolve unclear responsibility. Sometimes it merely displays the ambiguity on a prettier screen.

Traceability: The Chain's Memory, Not a Certificate of Innocence

Traceability means being able to follow a product or object's movement and status through a chain: who made it, when it was handed over, which warehouse it passed through, and who received it.

GS1 is one of the organizations developing standards for identification and data exchange in supply chains. It is a global, neutral, not-for-profit organization, not a government or judicial authority. The GS1 Global Traceability Standard was developed to help organizations and industries design and implement traceability systems. It focuses on processes and data exchange between supply-chain parties, rather than a specific technology.[5]

Traceability's benefit is that it gives the chain a memory. If a product becomes suspicious, its production site, batch, distribution route, and possible recipients can be found. Recalls become more precise, the problem's entry point becomes clearer, and responsibility does not disappear between links.

Traceability alone does not guarantee authenticity, however. If an illegitimate participant enters the system, an identifier is transferred to another product, or data are manipulated at some stage, the trail may look orderly while its contents are false.

Traceability must therefore be accompanied by authentication, access control, change logging, and participant validation. A chain does not become more honest merely by becoming digital.

Neat accounts do not make an account holder honest.

What Are the Features of Traceable Security?

Traceable security can be assessed through four questions.

Does the Claim Have an Owner?

Anyone claiming that a product is genuine, a document valid, a fineness specified, or a service guaranteed must be identifiable and accountable for the claim. An ownerless claim also has no responsible party when a dispute arises.

A seller, manufacturer, document issuer, or platform must not hide behind the general name of a market, brand, or system. It must be clear which person or institution accepted the obligation.

Does the Transaction Have a Memory?

The product, amount, time, parties, identifier, and main terms must be recorded. The greater the value or risk, the more precise that memory should be.

Invoices, system records, tracking numbers, and movement histories each contribute to it. Their absence may not prove counterfeiting, but it reduces the ability to defend the transaction.

Does the Warning Lead Somewhere?

If a code is duplicated, a package appears tampered with, or a document does not match the official system, the recipient needs to know what to do. An “invalid” message without explanation or a next step may merely leave users shuttling between seller and system.

A warning must connect to reporting, examination, and response.

Does Failure Have Consequences?

When counterfeiting is detected, is the identifier blocked? Is the product recalled? Is the seller or distributor investigated? Are the data corrected? Is the reporter informed of the outcome?

Detection that changes nothing in the system's behavior produces only statistics.

Traceable security means claims have owners, transactions have memories, warnings lead somewhere, and failures do not go without consequences.

Reporting: The Missing Link in Many Systems

After spotting something suspicious, many people do not know where to turn. Some stay silent for fear of trouble, lack of confidence in the outcome, or because the transaction is of little value. Others post on social media without the information needed for examination or prevention of recurrence reaching the responsible authority.

For fraudsters, that silence is a gift.

Reporting suspicion should be simple, but simplicity does not mean lack of structure. A report should capture the minimum necessary information—product or document, seller, time, place, identifier, image, and description—and provide a tracking number. It must also be clear how the information is examined, who can access it, and how findings return to the reporter or relevant links in the chain.

In June 2026, the World Health Organization published guidance on digitally transforming reporting systems for substandard and falsified medical products. WHO headquarters' Regulation and Prequalification team prepared it for ministries of health, regulators, and national partners. It is therefore not a handbook for ordinary consumers or a general standard for every industry. Its value here lies in reporting architecture: assessing the current situation, stakeholder participation, policy coordination, defining system requirements, phased implementation, and ongoing monitoring. It also emphasizes moving from fragmented paper reporting to interoperable digital platforms with standardized, timely data.[6]

WHO's training toolkit also treats health-workforce training as a foundation of the “prevent, detect, and respond” approach. The example shows that reporting is more than placing a form on a website: it belongs to a system that must train people, examine data, and act on the findings.[7]

A reporting form that empties into a dark box is merely a digital version of the old drawer.

Where Does the Public's Role End and the System's Responsibility Begin?

Prevention discussions can be tempted to put all responsibility on the buyer: take more care, look more closely, enter the code, check the package, compare prices, get an invoice, and watch out.

These recommendations are useful, but they have limits.

People cannot test every medicine's composition, open every component's chip, or assess database security. We can expect them to buy through credible channels, take warning signs seriously, retain transaction documents, and report suspicious cases. We cannot expect their personal expertise to compensate for weak design, supervision, and accountability.

A product identifier provides a simple example. Buyers can be expected to check the code through an official source. They cannot be expected to recognize a compromised database, mass-copied identifiers, or inadequate controls over code issuance at the manufacturer.

The first is the consumer's job. The second belongs to those who design, operate, and supervise the system.

Responsibilities must be divided.

Manufacturers must understand risk and protect products and data accordingly. Sellers need a clear identity, invoices, and accountability. Platforms must clarify ownership, inventory, and complaint routes. Document issuers must enable verification and revocation. Regulators must examine reports, identify patterns, and return the findings to the market.

When all responsibility rests on buyers, the system can say after every failure, “You should have been more careful.”

That sentence costs public relations very little. For prevention, it is worth almost nothing.

Education: Making the Right Questions Normal, Not Turning Everyone into Specialists

Successful education does not turn people into laboratory experts. It makes a few good questions habitual.

Buyers understand that a code without an authoritative source is insufficient. Sellers know an accurate invoice is part of their service. Employees know an official-looking document is not necessarily official. Managers know that buying a hologram does not replace risk assessment. Examiners know that “valid code” is not the end of an investigation.

Education must differ by role. Consumers do not need the same training as inspectors, sellers, technology staff, or crisis managers. Public education should be simple, situational, and actionable. Specialist training needs greater detail on examination methods, tool limitations, data protection, and the response after detection.

Fear-driven education should also be avoided. Showing alarming examples without practical responses may attract attention briefly, but does not produce lasting behavior. The audience either becomes anxious or grows accustomed to the warnings.

An alarm that sounds needlessly every day will still be part of the building's soundscape when a fire breaks out.

What Should Prevention Measure?

An anti-counterfeiting system cannot be evaluated solely by the number of installed tools or scans.

Millions of codes may be scanned while no one knows what to do with a suspicious response. Reports may increase without a single one being resolved. Labels may be difficult to copy yet removable from packages and reusable.

For example, an organization's announcement of five million verification checks in a year tells us almost nothing, by itself, about the system's quality.

More important questions are how many checks returned suspicious results, how many were reported, how many were actually investigated, how much time elapsed between report and response, and whether unusual patterns led to changes in the system.

Five million scans may indicate widespread use. They may also mean five million presses of a button after which nothing important happens.

Measurement must return to the purpose:

  • Have opportunities for counterfeiting decreased?
  • Does detection happen earlier?
  • Are duplicate identifiers or unusual behaviors identified?
  • Do reports lead to examination and outcomes?
  • Have recalls or distribution stoppages become more precise?
  • Have sellers and manufacturers become more accountable?
  • Do users understand what the system's response means?
  • Has the attacker changed methods, and has the system recognized that change?

More detections are not always a sign of failure. Violations may have increased, but reporting and visibility may also have improved. Fewer reports are not always a sign of success either: people may have lost confidence in the outcome.

Even in anti-counterfeiting, a number without context can play the cotton-stuffed champion: its chest is covered in charts, but no one knows what it has done in the field.

Common Mistakes in Prevention

There Is a Code, but No Authoritative Source

A code is printed, but users do not know which page is official or which database supplies the answer. The counterfeiter creates a code and a page together.

The Identifier Is Valid, but the Link Is Not

The number really exists in the system, but it is attached to another product. The system confirms the number's existence, not its proper attachment.

There Is a Report, but No Response

A form is completed, but there is no tracking number, response time, or clear outcome. The reporter will not make the effort a second time.

There Are Tools, but No Process Owner

Technology staff launched the system, production attached the labels, and public relations promoted it. But no unit is responsible for the final result.

There Is Education, but Responsibility Has Been Passed On

People are told to take care, while sellers, manufacturers, and the system are not accountable for their own ambiguities.

The Solution Stands Still While the Attacker Moves

The tool was designed once and left unchanged for years, while counterfeiting methods, sales markets, and consumer behavior have changed.

These mistakes usually arise not from missing technology, but from missing architecture, responsibility, and learning.

Prevention Means Changing the Fraudster's Calculation

Fraudsters calculate too. They weigh the cost of counterfeiting, the likelihood of detection, how far reports are followed up, and what failure will cost them.

If copying is easy, an identifier can be reused, sellers remain unidentifiable, and reports go nowhere, the calculation favors counterfeiting.

Prevention must change that calculation.

A security solution should make imitation harder. Recording and traceability should reduce the room for denial. Reporting and analysis should enable earlier detection. Legal, trade, or commercial responses should demonstrate that counterfeiting is not without cost.

The realistic goal is not to ensure that no attacker can ever counterfeit anything. That promise belongs more to advertising than security management.

The goal is to make counterfeiting harder, more expensive, more detectable, and less profitable—and, if it occurs, to stop it before it spreads.

In the “Implementation” section, this logic will become operational tools: threat scenarios, risk scoring, control selection, process ownership, event logging, response, review, and periodic testing. There we will ask more than “What is needed?” We will ask who should implement it, at which stage, with which tools, and against which indicators.

Traceable Security: Trust That Does Not Disappear in a Dispute

Many transactions look secure until a problem occurs. The seller speaks confidently, the packaging is intact, and the code returns a positive response.

Security's real value emerges when something does not fit the original account.

If authenticity is disputed, does a document remain? Can the seller be identified? Is there a verification history? Does an authority respond? Can the route of the goods and data be reconstructed? Will detecting this case help prevent similar ones?

Naive trust offers peace of mind at purchase. Defensible trust remains when a dispute arises.

Counterfeiting prevention does not mean removing trust. It means taking trust beyond appearances and connecting it to a route, a memory, responsibility, and response. The code must reach credible data. The data must have an owner and a history. Warnings must lead to action. Reports must lead to responses.

A warning says, “There may be deception.”

Prevention asks, “How can we reduce opportunities to deceive?”

Traceable security adds, “If deception occurs, what reveals it, who responds, and how do we prevent recurrence?”

Anti-counterfeiting moves beyond theater when it can answer all three questions.

The “Implementation” section is the natural continuation. There, this architecture becomes a process: defining roles and data flows, issuing and controlling identifiers, setting access levels, designing verification, reporting incidents, recalling products, analyzing patterns, and measuring effectiveness.

Here we have identified the necessary components. There we must assemble them so that they work in the real world.