A Platform Configuration Register (PCR) is a shielded memory location within a Trusted Platform Module (TPM) that cryptographically stores integrity measurements of platform components. Unlike standard memory, PCRs cannot be arbitrarily written; values are updated exclusively through a process called extending, where a new measurement hash is concatenated with the existing PCR value and rehashed. This append-only mechanism creates a tamper-evident log that captures the exact sequence of software and firmware loaded during boot, forming the foundation for measured boot and remote attestation.
Glossary
Platform Configuration Register (PCR)

What is Platform Configuration Register (PCR)?
A Platform Configuration Register (PCR) is a shielded memory location within a Trusted Platform Module (TPM) that cryptographically stores integrity measurements of platform components to prevent falsification.
PCRs enable critical security operations such as sealing, where data is encrypted to a specific PCR state and only decryptable when the platform reaches that exact configuration. During remote attestation, the TPM signs a quote of selected PCR values with an Attestation Identity Key (AIK), allowing a remote verifier to cryptographically assess the platform's trustworthiness. Standard PCR allocations follow TCG specifications, with PCRs 0-7 reserved for firmware measurements, PCRs 8-15 for operating system components, and PCR 16 for debug configurations, ensuring consistent interpretation across implementations.
Key Characteristics of PCRs
Platform Configuration Registers (PCRs) are the shielded memory locations within a TPM that form the cryptographic backbone of system integrity measurement. They enforce a strict, append-only logging mechanism that prevents falsification of boot and runtime state.
Append-Only Measurement Model
PCRs do not support arbitrary write operations. New measurements are combined with the existing value using a cryptographic hash extension: PCR_New = Hash(PCR_Old || Digest_New). This one-way, monotonic process ensures that no entity can overwrite a measurement to hide a compromise. The sequence of extensions mathematically encodes the entire event history, making it impossible to forge a 'clean' state without replaying every legitimate event.
Standardized Bank Allocation
The TCG PC Client Platform Firmware Profile specification defines 24 PCRs (index 0-23) with fixed roles:
- PCR 0: Core System Firmware (BIOS/UEFI)
- PCR 1: Host Platform Configuration
- PCR 2-3: Option ROM Code
- PCR 4: Initial Program Loader (IPL) Code
- PCR 5: IPL Configuration
- PCR 7: Secure Boot Policy
- PCR 10: Integrity Measurement Architecture (IMA) for Linux
- PCR 23: Application-specific measurements
Cryptographic Hash Algorithms
A single PCR index can store multiple digests simultaneously in distinct hash banks. A TPM 2.0 must support SHA-256 and may support SHA-384, SHA-512, or SM3. When a measurement is extended, the TPM computes the hash for all active banks in parallel. This allows a verifier to request a quote using its preferred algorithm, enabling interoperability across different security policies without re-measurement.
Sealing and Policy Binding
PCRs enable sealing, a cryptographic operation that encrypts data (like a disk decryption key) to a specific platform state. The TPM will only release the sealed data if the current PCR values match a policy-defined set. This binds secrets to a known-good configuration. For example, a BitLocker key can be sealed to PCRs 0, 2, 4, and 11, ensuring it is only released if the firmware, option ROMs, boot manager, and kernel are unmodified.
Remote Attestation Quoting
A remote verifier challenges a platform to prove its integrity. The TPM signs a quote—a cryptographically authenticated snapshot of selected PCR values—using an Attestation Identity Key (AIK). The quote includes a nonce to prevent replay attacks. The verifier compares the signed PCR digest against a reference database of known-good values to determine if the platform is in a trusted state before granting network access or deploying workloads.
Event Log Correlation
PCR values alone are opaque hashes. To reconstruct the measurement history, the platform maintains a TCG Event Log in system memory. Each entry records the PCR index, the extended digest, and a human-readable description of the measured component. During attestation, the verifier replays the event log to recompute the expected PCR value. If the recomputed hash matches the signed quote, the log is proven authentic and provides granular forensic detail.
Frequently Asked Questions
Clear, technical answers to the most common questions about Platform Configuration Registers, their role in measured boot, and how they enable remote attestation and data sealing in a Trusted Platform Module.
A Platform Configuration Register (PCR) is a shielded memory location within a Trusted Platform Module (TPM) that stores integrity measurements in a way that prevents falsification. Unlike standard memory, a PCR cannot be written to directly; it can only be updated through a cryptographic process called an extend. An extend operation takes the current PCR value, appends a new measurement hash, hashes the concatenation (SHA-256 or stronger), and stores the result. This one-way, append-only mechanism creates a cryptographically verifiable log of system state transitions. The formula is: New PCR Value = Hash(Old PCR Value || Hash of New Data). This ensures that the final PCR value represents the cumulative history of all measurements, making it impossible to forge a clean state if a malicious component was ever loaded.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Platform Configuration Registers are the cryptographic anchors for platform integrity. These related concepts define how PCRs are extended, quoted, and used to enforce security policies.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us