SBOM and Cyber Resilience Act readiness for manufacturers

Between Japan and the world

I have spent more than 25 years in the IT industry, working in a variety of roles, including software development, project management, sales, and corporate planning. Throughout my career, I have been involved not only in software but also in hardware and product development for manufacturers.

In 2016, I began focusing on software development in Southeast Asia, particularly Vietnam, and started collaborating with engineers overseas. In 2019, I expanded those partnerships to Ukraine, which gave me firsthand exposure to European software development practices, approaches, and working cultures.

Even today, connecting international technology and talent with Japanese companies remains at the heart of my work. This year alone, I have already made 14 international trips. But traveling abroad is not just about business meetings or gathering technical information.

I enjoy walking through local neighborhoods, experiencing everyday life, sharing meals, and learning about the history, culture, and values of the countries I visit. I consider these experiences an important part of my work.

You can learn a great deal about technology and business practices from documents and research. But understanding what people truly value, how they think, and how they approach their work and daily lives often requires being there in person.

To build a bridge between Japan and the rest of the world, I believe you must first understand the people and cultures on both sides.

For me, these experiences form the foundation of trust and meaningful relationships across borders.

Meeting the CRA

It was through this international work that I encountered the EU Cyber Resilience Act (CRA).

When I first learned about the CRA, I immediately felt that it could become a major challenge — even a serious threat — to Japanese manufacturers.

Japan has a long tradition of excellent engineering, manufacturing, and quality control. However, Japanese manufacturers also have a culture of keeping products in service for many years, maintaining legacy development environments, and supporting established product designs.

The CRA introduces a different set of expectations, particularly around continuously managing software components, vulnerabilities, and cybersecurity throughout a product's lifecycle.

I saw a significant gap between these new regulatory requirements and traditional Japanese product development practices.

And this is not something companies can solve simply by adding a few cybersecurity measures. It can require changes to development processes, maintenance policies, responsibilities across departments, and even management decisions.

That realization led me to my current work: helping Japanese manufacturers understand what the CRA means for their actual products and operations, and working with them to develop practical ways to meet its requirements.

A typical week

A typical week involves meetings with engineers and management teams at manufacturing companies, reviewing product risk assessments and gap analyses, discussing technical and regulatory issues with European specialists, and helping establish practical processes for SBOM management and vulnerability handling.

I also spend time researching international cyber threats and regulatory developments, which I share through my own publication, Hisashi Takano's Cybersecurity Watch, primarily for Japanese business leaders and manufacturers.

What matters most to me is translating the language of law and engineering into something that business leaders — especially executives without technical backgrounds — can understand.

Simply explaining legal provisions does not necessarily help executives understand what decisions they need to make. And filling a presentation with technical terminology does not tell a company where to begin.

For manufacturers dealing with products that have been on the market for many years, or development environments that cannot easily be replaced, imposing ideal solutions without understanding their circumstances rarely leads to meaningful progress.

I believe we need to understand each company's products, technology, people, budget, and corporate culture before deciding what can realistically be done.

My role is to help them identify where to start, what decisions need to be made, and who should take responsibility.

Connecting Japan with the world, and connecting technology with business leadership.

That has been the central theme of my career, and it is the role I want to continue playing in the fields of CRA and SBOM.

Knowledge in people's heads

From my experience working with Japanese manufacturers, I have found that many companies initially see SBOM and Cyber Resilience Act (CRA) compliance as something for their engineering departments to handle.

But once they begin working on it, much deeper challenges emerge.

In Japanese manufacturing, there is a tendency to see completing a product and bringing it to market as the finish line.

Of course, Japan has world-class engineering capabilities and a strong tradition of manufacturing excellence. Many engineers take enormous personal responsibility and pride in the products they create.

However, that same craftsmanship-driven culture can sometimes become a weakness.

"If you want to know about this product, just ask that engineer."

"He's been responsible for it for years. He knows everything."

When this way of thinking becomes established, critical technical knowledge and the reasons behind design decisions are often stored in individuals' heads rather than in company records.

And when those engineers retire or move to another department, companies may suddenly discover that nobody knows why certain design decisions were made, which software components were used, or what changes were introduced over the years.

The product still exists, but the people who can explain it — and the documentation needed to understand it — may no longer be there.

This creates a serious challenge for CRA readiness.

Departments that are not connected

Another issue I frequently encounter is the disconnect between sales, engineering, quality assurance, and administrative or management departments.

The sales team knows which products were sold and in which countries. Engineers understand the software and components inside those products. Quality assurance teams manage defects, modifications, and product histories.

But that information is not always connected across the organization.

For example, a manufacturer may have sold a product in the EU years ago, but it may now be difficult to determine which versions are still in use, who is responsible for maintaining them, or who would make the decision if a vulnerability were discovered.

No single department may have the complete picture.

The CRA introduces expectations that go beyond bringing a product to market. Manufacturers must be able to understand their software components, monitor vulnerabilities, and maintain appropriate cybersecurity processes throughout the relevant product lifecycle.

In other words, launching a product is no longer the finish line. Manufacturers must also understand and protect their products after release.

Gap analyses and SBOMs in practice

I have seen this challenge firsthand.

While working with a Japanese manufacturing client on a CRA gap analysis, concerns emerged that certain product-specific specifications and functions might not have been fully reflected in the assessment.

Even when external specialists understand the regulatory requirements, they cannot easily know every technical detail of a product that has evolved through years of development and modifications.

That is why I believe gap analyses should not simply be treated as final reports. They need to be validated together with the engineers who understand the actual products.

SBOM presents a similar challenge.

It is easy to tell a manufacturer, "You need to create a list of all the software components in your product."

But in practice, manufacturers may be dealing with legacy development environments, proprietary build processes, long-established software components, and incomplete information about third-party libraries.

One client told me very directly:

"Creating an SBOM manually every time we develop or update software is simply not realistic."

I think that is an extremely important point.

Rather than imposing idealized technical solutions or regulatory checklists, we need to understand how the manufacturer actually develops its products.

What information already exists? What can be reused? At what point in the development or release process should an SBOM be generated? How much can realistically be automated?

These are questions we need to explore together with the people doing the work.

A task for the whole company

And ultimately, CRA readiness cannot be achieved by engineers alone.

How long should a product be supported? How should legacy products be managed? Who decides whether a vulnerability must be reported? Which products should continue to be placed on the EU market?

These decisions require cooperation between engineering, sales, quality assurance, administrative departments, and senior management.

One of the messages I consistently share with manufacturers is that the CRA is not simply another cybersecurity regulation. It is also an opportunity to rethink how the entire company takes responsibility for its products.

What I believe many Japanese manufacturers underestimate is not just the technical difficulty of creating an SBOM.

It is the challenge of transforming a manufacturing culture that has traditionally relied heavily on individual expertise and personal responsibility into one where product knowledge is documented, shared across departments, and continuously managed by the organization.

Creating an SBOM once is one thing. Building a company that can keep its SBOMs accurate and up to date is much harder — and far more important.

Understanding the other side

Over the years, through my work and experiences abroad, one of the most important lessons I have learned is how much it matters to communicate in a way that truly connects with the person in front of you.

I have spent many years in the IT industry, working with people in engineering, sales, project management, and corporate planning. I have also had the opportunity to work with people from different cultures and backgrounds, particularly in countries such as Vietnam and Ukraine.

What I gradually came to understand is that people's perspectives are not determined simply by their nationality or culture.

Even within the same country, or the same company, people see things differently depending on their roles, experiences, responsibilities, and personal circumstances.

An engineer might look at a technical problem and ask, "How can we make this work?" A business executive might be thinking, "How much will this cost, and what impact will it have on our business?" Someone in sales may be worried about how to explain the situation to customers.

None of them is necessarily wrong. They are simply looking at the same problem from different positions, each trying to fulfill their own responsibilities.

Earlier in my career, I sometimes believed that if I explained something accurately and logically, people would naturally understand.

But experience taught me something different.

Explaining something correctly and actually getting your message across are not always the same thing.

Today, before explaining something, I try to understand the other person's position. What do they already know? What are they concerned about? What are they really trying to achieve?

When discussing complicated regulations or technical subjects, I try not to rely on specialist terminology. Instead, I look for words and examples that make sense in their everyday work.

And when someone sees things differently from me, I try not to reject their opinion immediately. I want to understand why they see things that way.

Between European specialists and Japanese engineers

This approach has become particularly important in my current work with the EU Cyber Resilience Act (CRA).

European specialists naturally approach the CRA from legal and technical perspectives. Japanese manufacturers, on the other hand, have their own development practices, quality standards, and ways of working that have evolved over many years.

Some of these practices cannot be changed overnight.

I see my role as helping both sides understand each other and finding practical solutions, rather than simply insisting that one side adopt the other's approach.

One experience with a Japanese manufacturing client reinforced this lesson.

We were working on CRA readiness with European specialists. The proposed approach made sense from a regulatory and technical perspective, but parts of it were difficult to apply in the client's actual development environment.

The company had legacy systems, established engineering processes, and practical limitations that were not immediately obvious to people outside the organization.

The answer was not to argue about who was right.

We first needed to listen to the Japanese engineers, understand what was difficult and why, and then explain those circumstances to the European specialists.

Only then could we begin looking for an approach that was both compliant and realistic.

That experience reminded me that when you work between different people, companies, and cultures, technical knowledge alone is not enough.

The willingness to understand others is just as important.

Learning from ordinary moments

There is another lesson I have learned from traveling and working internationally.

The world is much bigger than the one we see in our everyday lives.

Something that seems completely normal in Japan may be viewed very differently elsewhere. Even the same event can mean different things to people depending on their country's history, culture, circumstances, and personal experiences.

Whenever I travel abroad, I try to do more than attend meetings or visit offices.

I like walking through local neighborhoods, talking with people, trying everyday food, and observing how people actually live.

A country's identity is not found only in its impressive office buildings or international conferences.

It is also found in the people working at local markets, families eating together, and young engineers talking about their ambitions and worries.

I often learn just as much from these ordinary moments as I do from formal business meetings.

And interestingly, the more I experience different cultures, the more I also rediscover what is good about Japan.

Why cyberattacks are never only technical

This is also one of the reasons I spend so much time researching and writing about cybersecurity and international affairs.

Cyberattacks are not simply technical incidents involving computers and networks.

Behind them, there may be geopolitical tensions, economic interests, historical conflicts, political objectives, and very human motivations.

Why would one country target another country's critical infrastructure? Why are companies' technologies and intellectual property stolen? Why can something happening thousands of kilometers away eventually affect businesses and everyday life in Japan?

When I investigate a cybersecurity incident, I often find that the technical details are only the beginning of a much larger story.

They can reveal something about how countries compete, how societies function, and how closely connected our world has become.

That is why I do not want to simply report that a cyberattack happened somewhere.

I want to explore why it happened, what may be behind it, what we actually know, and how it might relate to people living in Japan.

Making complicated technical subjects understandable to people without technical backgrounds is an important part of that work.

It is also why I continue publishing Hisashi Takano's Cybersecurity Watch.

More than anything, I want people to discover just how much there is to learn about the world.

There are so many events we know little about, so many different ways of thinking, and so many possibilities we have never imagined.

Learning about them can make us question our assumptions and look at familiar problems from completely different angles.

And you do not necessarily have to travel overseas to experience that.

Reading an article, listening to someone from a different background, or becoming curious about something happening in a distant country can be enough to open a new window on the world.

I still have so much to learn myself.

That is why I want to keep traveling, meeting people, listening to their stories, and discovering things I never knew before.

The lesson in one sentence

If I had to summarize what these experiences have taught me, it would be this:

Try to understand the person in front of you, and never assume that your own view of the world is the only one.

And if I can use what I have learned to help people in Japan become a little more curious about the wider world, then I feel I am doing something worthwhile.

That is what I can contribute, and what I hope to keep doing for many years to come.

The real issue is data quality

I don't think there is anything wrong with manufacturers using Excel to manage their component information.

Many Japanese manufacturers have relied on Excel and spreadsheets for years. They are familiar, flexible, and often fit naturally into the way people work.

The real issue is not which tool a company uses. It is whether the information is accurate, up to date, and connected to the product that was actually built and shipped.

For example, a manufacturer may have a detailed parts list in Excel. But does it describe the product being sold today? Is it from three years ago? Or does it represent a special configuration developed for a particular customer?

If nobody can answer those questions, that spreadsheet cannot be considered a reliable starting point for an SBOM.

There is also an important difference between a hardware bill of materials and a software bill of materials.

Japanese manufacturers are often very disciplined when it comes to managing physical components. But information about embedded software, third-party libraries, and software dependencies may be scattered across development teams or maintained by individual engineers.

Where automation and AI help

This is where I believe automation and AI can make a real difference.

AI can help bring together information from different documents, identify inconsistent component names, compare software versions, and highlight missing information. It can also examine existing design documents and development records to identify software components that need further investigation.

Where the development environment allows it, SBOM generation can also be integrated into the build or release process.

A practical workflow

Let me give you a practical example of how I think this could work.

A manufacturer might begin with the component information it already has in Excel, together with existing design documents, source code records, and build information.

AI could help organize those records, identify inconsistent names, and highlight missing details such as software versions or supplier information.

The next step would be to compare that information with the actual development environment, dependency records, and build outputs.

This is important because a component mentioned in an old document is not necessarily included in the product being released today.

Engineers would then review the findings, confirm which components are actually present, and resolve any uncertainties.

Once the information has been verified, the company could generate an SBOM in a standard format such as SPDX or CycloneDX and link it to the relevant product version and release.

When a new release is prepared, automated tools could compare the latest component information with the previous release, identify changes, and flag anything that requires human review.

AI could also help identify newly published vulnerabilities associated with those components, although engineers would still need to determine whether the vulnerabilities actually affect the product.

In other words, the process could move from existing spreadsheets and development records to automated checks, human verification, SBOM generation, and ongoing vulnerability monitoring.

I think this is a much more realistic approach than asking engineers to manually recreate an entire SBOM every time something changes.

Rather than immediately recommending a new tool, I believe we should first understand how the manufacturer actually works.

What development environment do they use? How is the software built? How are releases managed? What information do they already have?

Only after understanding those things can we decide what should be automated and what still requires human judgment.

The new risks

Of course, AI also introduces new risks.

The biggest concern is that AI-generated information is not necessarily correct.

Imagine an AI system reading an old design document and concluding that a particular software library is included in a product. That does not prove the library is actually present in the current release.

The opposite is equally important. Just because AI cannot identify a component does not mean it is absent.

If those assumptions are added to an official SBOM without verification, a manufacturer could overlook a real vulnerability or waste time investigating one that does not actually affect the product.

Confidentiality is another concern.

Source code, design documents, and product configurations often contain valuable intellectual property. Sharing that information with an external AI service without understanding how the data will be handled could create additional security risks.

Deciding whether a vulnerability actually affects a product requires an understanding of its implementation, configuration, and operating environment.

AI can support that decision, but it cannot take responsibility on behalf of the manufacturer.

Back to the spreadsheet?

There is another development I find particularly interesting.

I think AI may eventually bring some companies back to Excel and spreadsheets.

For years, businesses have been encouraged to move information out of spreadsheets and into dedicated systems or SaaS platforms.

But if AI can help organize data, compare versions, convert formats, and connect information from different sources, companies may not need a specialized platform for every business process.

Imagine a manufacturer using AI to organize its existing component records, identify missing information, and produce a standardized SBOM from verified data.

Instead of replacing its entire information management process, the company could improve what it already has.

I also believe AI could reduce the value of certain SaaS products.

Services that mainly organize data, generate reports, or convert information between formats may find it increasingly difficult to justify their value as standalone products.

That doesn't mean I think SaaS will disappear.

Access controls, audit trails, data integrity, secure integrations, and reliable version management will remain important. Dedicated platforms can still provide significant value in those areas.

But I wouldn't rule out the possibility that AI could make Excel and spreadsheets far more useful than we once imagined.

There is an important distinction here, though.

Returning to spreadsheets should not mean returning to the old problems of spreadsheet management.

If only one engineer understands how the information is maintained, then nothing fundamental has changed, no matter how much AI is involved.

What I want to see is product information that is accurate, traceable, and accessible across the organization.

People keep the responsibility

When I work with manufacturers, I don't encourage them to automate everything from the beginning.

I prefer to start by looking at the information they already have, understanding where it comes from, and identifying which processes can realistically be automated.

AI-generated findings should be checked against reliable evidence, and important decisions should remain with people who understand the products.

For me, AI and automation are not about removing people from the process.

They are about reducing repetitive work so engineers can spend more time on decisions that genuinely require their knowledge and experience.

The same principle applies to SBOM management.

The goal is not to introduce an impressive new system. It is to establish a practical way for manufacturers to maintain accurate software component information over many years.

AI may change the tools we use, perhaps more dramatically than we expect.

One meeting, one question

If a manufacturer were starting its SBOM and Cyber Resilience Act (CRA) preparations next Monday, my first recommendation would be to bring the relevant people together for a small meeting that morning.

I wouldn't start by buying an SBOM tool or asking everyone to read the entire CRA regulation.

I would bring together someone from senior management, engineering, quality assurance, sales, and, where necessary, legal and procurement.

Then I would ask one simple question.

"How well do we really understand the products we develop and sell?"

It sounds like an easy question, but in my experience, many companies find it surprisingly difficult to answer.

The sales team knows which products have been sold and in which countries. Engineers know what software is inside those products. Quality assurance teams have information about defects, modifications, and product histories.

But that information is not always connected.

So the first task is to bring together what the company already knows.

Which products have been placed on the EU market? Are they still being sold? Which products have been discontinued? What versions exist? Who is responsible for them today? And if a vulnerability is discovered, who receives that information and decides what to do?

These are the questions I would start with.

Start with what you already know

I also don't think a company needs to investigate every product on the first day.

Choose one representative product and bring together the information held by sales, engineering, and quality assurance.

Even that simple exercise can reveal a great deal about what the company knows and, perhaps more importantly, what it doesn't know.

I would also encourage manufacturers to make use of the information they already have.

Excel parts lists, old design documents, development records, release histories, and quality management records may contain valuable information.

Before introducing new systems, it makes sense to understand what can be achieved with those existing resources.

The same principle applies to SBOM.

Rather than beginning with the question, "How do we create an SBOM?" I would first ask, "How much do we actually know about the software inside this product?"

How is the software built? How are third-party libraries managed? Can the company connect a particular software configuration to a specific product version?

Once those questions are answered, it becomes much easier to decide what tools or automation methods are appropriate.

Listen to the engineers

I have seen the importance of this firsthand.

In one CRA readiness project with a Japanese manufacturer, concerns were raised that some product-specific specifications and functions might not have been fully reflected in the initial gap analysis.

We therefore placed greater emphasis on reviewing the assessment together with the engineers who understood the actual products.

That experience reinforced something I consider very important.

Even the most knowledgeable external specialist cannot recommend the right approach without understanding how the product actually works.

That is why I always encourage companies to listen carefully to their engineers, especially in the early stages.

There is another point I would emphasize to management.

CRA readiness is not something you can simply hand over to the engineering department with the instruction, "Please take care of this."

Decisions about product support periods, necessary modifications, staffing, budgets, and whether certain products should continue to be placed on the EU market all require management involvement.

So I would make sure that the first meeting also identifies a person who will take overall responsibility for the project.

Two CRA dates, two tasks

There is also an important distinction in the CRA timeline that manufacturers need to understand.

The Article 14 reporting obligations have already applied since 11 September 2026. These obligations can also apply to products that were placed on the EU market before December 2027, including older products.

This means manufacturers need to know which products they have placed on the EU market, who is responsible for them today, and who will handle reports of actively exploited vulnerabilities or severe incidents affecting product security.

The broader CRA cybersecurity requirements generally become applicable on 11 December 2027.

For products newly placed on the EU market from that date, manufacturers will need to demonstrate compliance with the applicable requirements, even if the product model itself has been sold for many years.

However, individual products already placed on the EU market before that date are generally covered by transitional provisions, unless they undergo a substantial modification from 11 December 2027 onward.

So I encourage manufacturers to think about two separate tasks.

First, identify the existing and legacy products that may already fall within the Article 14 reporting obligations.

Second, identify the products they plan to place on the EU market from December 2027 onward and prepare those products for the broader CRA requirements.

These are related responsibilities, but they are not the same project.

And importantly, manufacturers should not wait until 2027 to establish their Article 14 reporting processes. Those obligations are already in effect.

A good start

I don't believe a company needs to solve everything on its first Monday.

In fact, if that first meeting helps everyone understand what the company does not yet know, I would consider it a very good start.

The important thing is not to hide those gaps, but to make them visible and bring the right people together to address them.

That is how a sustainable CRA compliance process begins.

There is one final message I would like to share with business leaders.

The CRA is not just about complying with another European regulation.

It is also an opportunity to rethink how a company manages its products, moving away from relying on individual knowledge and personal responsibility toward a system where information is shared, documented, and maintained across the organization.

You don't need a perfect SBOM on day one. You don't need an impressive new management platform either.

Start by understanding your own products.

Then bring the people inside your company together.

If I were starting next Monday, that is exactly where I would begin.