Security by Design for AI-Enabled Defense Systems: Lessons from Cross-Border Technology Development
International technology firms entering the U.S. defense ecosystem should treat cybersecurity as an architectural property, not a compliance task to be added after the product is built.
By John Keenan, CISSP
Capability is only half the design problem
Emerging defense technologies are naturally conceived around capability: what a system can enable, how it can improve human performance, and how artificial intelligence can connect devices and information into something more useful.
My advisory work with an international company exploring an AI-enabled exoskeleton concept reinforced a second design problem: how early should cybersecurity enter the conversation?
The answer is earlier than many product teams expect.
The observations here are intentionally generalized. They disclose no proprietary architecture and do not represent official Department of Defense guidance. My role has been to bring a cybersecurity practitioner's perspective to early discussions about how an international technology company should think about security while exploring the U.S. defense market.
The lesson is broader than any one product. Security decisions made during concept development can determine whether later security requirements are straightforward engineering work or expensive architectural rework.
Connectivity changes the threat model
Consider the difference between a largely mechanical device and an AI-enabled system that exchanges information with sensors, applications, communications systems, cloud services, or other intelligent devices. Connectivity can create enormous operational value. It also creates trust relationships.
Which components authenticate to one another? What happens if communications are degraded or denied? Which functions must remain available locally? What data does the system collect from the operator or environment? How are software and model updates authenticated? What dependencies come from third-party components? Could compromise of an AI component affect physical behavior or decision support?
Those questions belong in architecture discussions before a customer asks them.
NIST's 2025 adversarial machine learning taxonomy is useful here because it expands the threat vocabulary beyond ordinary software exploitation. Evasion, poisoning, privacy, and misuse attacks illustrate ways adversaries may target the behavior or information of AI systems. The point is not that every AI-enabled defense product faces every attack. It is that AI introduces attack surfaces that should be considered explicitly.
Secure by design is a development posture
CISA and the UK National Cyber Security Centre's Guidelines for Secure AI System Development organize recommendations around secure design, secure development, secure deployment, and secure operation. That lifecycle framing matters.
A team that waits until deployment to ask security questions may discover that its identity model, update mechanism, logging architecture, cloud dependency, data handling, or component choices are difficult to change. A team that asks those questions during design retains more options.
Secure by design does not mean predicting every future requirement. An international startup may not know which U.S. government customer, program, contract vehicle, or operating environment will ultimately apply. It can still document architecture, identify trust boundaries, control changes, maintain component provenance, consider degraded modes, and assign responsibility for security decisions.
Cross-border development adds a human trust boundary
The international dimension adds another risk: institutional language.
Terms such as authorization, risk acceptance, zero trust, mission assurance, supply-chain risk, and secure by design carry assumptions shaped by the environments in which professionals learned them. A technically correct translation may not communicate those assumptions.
Much of my advisory discussion has taken place in Spanish. That experience has reinforced that cybersecurity communication is not simply vocabulary substitution. Sometimes the important work is explaining why a U.S. defense customer may ask a question, what kind of risk the question is trying to expose, and why an early design choice could matter later.
That does not make the advisor an accrediting authority. It makes communication part of risk reduction.
Build for scrutiny before scrutiny arrives
A company cannot guarantee acceptance into the U.S. defense market by adopting a cybersecurity framework. Nor should security be treated as a marketing badge.
The more useful objective is architectural readiness for scrutiny.
Can the company explain its data flows? Can it identify software and hardware dependencies? Can it show how updates are controlled? Can it describe trust boundaries and failure modes? Can it explain what AI components do and where they obtain data? Can it separate an engineering fact from an assumption? Can it document why a risk decision was made?
NIST's AI RMF and CISA/NCSC secure-AI guidance both support lifecycle thinking. They provide useful public foundations for companies that need to build security habits before customer-specific requirements become known.
For an international firm entering a security-conscious market, that may be the most important early shift: stop asking when cybersecurity certification begins and start asking when cybersecurity design begins. The latter begins with the product.