How a Game Console Is Made: Custom SoC, Security Chip and Signed Updates

A modern game console is a custom system on chip (one die holding the CPU and GPU) wired to a single pool of GDDR6 memory and a fast NVMe SSD, with a security processor inside that die acting as the root of trust. Keys are fused into the silicon at the factory, every boot stage checks the signature of the next, and system updates are signed images that the console refuses to roll back.

This post goes one level deeper than our walkthroughs of how a laptop is made and how a GPU is made. It follows a console from wafer to box, explains how a security processor that started in a console ended up in Windows PCs, and covers signed updates, two decades of console attack and defence, the open source inside, US and EU repair law, and how to check your own console. Console makers do not publish line yields, burn-in times or key ceremonies, so where a number is private we say so.

Key takeaways

• Current consoles use semi-custom chips. Microsoft lists an 8 core Zen 2 CPU and a 52 compute unit RDNA 2 GPU on one 360.45 mm² die for Xbox Series X, with 16 GB of GDDR6; Sony lists 8 Zen 2 cores, an RDNA 2 based GPU, 16 GB of GDDR6 and an 825 GB SSD for PS5.
• Both added custom I/O hardware. Microsoft's hardware decompression block doubles effective SSD throughput from 2.4 GB/s raw to 4.8 GB/s compressed.
• Microsoft says the Pluton security processor design was introduced in the Xbox One in 2013 with AMD, and that the same design now ships in Windows PCs as a crypto processor inside the CPU that can provide TPM functions.
• A 2019 Microsoft talk on the Xbox One explains the core design rule: data read from flash, the hard drive and even DRAM cannot be trusted, so the chip must verify or encrypt everything it reads from outside itself.
• Mask ROM boot code cannot be patched in the field, as NVD's 2018 record of a boot ROM flaw in some older Tegra processors (CVE-2018-6242) shows.
• The US Copyright Office's 2024 rule allows circumvention to repair consumer devices, but for video game consoles "repair" is limited to the optical drive, and the protection must be restored afterwards. The tenth triennial review opened in June 2026.
• The EU repair Directive (EU) 2024/1799 applies from 31 July 2026, but its obligation to repair covers only products listed in its Annex II. The EU Cyber Resilience Act's reporting duties apply from 11 September 2026 and its main duties from 11 December 2027.

From wafer to boxed console in one table

This is the map for the rest of the post. Console makers publish chip specifications and little else about their factories, so the table names the kind of check at each stage rather than inventing yields or durations. Steps 4 and 8 are where the security of the finished console is decided.

Two consequences follow from this table. First, a console's security cannot be stronger than step 4: if the fused root key hash or the debug lock is wrong, no later update fixes it. Second, the firmware in the box is often months old by the time someone opens it, which is why every current console asks to update during setup.

What is inside a modern console?

Strip the shell off a current home console and you find five main blocks: the main board with the SoC, GDDR6 memory and SSD, an internal power supply, a cooling assembly, the optical drive on disc models, and the wireless and controller hardware. The two makers' own launch specifications, published in March 2020, are the best public record of the silicon.

These are launch specifications, not a ranking; later revisions changed storage, process and enclosures.

The semi-custom APU: CPU and GPU on one die

Both consoles put the CPU cores and the GPU on one piece of silicon, an arrangement the PC world calls an APU (accelerated processing unit). One die means one memory controller serves both, CPU and GPU share data without copying it across a bus, and the board needs one large chip and one cooler. The cost is that a single defect can scrap an expensive die.

Unified GDDR6 memory

A PC has DDR system memory for the CPU and separate GDDR memory on the graphics card. A console uses one pool of GDDR6 for both. GDDR6 trades latency for bandwidth: it is built for a wide bus moving large blocks to a GPU, which suits a games machine whose heaviest traffic is textures and geometry. GDDR6 is an industry standard memory type rather than a console specific part, which is why consoles can buy it from more than one memory maker.

Microsoft's split figures show a trade off: 10 GB run at 560 GB/s and 6 GB at 336 GB/s on the same 320 bit bus. Sony lists a single 448 GB/s figure for its 16 GB.

NVMe storage and hardware decompression

Both consoles moved from hard drives to solid state storage in 2020, and Microsoft's specification names a custom NVMe SSD. NVM Express is the register and command interface that lets a host talk to flash storage over PCI Express. The NVM Express organisation publishes it as a family: a Base specification, command set specifications and transport specifications. The SSD itself carries a controller with its own firmware, a separate signed component inside the console, as covered in our post on how an SSD is made.

Game data is stored compressed, and decompressing it on the CPU would eat cores. Microsoft's hardware decompression block and Sony's "integrated custom I/O system", built to remove loading screens, are the clearest example of what semi-custom buys: fixed function blocks a general PC chip would not carry.

Power supply and cooling

Current home consoles typically use an internal power supply rather than an external brick, converting mains AC to the low voltage rails the board needs. The SoC is the main heat source, and current designs pair it with a large heat sink or vapour chamber and a single large fan. Console makers do not publish thermal design power figures for their SoCs in the launch posts we cite, so we do not quote one. What matters for reliability is that the line tests thermal behaviour under load before shipping (step 10 in the table).

Wireless, controllers and the optical drive

Consoles carry Wi-Fi and Bluetooth radios, and controllers connect over a wireless link. Any device with an intentional radio sold in the US must be certified by the FCC, which is why the label carries an FCC ID. The optical drive on disc models is its own small computer with firmware, and as we will see, it is the one part US copyright rules single out for console repair.

Why do console makers commission semi-custom silicon?

A console lives for years at a fixed hardware specification, sells in very large numbers of identical units, and has to hit a retail price, which makes a custom chip worth its up front cost. The maker can choose exactly how many CPU cores and GPU units to pay for, add fixed function blocks such as decompression and audio, and fold a security processor into the die so that keys never leave it.

The silicon partner brings licensed building blocks and the design teams that know them. Both console makers' public launch material credits AMD's Zen 2 CPU and RDNA 2 graphics. Microsoft's 16 March 2020 Xbox Wire post says AMD began working with the Xbox team more than 15 years earlier on the Xbox 360, and quotes Sebastien Nussbaum, AMD's corporate vice president for semi-custom products and technologies, calling Xbox Series X the biggest generational leap of "SOC [System on a Chip] and API design" the two companies had done. Microsoft's 2020 Pluton announcement adds an AMD statement that the two companies had been "closely partnering" on processor security "beginning with the Xbox One console".

From public material, the flow is: the console maker sets targets for performance, power, die size and price; the partner proposes a configuration from its CPU and GPU blocks; the console maker adds its own intellectual property (Microsoft says Pluton went into the Xbox One "in partnership with AMD"); and the combined design is verified, taped out and brought up while both sides tune system software and graphics APIs to it. The contract model and cost split are not public, so we do not describe them.

How is a console board and system assembled and tested?

The board side of a console is built like any dense consumer board, with tighter tolerances. Our post on how a printed circuit board is made covers the laminate and fabrication steps; here is what is specific to a console.

Surface mount assembly

Solder paste is printed through a stencil, parts are placed and reflowed, and the SoC and GDDR6 ball grid arrays are checked by X-ray because their joints are hidden. GDDR6 and PCIe traces need controlled impedance.

Flashing and functional test

The assembled board gets its first software image. On a console, the SoC's boot ROM will only run code signed by the console maker, so the factory image is a signed image like any update, not an unsigned test build. The board boots, and the test station exercises HDMI output, USB, Ethernet, Wi-Fi, Bluetooth, the SSD and the optical drive interface. Per device certificates that let the console prove its identity to the online service are installed at some point in the flow. The exact station where this happens is not published.

Burn-in and thermal testing

Finished consoles run test loads on powered racks. The goal is to catch early life failures (a weak solder joint, a marginal memory chip) before the console ships, and to confirm that the fan and heat sink keep temperatures in range under sustained load. Console makers do not publish burn-in durations.

FCC authorisation and the FCC ID

According to the FCC, an FCC ID is assigned to all devices subject to certification and has two parts: a grantee code of three or five characters, assigned by the Commission and representing the applicant, and an equipment product code. Because consoles and controllers contain radios, both carry one; Step 5 below shows how to look it up.

Controller pairing

The bundled controller is paired at the factory or on first setup, creating a shared secret with the console. Pairing protocols differ by platform, and each maker documents its own steps.

What is the hardware root of trust in a console?

A root of trust is the small piece of hardware and code that every other security check depends on and that cannot itself be checked by anything earlier. In a console it has three parts: immutable boot code in the SoC, keys fused into the SoC, and a security processor that holds those keys and runs the early checks. Our post on the hardware root of trust for device makers covers the general pattern; here is how consoles apply it.

Boot ROM and fused keys

When the console powers on, the first code that runs is in mask ROM inside the SoC. It was fixed at tape out (step 1 in the table) and cannot be changed. Its job is to load the next stage from flash and check its signature against a public key whose hash is burned into one time programmable fuses (step 4). If the check fails, the console does not boot that image. Device unique secrets in the fuses give each console its own identity.

A security processor inside the SoC

Microsoft has written most openly about this layer. Its Pluton documentation describes "a secure crypto-processor built into the CPU" and says it "is built on proven technology used in Xbox and Azure Sphere". The November 2020 announcement adds that the Pluton design "was introduced as part of the integrated hardware and OS security capabilities in the Xbox One console released in 2013 by Microsoft in partnership with AMD", and putting that IP "directly into the CPU silicon helped guard against physical attacks, prevent the discovery of keys, and provide the ability to recover from software bugs."

A console must assume its owner may attack it physically, so the keys live inside the die and recovery is designed in from the start.

Distrust everything outside the die

Tony Chen of Microsoft gave a talk titled "Guarding Against Physical Attacks: The Xbox One Story", published by the Platform Security Summit on 21 October 2019 and by the Microsoft Security Response Center from BlueHat Seattle 2019. Its abstract states the principle plainly: the team addressed "the fact that all data read from flash, the hard drive, and even DRAM cannot be trusted." In practice that means verifying code and data as they load, encrypting or integrity protecting sensitive memory, and assuming the buses between chips can be probed. The abstract also notes that the Xbox One and PS4 had then gone close to six years without being cracked to enable piracy, which it calls a first for game consoles.

How console security influenced PC security processors

The clearest documented line runs from console to PC through Pluton. Microsoft announced on 17 November 2020, with AMD, Intel and Qualcomm Technologies, that the Pluton processor "pioneered in Xbox and Azure Sphere" would come to Windows PCs. Microsoft's current Pluton documentation says it is designed to provide Trusted Platform Module (TPM) functionality and more, that its firmware can be updated through Windows Update alongside UEFI capsule updates of the copy held in SPI flash, and that Pluton platforms in 2024 AMD and Intel systems "will start to use a Rust-based firmware foundation" because memory safety matters.

The further inside the die the keys live, the harder they are to extract, and the more the device depends on getting immutable code right first time.

How do signed system updates, anti-rollback and per-console keys work?

Once the boot chain is in place, every system update is just a new signed image. The console's job is to accept only images that are authentic, intact and not older than what it is already running.

The signed update

The console maker's build system produces the update image and a signed manifest that lists the version number and the hash of each part. The private signing key lives in the maker's signing infrastructure, normally a hardware security module, and never on the console. The console downloads the update, verifies the signature with the public key it trusts, checks each hash, and only then writes the new image. Sony's own instructions show the user facing end of this: its PS5 support page warns not to "download or install the update using data other than the official update file provided online by Sony".

NIST's Platform Firmware Resiliency Guidelines (SP 800-193, May 2018) describe the same goals for any platform in three parts: protect firmware from unauthorised change, detect unauthorised change, and recover to a known good state. A console update chain is a strict implementation of all three.

Anti-rollback

A valid old image is still signed. If the console accepted any signed image, an attacker could reinstall an old version with a known bug. Anti-rollback stops that by storing a minimum allowed version in hardware the software cannot lower: one time programmable fuses that are blown as the version rises, or a monotonic counter in the security processor. The update is rejected if its security version is below the stored value. Our post on anti-rollback counters versus version numbers explains why the security version should move only when a fix must not be undone, since fuses run out.

Per-console keys

In designs like these, each console has device unique keys derived from fused secrets. They typically identify the console to the online service, bind licences to it and encrypt internal storage, so a drive moved to another console is unreadable. If one console's keys leak, the damage is limited to that console, and the service can revoke its certificate. Makers do not publish the details of their key hierarchies.

Recovery

Consoles ship a recovery path for a failed update. Sony documents PS5 Safe Mode: turn the console off, hold the power button and release it after the second beep, then choose to update or reinstall system software from a USB drive. In a sound design the recovery path is still a signed path, verified like an update from the network.

Why ECDSA nonce handling matters for signing

ECDSA, a common firmware signing algorithm, needs a fresh secret value (the nonce) for every signature; if two signatures share one, the private key can be computed. RFC 6979 (August 2013) defines deterministic generation of that value so signers no longer depend on a good random source, and Ed25519 builds deterministic nonces in. The signing service deserves the same review as the device.

Why are consoles a long running study in hardware attack and defence?

Consoles combine three things that attract attackers: a large installed base of identical hardware, a business model that depends on controlling what code runs, and owners who have the device in hand for years. The history below is conceptual. It describes the class of each weakness and the defensive lesson, not how to reproduce anything, and every date is from the primary source cited.

The pattern is consistent. Early consoles relied on PC style parts and secrets readable off a bus or out of flash. Later attacks targeted signing practices and boot code that could not be updated. The current generation answered with keys that never leave the die, checks on everything outside it, hardware anti-rollback and an updateable security processor, which is now standard advice for any device maker.

What open source components ship in console system software?

Console operating systems are proprietary, but they include open source components, and the licences of some of those components require the maker to publish source code or notices. The makers publish them.

Sony's "Source Code for Open Source Software Used in PlayStation 5" page states that the source is made available "in compliance with the applicable open source software licenses" and lists Eigen, cairo, the Public Suffix List, WebKit, WebKit JavaScriptCore, FFmpeg and source for its Share Factory Studio app. Those names tell you what kind of code is inside: a browser engine and JavaScript engine, a 2D graphics library, a linear algebra library, a media framework and the public suffix data browsers use to scope cookies.

Nintendo's Open Source Software source code distribution page says some Nintendo products include open source software under licences including the GNU Library General Public License 2.0, the GNU Lesser General Public License 2.1, the Mozilla Public License 1.1 and the Mini-XML License. It offers source archives per product (Nintendo Switch 2, Nintendo Switch, Wii U and the Nintendo 3DS family) and per system version; for Nintendo Switch 2 it lists archives for versions such as 19.0.0 and the 20.x releases, each about 139 MB (573 MB unpacked).

These pages are the best public evidence of which open source a console carries, and Nintendo's archives are versioned with system releases. The components named, such as browser engines and media frameworks, are the same ones that appear in advisories for phones, TVs and PCs, so a serious fix in one of them means the console needs a system update too.

What do right to repair rules and DMCA Section 1201 say about consoles?

United States: Section 1201 exemptions

Section 1201 of the US copyright law makes it unlawful to circumvent technological measures that control access to copyrighted works, including the software in a console. Every three years the Librarian of Congress, on the Copyright Office's recommendation, grants temporary exemptions. The current set comes from the ninth triennial rule, published in the Federal Register on 28 October 2024 (89 FR 85437) and effective that day. For consoles, four parts of the regulatory text matter:

Console repair is limited to the optical drive with the protection put back, and the open source investigation exemption excludes consoles entirely, which makes the makers' published source archives more important.

The Copyright Office opened the tenth triennial proceeding with a notice published on 9 June 2026 (91 FR 34795), with comments due 28 September 2026. Its Section 1201 page says renewed exemptions will run for an additional three years, from October 2027 to October 2030. Check the Copyright Office's page for the current status before relying on any exemption; this post describes the rule in force on the date at the bottom.

None of this is legal advice, and the exemptions do not authorise piracy, distribution of circumvention tools or anything outside their text.

European Union: repair and cybersecurity rules

Directive (EU) 2024/1799 on the repair of goods was adopted on 13 June 2024 and applies from 31 July 2026, according to the European Commission. Its obligation to repair covers products in Annex II, which already have EU reparability requirements; the Commission's examples are fridges and smartphones, and domestic local space heaters were added from 31 July 2026. For those products, makers must repair at a reasonable price and may not use contractual, hardware or software techniques that impede repair unless justified. The Commission's page does not name consoles and we could not confirm they are on Annex II, so do not assume the obligation covers them. The extra year of legal guarantee after a repair applies more broadly.

The Cyber Resilience Act (CRA) covers products with digital elements, a definition broad enough to include connected consoles. The Commission's summary says the CRA entered into force on 10 December 2024, its reporting obligations in Article 14 apply from 11 September 2026, and its main provisions apply from 11 December 2027. For console makers, vulnerability handling, security updates and reporting become legal duties in the EU.

How do you check a console's system software version, update settings and network privacy?

The steps below are for owners. Menus differ by console and change with updates; where we have a vendor's exact path we give it, and elsewhere we tell you where to look.

Step 1: Update first, then check the version

Before changing anything else, install the latest system software. On a PS5, Sony documents the path: Settings, then System, then System Software, then System Software Update and Settings. "Update Available" appears if there is a newer version; select Update System Software. Sony's page also describes automatic download and install. On other consoles, look for the system or console information page in Settings and compare the version with the maker's release notes.

Step 2: Update from USB when the network update fails

Sony's PS5 page documents an offline method. It needs a USB drive formatted as FAT32 or exFAT, a folder named PS5 containing a folder named UPDATE, and the official update file saved as PS5UPDATE.PUP, with about 1.1 GB free for an update or about 1.2 GB for a full reinstall. The commands below prepare such a drive.

Warning: formatting erases everything on the target drive. Identify the drive by size and model first, and make sure the device path you type is the USB drive and not your internal disk.

On macOS, list disks and find the USB drive by size and the word "external":

diskutil list external
# Confirm the identifier, for example /dev/disk4, matches the USB drive's size
diskutil info /dev/disk4 | grep -E "Device / Media Name|Disk Size|Protocol"

Only after confirming the identifier, format it as exFAT with a master boot record and create the folders:

# DESTRUCTIVE: erases /dev/disk4. Re-check the path before pressing Enter.
diskutil eraseDisk ExFAT PS5USB MBRFormat /dev/disk4
mkdir -p /Volumes/PS5USB/PS5/UPDATE
cp ~/Downloads/PS5UPDATE.PUP /Volumes/PS5USB/PS5/UPDATE/PS5UPDATE.PUP
ls -l /Volumes/PS5USB/PS5/UPDATE/
diskutil eject /dev/disk4

On Linux, find the device by size, model and transport (look for usb in the TRAN column):

lsblk -o NAME,SIZE,MODEL,TRAN,MOUNTPOINT
# Confirm that /dev/sdX is the USB drive, not a system disk
sudo fdisk -l /dev/sdX

Then, after confirming the path:

# DESTRUCTIVE: rewrites the partition table on /dev/sdX. Re-check the path first.
sudo parted /dev/sdX --script mklabel msdos mkpart primary 1MiB 100%
sudo mkfs.exfat -n PS5USB /dev/sdX1
sudo mount /dev/sdX1 /mnt
sudo mkdir -p /mnt/PS5/UPDATE
sudo cp ~/Downloads/PS5UPDATE.PUP /mnt/PS5/UPDATE/PS5UPDATE.PUP
sync && sudo umount /mnt

Download the update file only from the console maker's own support page. The console verifies the signature before installing, but a file from anywhere else is at best a wasted download.

Step 3: Review privacy and data sharing settings

Review both account privacy (who sees your activity and can message you) and console data sharing (diagnostic and usage data sent to the maker). Family controls are separate and worth setting for children.

Step 4: Check what the console exposes on your network

A console needs outbound internet access and, for some features, inbound peer to peer traffic for online play. Find it on your network from a computer on the same LAN:

# List devices your computer has recently seen; match the console's MAC address
# (shown in the console's network settings) to an IP address
arp -a

On your router, give the console a fixed DHCP lease and decide deliberately about UPnP: it lets the console open inbound ports for online play, and lets any other LAN device do the same. If you turn it off, forward only the ports the maker documents. A guest network or VLAN separates the console from computers holding sensitive files.

Step 5: Look up the FCC record

Find the FCC ID on the console's label or in its regulatory settings screen, then search for it on the FCC ID search page. The grant shows the applicant, the radio frequencies the device is certified for and the filing dates, and the attached exhibits often include internal photos unless the maker was granted confidentiality for them. It is a five minute check that tells you what the hardware is without opening it.

Step 6: Reset before you sell or give a console away

Sign out of all accounts, deactivate the console as your primary or home console if your platform uses that concept, and then run a full factory reset from the system menu. A full reset, not just signing out, is what removes your data and accounts.

How do console makers build signed updates with anti-rollback? A miniature pipeline

The previous sections described the console side. This section shows the shape of the maker side with standard tools, for engineers building any device that should behave the same way. It is a teaching model, not any console maker's actual process, and in production the private key stays in a hardware security module rather than a file.

Generate an Ed25519 signing key pair (deterministic signatures, so no nonce to get wrong):

openssl genpkey -algorithm ed25519 -out update-signing.key
openssl pkey -in update-signing.key -pubout -out update-signing.pub

Build a manifest that binds the image hash to a version and a security version:

IMG=system-20.3.0.img
cat > manifest.txt <<EOF
version=20.3.0
security_version=7
image_sha256=$(openssl dgst -sha256 -r "$IMG" | cut -d' ' -f1)
EOF
openssl pkeyutl -sign -inkey update-signing.key -rawin -in manifest.txt -out manifest.sig

On the device side, verify the signature, check the hash, then enforce anti-rollback against a stored minimum. Here the stored value is a file; on real hardware it is fuses or a monotonic counter that software cannot lower.

openssl pkeyutl -verify -pubin -inkey update-signing.pub -rawin \
  -in manifest.txt -sigfile manifest.sig || { echo "bad signature"; exit 1; }

want=$(grep '^image_sha256=' manifest.txt | cut -d= -f2)
have=$(openssl dgst -sha256 -r "$IMG" | cut -d' ' -f1)
[ "$want" = "$have" ] || { echo "image hash mismatch"; exit 1; }

new_sv=$(grep '^security_version=' manifest.txt | cut -d= -f2)
min_sv=$(cat /var/lib/device/min_security_version)
[ "$new_sv" -ge "$min_sv" ] || { echo "rollback refused"; exit 1; }
echo "update accepted; write image to inactive slot, then raise min to $new_sv after a good boot"

Three details in that script carry most of the security. The signature covers the manifest, and the manifest covers the image, so one signature protects everything. The rollback check uses a separate security version, so ordinary releases do not burn fuses. And the minimum is raised only after the new image has booted successfully, so a bad update can still fall back to the previous slot.

Common mistakes

• Treating the console's first boot as up to date. The firmware in the box may be months old. Let the setup update run first.
• Downloading update files from mirrors. Sony's page warns against update data other than its official file. Use only the maker's support page.
• Formatting the wrong drive while preparing a USB update. The PS5 offline update needs an exFAT or FAT32 drive, and the formatting command does not ask twice. Check the device path by size and model before every destructive command.
• Assuming "repair" includes modifying system software. In the US, the console part of the 2024 repair exemption covers the optical drive only, and the protection must be restored. Anything broader is outside the exemption.
• Relying on a version number for rollback protection. A display version can be faked or reset. Anti-rollback needs a security version enforced by hardware that software cannot lower, and a plan for how many times it can move.
• Putting the signing key on a build server. The device's boot chain is only as strong as the key that signs updates. Keep it in a hardware security module, sign through a controlled service, and log every signature.
• Selling a console without a full reset. Signing out is not enough; run the full factory reset.
• Forgetting the services around the console. A studio's game servers, launchers and companion apps ship open source libraries too, and they do not get patched by the console maker's system update.

FAQ

What chip is inside a PS5 and Xbox Series X?

Both use a semi-custom AMD chip with Zen 2 CPU cores and an RDNA 2 based GPU on one die, according to each maker's March 2020 specifications. Microsoft lists 52 GPU compute units on a 360.45 mm² die; Sony lists a GPU running at up to 2.23 GHz.

Why do consoles use GDDR6 instead of normal RAM?

One memory pool serves both CPU and GPU, and the GPU needs very high bandwidth. GDDR6 provides it on a wide bus, at the cost of higher latency than the DDR memory a PC CPU uses.

What is Microsoft Pluton and did it come from the Xbox?

Pluton is a security processor inside the CPU that protects keys and can provide TPM functions on Windows PCs. Microsoft says the design was introduced in the Xbox One in 2013 with AMD and announced it for PCs on 17 November 2020.

How does a console stop you installing old firmware?

Each update carries a security version, and the console stores the minimum allowed value in fuses or a monotonic counter. Images below it are refused even when correctly signed.

Is it legal to repair your own game console in the US?

Repair that does not circumvent access controls is not a Section 1201 question. Where circumvention is needed, the 2024 exemption limits console "repair" to the optical drive and requires restoring the protection. The tenth review of exemptions opened in June 2026.

Does the EU right to repair law cover game consoles?

Directive (EU) 2024/1799 applies from 31 July 2026, but its obligation to repair covers only Annex II products with EU reparability requirements. We could not confirm that consoles are listed, so check Annex II.

What open source software is in a PS5 or Nintendo Switch?

Sony's PS5 page lists WebKit, JavaScriptCore, FFmpeg, cairo, Eigen and the Public Suffix List. Nintendo publishes source archives per product and system version under licences including LGPL 2.1 and MPL 1.1.

Why are game consoles hard to hack now?

Keys stay inside the SoC, every boot stage is verified, memory and storage outside the chip are treated as untrusted, storage is encrypted with per console keys and rollback is blocked in hardware.

Can a console's boot ROM be updated?

No. Boot ROM is mask ROM fixed when the chip is made, so a flaw in it is fixed only in new silicon, as the 2018 record for CVE-2018-6242 in some older Tegra processors illustrates.

Where Safeguard fits, honestly

Safeguard does not analyse console hardware, scan firmware images, generate hardware bills of materials, manage devices or protect endpoints, and its models are single purpose security models, not tools for chip design, electronics or manufacturing. Nothing in this post about silicon, fuses or factory steps is something Safeguard does.

The fit is the software that teams build around devices like these: companion apps, online services, store and matchmaking backends, update servers, build containers and the open source libraries in all of them. The components listed on the console makers' own notice pages, such as browser engines and media frameworks, are the same kinds of libraries that run in those services. Safeguard scans repositories, container images and SBOM files for known vulnerable components with safeguard scan --dir ., safeguard scan --image <name> and safeguard scan --sbom <file>, shows which projects contain a given component and version, applies policies and gates, and can open fix pull requests for dependency upgrades when you turn autonomous remediation on (it ships switched off). The console makers' system updates, SoC firmware and closed drivers still have to come from them.

A console's own update can be perfect while the services it talks to ship a vulnerable library on every build. The remediation habits that keep a backend patched apply to the open source inside game servers, launchers and companion apps.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository; the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval and pushes nothing. The same flow fits a game companion app, a launcher or a store backend your team maintains.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. That suits a studio or platform team that builds game servers or update services on its own build hosts and wants the scan to run where the build runs.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. If your team already asks Claude about its projects, this is how the same conversation can look up which projects carry a vulnerable component when an advisory names a media library or browser engine your services depend on.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• Microsoft Learn, Microsoft Pluton security processor
• Microsoft Security blog, Meet the Microsoft Pluton processor: the security chip designed for the future of Windows PCs (17 November 2020)
• Xbox Wire, Xbox Series X: A Closer Look at the Technology Powering the Next Generation (16 March 2020)
• PlayStation Blog, Unveiling New Details of PlayStation 5: Hardware Technical Specs (18 March 2020, updated)
• PlayStation, PS5 system software update
• PlayStation, Source Code for Open Source Software Used in PlayStation 5
• Nintendo, Open Source Software source code distribution page
• Platform Security Summit, Tony Chen, Guarding Against Physical Attacks: The Xbox One Story (video, 21 October 2019)
• Microsoft Security Response Center, BlueHat Seattle 2019, Guarding Against Physical Attacks: The Xbox One Story (video, 30 October 2019)
• 22C3, 17 Mistakes Microsoft Made in the Xbox Security System & Xbox 360 Hacking (December 2005)
• 27C3, Console Hacking 2010: PS3 Epic Fail (29 December 2010)
• NIST NVD, CVE-2018-6242 (via the NVD API)
• NIST, SP 800-193, Platform Firmware Resiliency Guidelines (May 2018)
• IETF, RFC 6979, Deterministic Usage of DSA and ECDSA (August 2013)
• NVM Express, Specifications
• FCC, FCC ID Search
• US Copyright Office, Rulemaking Proceedings Under Section 1201 of Title 17
• Federal Register, Exemption to Prohibition on Circumvention of Copyright Protection Systems for Access Control Technologies, 89 FR 85437 (28 October 2024)
• Federal Register, Exemptions To Permit Circumvention of Access Controls on Copyrighted Works, 91 FR 34795 (9 June 2026)
• European Commission, Directive on repair of goods
• Publications Office of the EU, Directive (EU) 2024/1799 record
• European Commission, Cyber Resilience Act: summary of the legislative text

Last reviewed: 24 October 2026.