JC-STAR Application Guide 2026: Prepare, Apply and Avoid Rework
For a connected-device vendor planning to sell cameras, gateways, routers, sensors or smart appliances in Japan, a JC-STAR application is becoming a practical way to demonstrate product-security readiness to buyers. The hard part is rarely the application form itself. Rework usually starts when product variants, security claims and supporting evidence do not match. This guide translates the official process into an execution plan for regional product teams. It reflects primary information published by Japan’s Information-technology Promotion Agency (IPA) and checked on 26 August 2026, with a focus on STAR-1 applications, current fees, the April 2026 application-number change, the corrected checklist, ETSI EN 303 645 evidence and the new UK and Singapore mutual-recognition routes.
Current capacity notice: On 31 July 2026, IPA said that a sharp increase in applications was causing checks to take longer than usual. IPA did not publish a standard completion time in that notice. Do not promise a label by a calculated date. Any internal preparation stages suggested below are project-management recommendations, not IPA processing times.
Treat JC-STAR acquisition as an evidence project, not a form-filling exercise
JC-STAR is Japan’s cybersecurity labelling scheme for IoT products. Under STAR-1 and STAR-2, the vendor evaluates its product against the scheme’s conformance requirements and assessment procedures, records the result in the prescribed checklist, and IPA grants a label based on that self-declaration package. “Self-declaration” does not mean “evidence-free.” A vendor must be able to explain why an answer is valid for the exact hardware, firmware and service configuration named in the application.
A defensible package aligns three layers:
- Product implementation: authentication, protected communications, secure updating, data handling and other controls work on the submitted product version.
- Published commitments and operating processes: the vulnerability-reporting channel, support period, update policy and user guidance reflect what the organisation can actually deliver.
- Application answers and evidence: every checklist conclusion can be traced to a design record, configuration, test result, operating procedure or other controlled source.
This structure also matters after approval. Firmware changes, added model numbers, a cloud migration or a revised support commitment can affect the basis of the original conclusion. A clean evidence register makes change assessment and future surveillance far more manageable.
What changed in the 2026 JC-STAR application environment
Teams using a 2025 playbook should refresh it. Several official pages and procedures changed in 2026, and locally saved forms may no longer be the right working copies.
| Date | Official update | What an applicant should do |
|---|---|---|
| 1 Jan 2026 | Mutual recognition with the UK PSTI Act began | Check whether the dedicated PSTI-compliant-product route applies |
| 22 Apr 2026 | The method for obtaining an application number changed | Use the current JC-STAR Application Number Request Form |
| 1 Jun 2026 | Mutual recognition with Singapore’s CLS began | Assess the STAR-1 / CLS Level 1 dedicated route |
| 19 Jun 2026 | IPA’s forms library was updated | Download fresh forms instead of reusing saved copies |
| 29 Jun 2026 | The STAR-1 checklist was corrected | Use “2025.05.05 version (corrected 2026.06.29)” |
| 16 Jul 2026 | The scheme-document library was updated | Recheck applicable rules, guidance and operational documents |
| 31 Jul 2026 | IPA announced that checks were taking longer than usual | Keep the approval date outside fixed launch commitments |
An updated page does not necessarily mean every document on that page changed on the same date. Record the identifier, version and effective date of each document you rely on. Before submission, compare that register with the live IPA pages again.
The current JC-STAR application workflow for STAR-1
1. Define the product and the application boundary
Start with a controlled product matrix: legal product name, commercial brand, model numbers, hardware revisions, firmware builds, companion application, cloud service, manufacturing entity and applicant. Products sold as one family are not automatically one evidence set. If variants use different chipsets, update paths, authentication methods or cloud endpoints, determine whether one assessment conclusion can genuinely cover them.
OEM and ODM arrangements deserve early attention. The applicant must be able to obtain technical evidence and answer questions even if engineering is performed by another company. Confirm disclosure rights, confidentiality arrangements, change notifications and access to test results before committing to an application boundary.
2. Freeze the official baseline for the project
Create a document register that points to the live IPA application page, scheme documentation, STAR-1 conformance requirements and assessment procedures, evaluation guidance, current forms and current checklist. As of 26 August 2026, the Japanese STAR-1 page identifies the current checklist as the 2025.05.05 version corrected on 29 June 2026. IPA also warns that forms may change and tells applicants to download the latest files each time they use them.
Use “freeze” to mean controlled working copies, not permission to ignore later updates. Recheck the live pages at the submission gate and assess any difference before sending the package.
3. Obtain the application number using the post-April process
Effective 22 April 2026, the procedure for obtaining an application number changed. Applicants are directed to a JC-STAR Application Number Request Form. Retire internal instructions that still tell staff to request a number under the previous method. Before requesting the number, align the applicant’s legal name, company number, product name and contact details so the same wording flows through all later documents.
4. Perform a gap assessment before completing the checklist
Classify each requirement as implemented, insufficiently documented, insufficiently tested, potentially not applicable, or requiring a design change. “Not applicable” is a conclusion that needs a product-specific rationale; it is not a shortcut for an inconvenient requirement.
An existing ETSI EN 303 645 report can accelerate this stage, but it needs to be mapped to the JC-STAR requirement and assessment method. The two schemes are related, not interchangeable.
5. Complete the assessment and build the evidence chain
Bring product engineering, quality, a PSIRT or security function, legal, product management and the Japanese application owner into the review. STAR-1 uses a self-conformity approach, while IPA’s materials also indicate that an applicant may ask a JC-STAR Evaluation Body or JC-STAR Verification Service Provider to conduct the assessment. External support can be useful when the company lacks prior experience, depends on an ODM, or wants an independent view across many variants.
6. Submit the current application set and pay after acceptance
IPA’s application-process page lists the principal documents as the Application Confirmation, JC-STAR Conformance Label Application, checklist for STAR-1 or STAR-2, an authorisation letter when an agent applies, and evidence of corporate status when the corporate number is not used. Incomplete documents may be returned without acceptance. IPA says the application fee is paid after the application has been accepted.
7. Manage questions, label issuance and publication controls
Nominate one coordination point for IPA questions and preserve every submitted and revised version. After label issuance, verify the published model names, registered ID, product information and support details before releasing marketing materials. The label is tied to defined product information; it should not be casually extended to an unassessed variant.
Documents are only the front end: build evidence that can be explained
The application package becomes much easier to review when each answer has an owner and a direct evidence path.
| Evidence area | Typical controlled records | Review question |
|---|---|---|
| Applicant identity | legal-entity data, company number, agency authority, contracts | Are manufacturer, seller, applicant and agent roles unambiguous? |
| Product identity | model matrix, hardware and software bill, firmware baseline | Does every evidence item cover the submitted configuration? |
| Authentication | provisioning design, credential rules, privilege model, tests | Are initial access and reset behaviour secure and reproducible? |
| Communications | data-flow diagram, protocols, TLS configuration, key lifecycle | Are device, app, cloud and maintenance paths all covered? |
| Updating | signing, verification, distribution, failure handling, test logs | Can the product reject an unauthorised or corrupted update? |
| Vulnerability handling | public contact, triage, remediation and disclosure workflow | Is the published channel monitored and operational? |
| Sensitive data | collection purpose, storage, access, deletion and logging | Do documented controls match the actual data flow? |
| User information | secure installation, configuration and support statement | Are customer instructions accurate for the shipping product? |
| Assessment | checklist, rationale, test method, results and review record | Can an independent reviewer reproduce the conclusion? |
IPA’s STAR-1 application overview says the checklist must have been prepared within 90 days before the application date. It also states that supporting documents, evaluation reports and real-device test results underpinning the checklist must be retained during the label’s validity period. This is a strong reason to reassess the release configuration rather than copy a previous product’s checklist.
A practical evidence register
An internal register should include the JC-STAR requirement ID, conclusion, rationale, evidence file, revision, repository location, author, reviewer, test device, firmware build, test date, related public URL and the changes that would trigger reassessment. This register is a TOMAS TECH project-control recommendation, not an IPA-prescribed form.
Evidence quality is more important than file quantity. A design statement that “TLS is used” may not prove endpoint validation, certificate handling or failure behaviour. A better chain joins the architecture, configured parameters, test cases and observed results for the same build.
JC-STAR application fee: what the JPY 198,000 does and does not cover
As of 26 August 2026, IPA’s fee for one standard STAR-1 conformance-label application is JPY 198,000 including tax. The applicable operational manual says that a paid application fee is not refunded, regardless of the reason. IPA’s application page also makes clear that fees paid to an Evaluation Body, Verification Service Provider or other assessment provider are not included.
| Budget line | Official position | Planning action |
|---|---|---|
| IPA application fee | JPY 198,000 incl. tax per standard STAR-1 application | Confirm application units and model grouping |
| External evaluation | Not included in the IPA fee | Obtain scope, retest and question-support quotations |
| Internal assessment | No official fixed amount | Budget engineering, QA, PSIRT, legal and language effort |
| Product remediation | Depends on identified gaps | Reserve capacity for firmware, cloud, process and document changes |
| Ongoing maintenance | Changes and post-approval procedures must be managed | Assign an owner for evidence and change control |
Avoid presenting JPY 198,000 internally as the “total certification cost.” A realistic business case separates application, assessment, remediation, programme management and ongoing maintenance. A mutual-recognition route may have a different fee and documentation set, so confirm eligibility before comparing totals.
Using ETSI EN 303 645 work in a JC-STAR application
ETSI EN 303 645 is the European standard for baseline cybersecurity of consumer IoT. It addresses topics such as vulnerability disclosure, unique credentials, software updates, protection of sensitive security parameters, secure communications, minimised attack surfaces and personal-data handling. IPA describes JC-STAR as harmonised with domestic and international references including ETSI EN 303 645 and NISTIR 8425.
However, an ETSI EN 303 645 test report or conformity statement does not itself confer a JC-STAR label. The applicant must still follow the JC-STAR procedure and answer the current checklist. Reuse existing work through a controlled crosswalk:
| Crosswalk field | What to record |
|---|---|
| JC-STAR item | Current requirement and assessment condition |
| ETSI reference | Relevant provision or recommendation |
| Product implementation | Feature, component, setting and operating assumption |
| Existing evidence | Test report, architecture, policy or conformity record |
| JC-STAR gap | Scheme-specific statement, public information or additional test |
| Approval owner | Person accountable for the final conclusion |
Do not map clause numbers in isolation. Verify that both records refer to the same firmware, configuration and service environment. IPA says JC-STAR applications must be made in Japanese and asks applicants to assign a person who understands Japanese. An English engineering report may support the evidence chain, but the Japanese application owner must be able to explain its meaning consistently.
Mutual recognition in 2026: UK PSTI and Singapore CLS
Mutual recognition can reduce duplicated work for international products. It is not permission to use a JC-STAR label automatically. Each route has defined documents and an approval process.
UK PSTI Act route
Mutual recognition with the UK’s Product Security and Telecommunications Infrastructure Act started on 1 January 2026. IPA publishes a dedicated application form and checklist for PSTI-compliant products. Its guidance says applicants are exempt from the JC-STAR checklist’s conformity checks for three PSTI-covered requirements. The remaining application review still applies.
For the opposite direction, a company seeking to demonstrate UK PSTI compliance for a JC-STAR-labelled product must submit the specified PSTI compliance application to IPA. In either direction, check that the evidence, product version, applicant and market configuration are the same.
Singapore CLS route
Mutual recognition with Singapore’s Cybersecurity Labelling Scheme began on 1 June 2026, centred on JC-STAR STAR-1 and CLS Level 1. IPA provides a dedicated form, completion guide and checklist for CLS-compliant products applying for JC-STAR. The published STAR-1 fee for this CLS-compliant-product route is JPY 140,000 including tax, compared with the standard JPY 198,000.
Holders of a JC-STAR-certified product seeking a CLS label are directed to apply through Singapore’s GoBusiness portal using “Cybersecurity Labelling Scheme for IoT (MRA).” IPA says there is no separate payment to IPA for that direction. Applicants should still verify the current Singapore requirements, scope and any local charges at the time of filing.
Choosing the route based on evidence, not the label name
| Decision | Standard JC-STAR route | Consider mutual recognition |
|---|---|---|
| Existing status | No relevant overseas conformity | Same product version has PSTI conformity or a CLS label |
| Markets | Mainly Japan | Coordinated Japan–UK or Japan–Singapore plan |
| Evidence | Build a JC-STAR evidence set | Map existing overseas evidence and close residual gaps |
| Product configuration | One Japan configuration | Confirm country builds are materially the same |
| Filing controls | Current standard forms and fee | Current dedicated forms, exemptions and fee |
A globally named model may contain country-specific firmware. Verify technical identity before assuming that mutual recognition applies to every market version.
Eight common causes of application rework
1. Following the pre-April application-number process
Remove old request instructions from shared folders and link the team to the live IPA STAR-1 page. Add an explicit official-page recheck to the submission checklist.
2. Using an uncorrected checklist
The current Japanese page identifies “2025.05.05 version (corrected 2026.06.29).” Check the version inside the workbook, not only its filename. Preserve the exact working copy in the controlled submission record.
3. Attaching an ETSI report without mapping it
The report may be valuable, but reviewers still need a clear path from JC-STAR item to implementation and evidence. Record uncovered differences and close them through tests or rationale.
4. Accepting an ODM’s “compliant” statement without supporting data
The applicant needs enough detail to answer questions. Establish access to design records, firmware identities, security settings and test results under appropriate confidentiality terms.
5. Publishing a support period that operations cannot sustain
Product, engineering, service and legal teams must approve the same commitment. Treat an update-support statement as an operating obligation, not marketing copy.
6. Advertising “JC-STAR pending” too early
IPA does not permit expressions such as “conformance-label compatible,” “JC-STAR conformance planned” or “application in progress” unless the application has been accepted and IPA has issued an acceptance number or provisional registration number. Approval is not guaranteed. Put all label-related wording under a controlled release process.
7. Estimating IPA checks as a fixed number of days
The 31 July 2026 notice says checks are taking longer than usual but gives no promised period. Separate internal readiness, submission, acceptance, questions and issuance in programme reporting.
8. Closing the project without change control
New model numbers, firmware releases, cloud migrations, revised vulnerability contacts and end-of-support decisions need an impact assessment. Transfer the evidence register and decision responsibility to the sustaining organisation.
Operating model for Thailand and ASEAN manufacturers selling into Japan
For products manufactured in Thailand or Vietnam and sold through a Japanese subsidiary or distributor, evidence often crosses company and language boundaries. A workable RACI looks like this:
| Role | Core accountability |
|---|---|
| Japanese application owner | IPA contact, application scope, Japanese answers, final approval |
| Product owner | model list, market configuration, support term, change decisions |
| Engineering or ODM | design explanation, firmware baseline, remediation |
| Quality and test | test methods, device results, reproducibility, revision control |
| PSIRT or security | vulnerability intake, triage, remediation and notification |
| Legal and procurement | NDA, evidence-access rights, authorisation and claims |
| Sales and marketing | accurate post-issuance use of the label and model scope |
Build a controlled vocabulary for terms such as secure update, support period and vulnerability disclosure. In multilingual teams, the goal is not word-for-word translation; it is one operational meaning across contracts, engineering records, application answers and customer statements.
Pre-application Go/No-Go checklist
The following is an internal readiness gate, not an official IPA form:
- Applicant, manufacturer, brand, model numbers and release configuration are fixed.
- The application number is being obtained through the process effective from 22 April 2026.
- Live IPA rules, forms and the STAR-1 page were rechecked immediately before submission.
- The 2025.05.05 checklist corrected on 29 June 2026 is being used.
- The checklist assessment can be completed within 90 days before the application date.
- Every conclusion has an evidence owner, revision, product build and review record.
- Authentication, update integrity, protected communications and data handling have been tested on a representative device.
- The vulnerability-reporting channel is public, monitored and connected to remediation.
- Product, engineering, service and legal functions approve the same support commitment.
- OEM or ODM evidence can be obtained throughout the required retention period.
- ETSI EN 303 645 materials are mapped to JC-STAR, with gaps made explicit.
- Any PSTI or CLS route has been checked for product identity, level and current dedicated forms.
- The budget covers the IPA fee, assessment, remediation, retest and maintenance.
- No “planned,” “pending” or similar claim will be published before IPA’s conditions are met.
- An owner is appointed for post-approval changes and reporting.
A realistic internal project structure when IPA timing is uncertain
Manage the work that the vendor can control without inventing an IPA processing timeline.
Gate A — scope and authority: Fix the product matrix, applicant, evidence rights and market versions. Escalate ODM information gaps while engineering review can still change the plan.
Gate B — conformance gap: Review the current checklist and separate evidence gaps from product gaps. If a security-design change is needed, put it into the release plan before polishing the application.
Gate C — evidence and operations: Complete tests and validate that vulnerability response, update distribution, support-end and public-information processes actually operate. A tabletop vulnerability exercise can reveal ownership gaps that a written policy hides.
Gate D — independent submission review: Someone other than the primary drafter should cross-check the form, checklist, evidence, firmware, model numbers, dates, URLs and legal names. After submission, keep one question log and one controlled response set.
This approach cannot shorten IPA’s checks, but it can prevent applicant-side inconsistencies from creating avoidable extra cycles.
Related guidance
- JC-STAR and IoT security labelling developments in 2026
- How manufacturers can incorporate JC-STAR into procurement
FAQ: JC-STAR application and acquisition
Can a manufacturer outside Japan apply for JC-STAR?
An overseas manufacturer’s product may be eligible, but IPA says the application must be made in Japanese and asks for a person who understands Japanese. Confirm the applicant or agent structure, corporate evidence and access to the manufacturer’s technical records.
How long does JC-STAR acquisition take?
IPA’s 31 July 2026 notice says checks are currently taking longer than usual. It does not provide a standard completion period. Do not plan on an unsupported number of days; report internal readiness, submission, acceptance, questions and issuance as separate events.
How much does a STAR-1 application cost?
The standard IPA fee is JPY 198,000 including tax per application, paid after acceptance and non-refundable after payment. External evaluation, remediation, testing, translation and maintenance are separate. The published STAR-1 fee for the CLS-compliant-product mutual-recognition route is JPY 140,000 including tax.
Does ETSI EN 303 645 conformity qualify a product automatically?
No. ETSI materials may provide useful evidence, but the vendor must map them to current JC-STAR requirements, complete the current checklist and follow the JC-STAR application process.
Which STAR-1 checklist is current?
As checked on 26 August 2026, IPA’s Japanese STAR-1 page lists the 2025.05.05 version corrected on 29 June 2026. Download it again immediately before use.
May we say “JC-STAR application pending” on the product page?
Not without meeting IPA’s stated conditions. IPA restricts such wording unless the application has been accepted and an acceptance number or provisional registration number has been issued. Verify the live conditions before publishing any claim.
Does mutual recognition remove the need to apply?
No. The PSTI and CLS routes use dedicated forms and review. Confirm the eligible product, level, reduced or exempted scope and current fee for the direction in which you are applying.
Should we use an external assessment provider for STAR-1?
STAR-1 is based on self-conformity, but external review may be useful when evidence is distributed across an ODM, variants are complex or the team has no prior scheme experience. Confirm scope and cost separately from the IPA fee.
Conclusion: make current versions and traceable evidence your competitive advantage
A 2026 JC-STAR application should reflect the application-number procedure effective 22 April, current forms, the STAR-1 checklist corrected on 29 June, and the scheme-document page updated on 16 July. The standard STAR-1 IPA fee is JPY 198,000 including tax, but it is only one part of the budget. ETSI EN 303 645 work and the new PSTI and CLS mutual-recognition paths can reduce duplication, yet they do not replace product-specific mapping or the prescribed application. With IPA currently saying that checks take longer than usual, the strongest plan is not a guessed acquisition date. It is a controlled package in which the application, checklist, released product, public claims and evidence all describe the same thing.
TOMAS TECH can support early-stage scoping, ETSI EN 303 645 gap mapping, evidence-register design and coordination between Japan and Thailand or other ASEAN engineering teams. Share your product family and target markets through our contact page to discuss a practical preparation path without assuming an approval timeline.
Primary sources checked on 26 August 2026
- IPA: New application procedures for STAR-1 and STAR-2
- IPA: Application and Reporting Process
- IPA: Japanese STAR-1 application page and corrected checklist
- IPA: Current forms library
- IPA: Current scheme-document library
- IPA: UK PSTI mutual-recognition application
- IPA: Singapore CLS mutual-recognition application
- IPA: STAR-1 conformance requirements and assessment procedures
- ETSI: Consumer IoT Security and EN 303 645
*This article is operational guidance for companies considering the scheme. It does not guarantee IPA acceptance, a label, or a completion date. Always use the live IPA rules, forms and notices when applying.*
