JC-STAR in October 2026: What Japan's IoT Security Label Requires, Who Asks for It, and How PSTI Recognition Works

Japan's IoT security label, JC-STAR, has been open for applications since March 2025, and in 2026 it started to matter outside Japan. Since 1 January a product that meets the UK's PSTI Act can reuse that work toward a JC-STAR label, and since 1 June the same goes for Singapore's Cybersecurity Labelling Scheme. Japanese government guidelines now steer agencies toward labelled devices. IPA, the agency that runs the scheme, said in July that applications had surged.

This explainer is for teams that make or sell connected devices, such as routers, cameras, sensors and controllers, and either sell into Japan or already comply with PSTI or CLS. It covers what the four levels are, which of them you can get today, the 16 requirements behind the first level, who is asking for the label, how mutual recognition works, and a script that checks STAR-1 evidence and marketing copy.

The short answer

JC-STAR is Japan's voluntary security label for internet-connected products, run by IPA under a policy METI published in August 2024. It has four levels. In October 2026 only STAR-1 is open: a self-declaration against 16 baseline requirements, which IPA reviews before issuing a label valid for two years. STAR-2 applications are planned for "2026 or later", STAR-3 requirements for network devices and network cameras exist as tentative drafts, and STAR-4 is still in preparation. Products that already comply with the UK PSTI Act are exempt from three STAR-1 checklist items and pay a lower fee. Until IPA has issued an acceptance number and a provisional registration number, don't market it with wording such as "label supported", "conformance planned" or "application in progress". IPA has said that's not allowed.

What JC-STAR is

The name stands for Japan Cyber STAR, and its formal title is the Labeling Scheme based on Japan Cyber-Security Technical Assessment Requirements. IPA describes it as covering "a wide range of IoT products capable of communicating with the internet", with requirements harmonized with ETSI EN 303 645 and NISTIR 8425. The policy behind it is METI's IoT Product Security Conformity Assessment Scheme Policy of 23 August 2024.

A label carries the level, a registered ID and a two-dimensional barcode that links to a product page IPA maintains. That page lists the applicant, the product, the label's status and security information such as updates and vulnerabilities. IPA is explicit about the limits: a label "does not assure complete or perfect security".

The four levels, and which exist today

STAR-3 is moving. IPA published the security requirements for network devices and cameras in Japanese on 6 February 2026, and their conformance requirements on 12 June, with English versions following in July and September. Between June and July it also published the requirements, guidance and procedures for approving third-party evaluation bodies. No STAR-3 evaluation guide is out yet, so for now STAR-1 is the label you can actually get.

Self-declaration doesn't mean unchecked. Vendors must keep their evidence, and IPA can inspect labelled products, ask for evidence or a fresh assessment, and revoke the label.

What STAR-1 requires

The STAR-1 requirements document, JST-CR-01-01-2024R1, has 16 requirements. Each one is checked by document review, a device check or both:

Two requirements need more than paperwork. S1.1-13 needs a vulnerability scan of the product itself that finds nothing exploitable, so known vulnerabilities in the software a device ships with have to be fixed before you apply. And S1.1-16 makes the vendor tell users what happens when support ends, close to PSTI's rule on support periods.

Labels last two years. STAR-1 and STAR-2 labels can be extended in two-year steps. STAR-3 and STAR-4 labels extend one year at a time and need recertification after five years. The standard STAR-1 application fee is 198,000 yen including tax.

Who is asking for it

JC-STAR is voluntary, so its pull comes from buyers. IPA's page on adoption lists three kinds:

• Government agencies. In September 2025, Japan's National Cybersecurity Office revised the guidelines agencies use to set their security standards. IoT devices in systems classed as low importance should come from STAR-1 labelled products or have the same functions. For medium and high importance systems, agencies should choose STAR-1 or higher and add more advanced functions.
• Local governments. The Ministry of Internal Affairs and Communications' guidelines for local government security policy, revised in March 2025, list checking for a JC-STAR label as one way to confirm an IoT device has the right protections.
• Critical infrastructure. IPA says it's working with the relevant bodies to have critical infrastructure operators select labelled products by use and risk. That isn't in place yet.

METI has also published a guide to using JC-STAR in sector-specific systems, and industry guidelines for energy aggregation and device retailers refer to it.

Mutual recognition with the UK and Singapore

UK PSTI. METI and the UK's Department for Science, Innovation and Technology signed a memorandum of cooperation in London on 5 November 2025, and recognition started on 1 January 2026. It runs in both directions:

• A PSTI-compliant product applying for JC-STAR is treated as meeting S1.1-02, S1.1-05 and S1.1-16, skips those three checklist items, and pays a reduced STAR-1 fee of 140,000 yen.
• A JC-STAR labelled product can be listed by IPA as PSTI compliant, if the vendor provides product and vulnerability information in English, among other conditions. Only STAR-1 is recognized for PSTI, and Northern Ireland is excluded.

Singapore CLS. METI and Singapore's Cyber Security Agency signed a memorandum in Tokyo on 18 March 2026, and recognition started on 1 June. It covers JC-STAR STAR-1 and CLS Level 1, and is partial: a CLS-labelled product skips the matching checklist items and gets the same reduced fee. A JC-STAR labelled product can apply for CLS Level 1 through CSA's mutual recognition route without a test lab.

Japan is also a founding member of the Global Cyber Security Labelling Initiative, with ten other governments as of October 2025.

Don't claim the label early

IPA has warned twice, in April and May 2026, about products marketed with wording such as "JC-STAR conformance planned", "label supported" or "label application in progress" when no label had been issued. Its rule is that no such wording may appear before IPA accepts the application and issues an acceptance number. After that, a vendor can request a provisional registration number and use it in pre-launch material. IPA says it may publish the facts about misleading claims and act on the vendor's application.

Check your evidence and your copy

This script does two things. gaps reads a JSON file recording the status and evidence for each STAR-1 requirement. It applies the PSTI exemption when you mark the product as PSTI compliant, and flags requirements with no evidence, a "not applicable" with no reason, or a "not applicable" where STAR-1 doesn't allow one. claims scans product pages or release notes for the kind of label wording IPA prohibits. It reads files only and uses the Python standard library.

#!/usr/bin/env python3
"""JC-STAR STAR-1 readiness and label-claim checks.

  python3 jcstar_check.py gaps evidence.json
      Report STAR-1 requirements that still lack evidence. With
      "psti_compliant": true, S1.1-02, S1.1-05 and S1.1-16 are exempt
      from the checklist, as IPA's PSTI mutual recognition page states.

  python3 jcstar_check.py claims FILE [FILE ...]
      Flag marketing text that implies a JC-STAR label before IPA has
      issued one (IPA does not allow such wording without a provisional
      registration number).

Reads files only. Standard library only.
"""
import json
import re
import sys

STAR1 = {
    "S1.1-01": "access control with appropriate authentication over IP",
    "S1.1-02": "no common default passwords",
    "S1.1-03": "network authentication values can be changed",
    "S1.1-04": "brute-force resistance (unless constrained device)",
    "S1.1-05": "public vulnerability disclosure policy",
    "S1.1-06": "updatable firmware, version visible, kept across power loss",
    "S1.1-07": "easy, documented update procedure",
    "S1.1-08": "integrity check before network updates",
    "S1.1-09": "documented policy for prioritising security updates",
    "S1.1-10": "model number available to users",
    "S1.1-11": "protected assets stored securely",
    "S1.1-12": "protected assets protected in transit",
    "S1.1-13": "unneeded ports, Bluetooth, USB disabled; vulnerability scan clean",
    "S1.1-14": "settings and updates survive power loss",
    "S1.1-15": "user can delete their data",
    "S1.1-16": "security information for users, incl. support policy",
}
PSTI_EXEMPT = {"S1.1-02", "S1.1-05", "S1.1-16"}
# Requirements whose "Conditions for being Not Applicable" are not "None"
# in JST-CR-01-01-2024R1. Every other requirement must be met.
NA_ALLOWED = {"S1.1-01", "S1.1-02", "S1.1-03", "S1.1-04", "S1.1-08", "S1.1-12"}
VALID = {"met", "na", "gap"}

# Wording IPA's notice names, plus English equivalents of the same idea.
CLAIM_PATTERNS = [
    r"JC-STAR\s*適合予定", r"適合ラベル取得申請中", r"適合ラベル対応",
    r"JC-STAR[- ](ready|pending|compliant soon|certification pending)",
    r"(applying|applied|application submitted) for (a )?JC-STAR",
    r"JC-STAR (label )?(coming soon|in progress)",
]
PROVISIONAL = re.compile(r"(仮登録番号|provisional registration (no\.|number))", re.I)


def gaps(path):
    ev = json.load(open(path, encoding="utf-8"))
    reqs = ev.get("requirements", {})
    psti = bool(ev.get("psti_compliant"))
    open_items, na_without_reason, na_not_allowed = [], [], []
    for rid, desc in STAR1.items():
        if psti and rid in PSTI_EXEMPT:
            print(f"  {rid} exempt (PSTI statement of compliance): {desc}")
            continue
        item = reqs.get(rid, {"status": "gap"})
        status = item.get("status", "gap")
        if status not in VALID:
            status = "gap"
        if status == "na" and rid not in NA_ALLOWED:
            na_not_allowed.append(rid)
        elif status == "na" and not item.get("reason"):
            na_without_reason.append(rid)
        if status == "met" and not item.get("evidence"):
            status = "gap"
        if status == "gap":
            open_items.append((rid, desc))
    for rid, desc in open_items:
        print(f"  GAP {rid}: {desc}")
    for rid in na_not_allowed:
        print(f"  NA NOT PERMITTED {rid}: {STAR1[rid]} has no NA condition")
    for rid in na_without_reason:
        print(f"  NA WITHOUT REASON {rid}: the checklist needs the rationale")
    n = len(open_items) + len(na_not_allowed) + len(na_without_reason)
    print(f"  {n} item(s) open of {len(STAR1)}" + (" (3 exempt via PSTI)" if psti else ""))
    return 1 if n else 0


def claims(paths):
    bad = 0
    for p in paths:
        text = open(p, encoding="utf-8", errors="replace").read()
        has_prov = bool(PROVISIONAL.search(text))
        for n, line in enumerate(text.splitlines(), 1):
            for pat in CLAIM_PATTERNS:
                if re.search(pat, line, re.I):
                    verdict = "check provisional number" if has_prov else "NOT ALLOWED without a provisional registration number"
                    print(f"  {p}:{n}: {line.strip()[:70]!r}: {verdict}")
                    bad += 0 if has_prov else 1
                    break
    if not bad:
        print("  no disallowed label claims found")
    return 1 if bad else 0


def main(argv):
    if len(argv) >= 2 and argv[0] == "gaps":
        return gaps(argv[1])
    if len(argv) >= 2 and argv[0] == "claims":
        return claims(argv[1:])
    print(__doc__.strip())
    return 2


if __name__ == "__main__":
    sys.exit(main(sys.argv[1:]))

On a sample evidence file for a network camera that already complies with PSTI, with one requirement still open, one without evidence and two "not applicable" entries:

$ python3 jcstar_check.py gaps camera.json
  S1.1-02 exempt (PSTI statement of compliance): no common default passwords
  S1.1-05 exempt (PSTI statement of compliance): public vulnerability disclosure policy
  S1.1-16 exempt (PSTI statement of compliance): security information for users, incl. support policy
  GAP S1.1-09: documented policy for prioritising security updates
  GAP S1.1-13: unneeded ports, Bluetooth, USB disabled; vulnerability scan clean
  NA NOT PERMITTED S1.1-15: user can delete their data has no NA condition
  NA WITHOUT REASON S1.1-12: the checklist needs the rationale
  4 item(s) open of 16 (3 exempt via PSTI)

And on a draft product page:

$ cat product-page.md
# Example Camera 3

Secure by design, with signed firmware updates.

JC-STAR ready: application submitted for a JC-STAR STAR-1 label.

$ python3 jcstar_check.py claims product-page.md
  product-page.md:5: 'JC-STAR ready: application submitted for a JC-STAR STAR-1 label.': NOT ALLOWED without a provisional registration number

The script works from requirement summaries, not the full text. Use it to track progress, and fill in IPA's own checklist for the application.

What to do

1. Decide whether Japan matters to you. If you sell IoT devices to Japanese government agencies or local governments, a STAR-1 label is becoming the expected answer. If you sell to consumers there, it's a differentiator, not yet a requirement.
2. Start from what you have. PSTI compliance covers three STAR-1 items and lowers the fee. CLS Level 1 covers some too. The two that usually need new work are S1.1-13's vulnerability scan and S1.1-15's data deletion.
3. Build the evidence once. STAR-1 was written to align with ETSI EN 303 645, so much of the evidence you keep for the EU or UK applies. Keep the evidence, since IPA can ask for it at any time during the label's life.
4. Know what's in the firmware. A clean vulnerability scan needs a current list of components and the versions they're on. Our guide to SBOMs for firmware and IoT devices covers building one.
5. Watch STAR-3 if you make network equipment or cameras for government or critical infrastructure. Its requirements exist and the evaluation bodies are being approved. The evaluation guide is the last piece.
6. Hold the marketing until IPA issues an acceptance number and, if you need it, a provisional registration number.

For the UK side of the same requirements, see our review of the PSTI Act's first year.

The fair view

STAR-1 is a modest bar. It's self-declared, it overlaps with requirements many device makers already meet for the UK and EU, and a label says nothing about how well those controls hold up under attack. IPA says so itself. The levels that would carry real assurance, STAR-3 and STAR-4, aren't available yet, more than a year and a half after STAR-1 opened.

But labels like this work by changing what buyers ask for, and that's what is happening. Japanese agencies have a guideline that names the label, local governments have a checklist that mentions it, and two foreign schemes now accept it. A device maker that already does the work for PSTI can add a STAR-1 label with relatively little extra effort. The vendors who wait for STAR-3 to become mandatory will be doing the same evidence work later, on a deadline.