When conducting IoT security evaluations, you’ll uncover a sobering truth:80% of vulnerabilities are not the result of sophisticated cyberattacks—they stem from "devices failing to lock their own doors".

Default passwords, exposed debug ports, hardcoded keys, unsigned firmware… These classic pitfalls are grounds for automatic failure under any international security standard.

Though JC-STAR (Japan Cyber-STAR) is a Japanese cybersecurity benchmark framework, its requirements for device-side security (hardware/firmware) align almost perfectly with global mainstream IoT security standards:Minimize risks in the device’s default state and eliminate engineers’ complacent mindset of "I don’t think anyone will find this".

This guide breaks down all core JC-STAR device-side security requirements in one comprehensive overview.

I. Identity Authentication: Start with "No Default Passwords"

Every international IoT security standard enforces one ironclad rule: no default or weak passwords allowed.

1. Default Passwords Must Be Eliminated

• Prohibit shared default credentials (e.g., admin/admin) across all devices.
• Mandate forced password reset on first boot.
• Avoid printing "unique label passwords" on product packaging (vulnerable to unauthorized photography).

2. Password Strength Must Meet Minimum Standards

Common compliance criteria require passwords to:

• Be at least 8 characters long
• Include a mix of character types (letters, numbers, symbols)
• Ban weak passwords such as 123456, password, and qwerty

3. Account Management Must Be Tidy

• Forbid hidden backdoor accounts left in the system at the factory.
• Remove all debugging accounts (e.g., engineering mode accounts) before production.
• Block default root login via Telnet/SSH.

One-sentence takeaway: Retaining default passwords is a red line that guarantees 100% failure in compliance audits.

II. Firmware Update Mechanism: Secure Updates Are Mandatory

As a government-led cybersecurity benchmark, JC-STAR emphasizes sustained security—and firmware updates are central to this goal.

1. Support for Legal Update Channels Is Required

At least one of the following update methods must be available: OTA (Over-the-Air), wired, or USB.There is no room for "this device cannot be upgraded". Even smart air conditioner sockets need vulnerability patching capabilities.

2. Update Packages Must Have Integrity Protection

Universal requirements include:

• Digital signature verification
• Integrity check using at least SHA-256 hashing
• Automatic rejection of updates that fail verification

3. Update Processes Must Be Secure

Key requirements cover:

• Mandatory HTTPS for fetching update information
• Verifiable source authentication for update files
• Failure rollback mechanism (to prevent bricking the device)

An unsigned update system is essentially "an all-you-can-hack buffet for supply chain attacks".

III. Debug Interfaces (Telnet/UART/Debug): High-Priority Audit Targets

All security standards classify debug interfaces as high-risk vectors.

1. Telnet = Disabled by Default

International standards uniformly require:

• Telnet must be permanently disabled.
• If enabled for debugging in test environments, it must be completely removed before mass production.

2. SSH Must Use Key-Based Authentication (No Password Login) & Restrict Root Access

• Prohibit root login with empty or weak passwords.
• Prevent SSH exposure to the public internet.

3. UART/JTAG Interfaces Must Implement One of the Following Measures

• Full disablement
• Physical protection of solder joints or tamper detection
• Require authentication to access the shell

4. Debug Mode Must Be Disabled

Debug logs, diagnostic ports, and engineering commands are typical "forgotten-to-turn-off" pitfalls at the factory.

IV. Key Management: Hardcoding Is Always a Red Line

This is a critical checkpoint in IoT security evaluations.

1. Prohibit Hardcoded Keys, Tokens, JWTs, & Cloud Keys

This includes:

• MQTT tokens
• JWT secrets
• TLS private keys
• Cloud API keys
• Symmetric encryption keys

Hardcoding = unlimited exposure of sensitive credentials.

2. Secure Storage of Certificates & Keys Is Mandatory

Common requirements:

• Private keys must never be stored in plaintext on the file system.
• At minimum, enforce file permission isolation (e.g., 600 permissions).
• High-end devices should use secure enclaves (TEE/SE/TPM).

3. Key Rotation Mechanism Must Be Supported

• Cloud-delivered keys require TLS mutual authentication.
• Keys must not be hardcoded into firmware.
• Support key rotation and revocation.

V. Device Logs & Security Events: Record Critical Behaviors at Minimum

International standards generally mandate devices to log the following key events:

1. Mandatory Logged Events

• Successful/failed login attempts
• Configuration changes
• Firmware updates
• Security anomalies (e.g., brute-force authentication attempts)
• Communication failures/certificate verification failures

2. Log Requirements

• Exclude sensitive information (passwords, tokens) from logs.
• Restrict log access with permission controls (prevent unauthorized leakage).
• Limit log size growth to avoid Denial of Service (DoS) risks.

3. Security Event Reporting (For Cloud-Connected Devices)

• Report suspicious activities to the cloud backend.
• Integrate with the manufacturer’s vulnerability response mechanism.

VI. Red Line Behaviors to Avoid at All Costs

The following issues result in immediate failure under any compliance framework. Manufacturers with these flaws will face intense scrutiny from testing laboratories.

1. Weak/Default Passwords

   • root/123456
   • admin/admin
   • Default WiFi password 12345678

2. Residual Debug Modes

   • Dropbear debug=1
   • Python Flask debug=True
   • Access to BusyBox root shell via UART

3. Hardcoded Sensitive Information

   • JWT secret = abcd1234
   • Hardcoded cloud API keys
   • AES keys stored as constants in binary files

4. Hardcoded & Expired Certificates

   • Factory-installed certificates not updated for 5+ years
   • Shared private keys across all devices

5. Unencrypted Communication

   • Firmware updates via HTTP (not HTTPS)
   • MQTT without TLS encryption
   • Unencrypted local device communication

Simple litmus test: If a student hacker can compromise the device using basic tools like binwalk + strings, it is definitely non-compliant.

If you’ve read this far, congratulations—you now understand the most "high-risk" areas of IoT security.

Device security may seem fragmented, trivial, and cumbersome, but its underlying logic can be summed up in one sentence:Don’t expose what you don’t have to, don’t hardcode what you don’t have to, and don’t trust what you don’t have to.

By disabling default passwords, closing debug ports, properly managing keys, and signing firmware, your device’s overall security will improve by leaps and bounds.

At its core, JC-STAR’s device-side requirements remind manufacturers of one critical fact: devices are the weakest link in the cybersecurity chain. Without strengthening this link first, all subsequent cloud-side security measures will be for nothing.