As the complexity of microelectronics accelerates across commercial and government systems, security assurance and trust is becoming a defining requirement rather than a secondary consideration. This complexity growth has also expanded the role of third-party intellectual property (3PIP) used in today's chip designs allowing for a faster, more scalable path to complex system design. To fully realize these benefits, system developers need a standardized, repeatable process that improves visibility into 3PIP design and behavior. This visibility is critical to hardware security, helping teams detect misconfigurations, unintended access paths, and other vulnerabilities that can emerge when third-party IP becomes part of the full system. Security does not automatically carry across combined components, making system-level security practices essential. As a result, design teams are shifting to an executable, robust, and end-to-end structure that ensures performance gains do not come at the expense of security.
The adoption and openness of the RISC-V instruction set architecture has driven innovation, flexibility, and rapid ecosystem growth. This has put a larger emphasis on adopting standardized tools and approaches to ensure the functionality and security of RISC-V designs are complete and correct especially in safety critical systems.
Defining a Systematic Approach
To support this shift, Cycuity, recently acquired by Arteris, has developed a four-step security assurance methodology, recognizing that a structured and repeatable framework is needed to evaluate and verify third-party IP at scale.
- Scope inclusion: Identify relevant Common Weakness Enumeration (CWE) categories from the MITRE-maintained database for IP under review.
- Security requirements: Translate identified weaknesses into concrete, design-specific security requirements.
- Verification development: Create security properties and corresponding tests to validate those requirements.
- Evidence collection: Gather artifacts to support, document, and validate the results.
Most of the engineering effort is concentrated in Steps 3 and 4, where security requirements are implemented as security properties and rules, tests are executed in the security analysis environment, and the resulting evidence is reviewed, collected, and archived. This process establishes hardware security as a structured verification workflow supported by repeatable artifacts.
Figure 1. CWE Security Assurance Evidence Tree. Source: Arteris, Inc.
Rather than treating verification as a single effort, the methodology is designed to scale across the third-party ecosystem. Reusable security properties in the form of security rule templates, reduce non-recurring engineering costs while maintaining flexibility for different implementations. Scope definitions can be reused, requirements standardized, and both properties and tests made portable, enabling consistency across designs while formalizing the process. For example, pairing a template rule with a portable C-based test that can run with any RISC-V processor with minimal modifications ensures that security intent is validated through both formal analysis and execution-based testing.
Producing Traceable Results
A central part of this approach is the use of formalized security rule templates that translate requirements into machine-checkable logic directly on the register transfer level (RTL) source code. These rules can be adapted to specific implementations through configurable parameters, allowing the same underlying structure to be applied across multiple designs.
Equally important is the focus on evidence, or the data generated during verification that supports security results. This evidence includes structured artifacts such as rule evaluations, test outputs, and coverage data, each providing traceable support for the reported security outcome. By grounding results in reviewable evidence, the process ensures that security findings are not only produced but can also be assessed and interpreted with confidence.
This method leverages multiple verification techniques depending on the type of security concerns being evaluated. Rule-based analysis and testing form the core, serving as the primary methods for verifying how a design behaves and enforces security requirements. Static analysis is used where appropriate to examine issues such as register initialization directly in the design. Traditional simulation-based verification can also be used for functional use cases. This flexibility improves security coverage and ensures that each type of risk is addressed using the most effective method.
The approach also helps bridge the gap between hardware design teams and system-level stakeholders. Organizing results into clear, standardized outputs enables integrators, auditors, and program managers to understand the security posture of an IP block without requiring deep access to the underlying design. That transparency is especially important when third-party IP is incorporated into a larger system.
Over time, this structure enables organizations to build a growing body of reusable knowledge. As more designs are evaluated, patterns emerge, templates improve, and verification cycles become faster and more predictable. The result is not just stronger individual designs, but a more mature and scalable model for establishing trust in third-party processor IP.
Conclusion
With third-party IP gaining momentum, the need for hardware security practices is only increasing. Designs demand tools that can translate security requirements into measurable, verifiable outcomes. This is where the hardware security assurance products from Arteris, play a critical role.
Cycuity Radix enables the creation and execution of formalized security rules that map directly to design behavior. This allows engineers to verify how data moves through a system and whether it aligns with defined security requirements. By combining rule-based analysis with executable tests, the product provides a practical way to validate security intent across different implementations while maintaining consistency and reuse. Cycuity Radix-ST extends this capability through static analysis, examining RTL directly to identify issues such as improper initialization or unintended behavior without requiring simulation. Together, these capabilities provide both dynamic and static visibility into design security.
Engineers gain earlier insight into potential risks, reduce manual effort through reusable templates and automation, and produce structured evidence that supports confident decision-making. As organizations increasingly rely on third-party IP, these tools help move hardware security from reactive analysis to a proactive, structured process that improves confidence in system integrity without sacrificing security trust.
Read the whitepaper here.
About the author
Mark Labbato is a Staff Security Engineer at Arteris (formerly Cycuity). He helps develop and implement solutions for customers with a focus on security assurance methodologies. He has 15 years of experience in the microelectronics space spanning from applications engineering, new product development, verification, research, and most recently trust and assurance.