Glossary

MRSIGNER

A cryptographic hash of the public key used to sign an enclave's authorizing certificate, allowing attestation verifiers to establish trust based on the software vendor's identity rather than a specific code version.

Get in touch Learn more

Operations team reviewing AI vendor onboarding platform on laptop, forms and contracts visible, casual office workspace.

Enclave Signer Identity

What is MRSIGNER?

MRSIGNER is a cryptographic hash of the public key used to sign an enclave's authorizing certificate, enabling attestation verifiers to establish trust based on the software vendor's identity rather than a specific code version.

MRSIGNER is a cryptographic measurement that identifies the signing authority—typically the software vendor or development team—responsible for an enclave's authorizing certificate. Unlike MRENCLAVE, which changes with every code modification, MRSIGNER remains constant across all enclaves signed by the same private key, enabling verifiers to establish trust based on the software vendor's identity rather than a specific binary hash.

During remote attestation, a relying party evaluates MRSIGNER to determine whether the enclave was produced by a trusted source. This allows for version-flexible trust policies: an organization can whitelist all enclaves signed by an approved vendor without updating attestation policies for each software update, simplifying confidential computing deployment management while maintaining cryptographic assurance of provenance.

IDENTITY-BASED ATTESTATION

Key Characteristics of MRSIGNER

MRSIGNER shifts the trust model from verifying a specific code version to verifying the software vendor's identity. This cryptographic primitive enables seamless updates without re-attestation.

Vendor Identity, Not Code Identity

Unlike MRENCLAVE, which binds trust to an exact binary hash, MRSIGNER binds trust to the public key of the software vendor. This allows verifiers to trust any enclave signed by a specific authority, decoupling security policy from specific build artifacts.

Seamless Software Updates

Because MRSIGNER does not change when code is patched (as long as the signing key remains the same), organizations can deploy security patches and version updates without updating their attestation policies. This is critical for maintaining operational agility in production environments.

The Signing Enclave Hierarchy

MRSIGNER is derived from the hash of the public key that signs the Enclave Authoring Certificate. This creates a chain of trust: the hardware root verifies the provisioning key, which certifies the signing key, which authorizes the enclave developer.

Attestation Policy Flexibility

Verifiers can implement allowlisting by MRSIGNER values to permit any enclave from a trusted Independent Software Vendor (ISV). This enables a single policy rule—'trust all binaries from Vendor X'—rather than managing a whitelist of hundreds of individual MRENCLAVE hashes.

Intel SGX DCAP Integration

In the Intel Data Center Attestation Primitives (DCAP) framework, MRSIGNER is a primary claim in the attestation quote. Verifiers use the MRSIGNER value to query the Provisioning Certification Service and validate the signing certificate chain before trusting the enclave.

Multi-Vendor Trust Models

Complex confidential applications often combine enclaves from multiple vendors. MRSIGNER allows a verifier to establish a composite trust policy, trusting a database engine from one MRSIGNER and a machine learning runtime from another, all within a single attestation decision.

ATTESTATION IDENTITY COMPARISON

MRSIGNER vs. MRENCLAVE

A comparison of the two primary measurement values used in Intel SGX remote attestation to establish enclave identity and trust.

Feature	MRSIGNER	MRENCLAVE
What it measures	Hash of the enclave author's public key	Hash of the enclave's code and initial data
Identity granularity	Software vendor or signing authority	Exact binary version of the enclave
Update tolerance
Trust model	Trust in the vendor's signing key	Trust in a specific, immutable code build
Policy flexibility	Allows any enclave signed by the same key	Locks policy to a single, precise measurement
Typical use case	Production deployments requiring seamless updates	High-security environments requiring strict immutability
Revocation mechanism	Key revocation by the vendor	Requires policy update for each new build
Collision resistance	Dependent on the signing key's security	Dependent on the enclave's content uniqueness

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.

Enterprise searchRAGPermissions

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.

AI agentsWorkflow automationGovernance

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.

AI integrationDecision supportModel routing

MRSIGNER ATTESTATION

Frequently Asked Questions

Common questions about the MRSIGNER identity, its role in enclave attestation, and how it differs from MRENCLAVE for establishing trust in confidential computing environments.

MRSIGNER is a cryptographic hash of the public key used to sign an enclave's authorizing certificate, serving as a hardware-enforced identifier of the software vendor or signing authority. Unlike MRENCLAVE, which identifies a specific binary build, MRSIGNER allows attestation verifiers to establish trust based on who signed the enclave rather than the exact code version. During Intel SGX attestation, the CPU generates a signed report containing both the MRSIGNER and MRENCLAVE values, enabling a relying party to verify that the enclave was produced by a trusted vendor—such as a specific ISV or cloud provider—without needing to whitelist every individual build hash. This abstraction is critical for Confidential Computing deployments where software updates occur frequently, as it decouples identity from the precise code measurement.

ATTESTATION ECOSYSTEM

Related Terms

Core concepts that interact with MRSIGNER to establish a complete hardware-rooted trust chain in confidential computing environments.

MRENCLAVE

A cryptographic hash representing the exact identity of the code and initial data loaded into an Intel SGX enclave. While MRSIGNER identifies the software vendor, MRENCLAVE identifies the specific software version. Verifiers use MRENCLAVE to enforce strict binary-level whitelisting, ensuring only a precise, audited build can access secrets. Any code change—even a single byte—produces a completely different MRENCLAVE value.

SHA-256

Hash Algorithm

Remote Attestation

The protocol by which an enclave proves its identity and integrity to a remote relying party. The process involves:

The enclave generating a cryptographic report containing its MRSIGNER and MRENCLAVE values
The hardware signing this report with a provisioning key rooted in the platform's Hardware Root of Trust
The verifier checking MRSIGNER against a trusted vendor list before provisioning secrets or trusting outputs

EXPLORE

Enclave Measurement

The process of computing a cryptographic hash over the initial state of an enclave before execution begins. This measurement captures:

The enclave's code pages
Static data and configuration
Stack and heap initialization parameters

The measurement is stored in hardware registers and becomes the foundation for both local attestation (enclave-to-enclave on the same platform) and remote attestation (enclave-to-remote-verifier).

Data Sealing

A mechanism that cryptographically binds data to an enclave's identity so it can be securely persisted to untrusted storage. Sealing policies can be tied to:

MRSIGNER: Any enclave signed by the same vendor can unseal (enables seamless upgrades)
MRENCLAVE: Only the exact same enclave version can unseal (maximum security, breaks on update)

This allows enclaves to maintain state across restarts without exposing secrets to the host OS.

DCAP

Intel's Data Center Attestation Primitives framework enables organizations to run their own attestation infrastructure without depending on Intel's cloud-hosted service. Key components include:

Provisioning Certification Caching Service: Caches PCK certificates locally
Quote Verification Library: Validates attestation quotes in-process
Flexible policy engine: Allows custom MRSIGNER trust lists

DCAP is essential for air-gapped environments and organizations requiring full attestation sovereignty.

EXPLORE

Hardware Root of Trust

A physically immutable, tamper-resistant hardware module that serves as the foundational trust anchor for the entire attestation chain. In Intel SGX, the root of trust is fused into the CPU during manufacturing. It anchors:

The provisioning key that signs attestation reports
The sealing key derivation hierarchy
The platform's unique, unforgeable cryptographic identity

Without a hardware root of trust, MRSIGNER verification would be vulnerable to software-based spoofing.

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.

Limited slotsGet a Free AI Consultation

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.