What Is SEAL Certification? Operational Security Assurance for Crypto

SEAL Certifications is an open-source operational security certification program published by Security Alliance (SEAL). Its current baseline organizes 99 specific operational requirements, referred to as controls, across six modules covering the people, accounts, signers, domains, infrastructure, treasury processes, and response capabilities around a crypto protocol [1, 2].

BlockSec is part of the first cohort of SEAL-accredited assessors. As a SEAL-accredited assessor, we define the scope with the client, assess the selected controls and evidence, document gaps, and determine whether the scoped requirements have been met. When the scoped requirements and applicable SEAL review and recognition requirements are met, we issue the on-chain attestation under our SEAL accreditation [4].

This article explains why an organization may pursue SEAL certification, what the resulting certification means, which modules may apply, how we conduct the assessment, and how a team can prepare for an engagement.

1. Why pursue SEAL certification

SEAL's rationale for the framework is that crypto's primary source of exploits has shifted from smart-contract vulnerabilities to operational failures [1]. For an assessment, that shifts attention to the controls around signers, multisigs, domains, credentials, infrastructure monitoring, and incident response. A SEAL certification assessment asks whether those controls operate in practice and can be substantiated, giving crypto organizations an independent view of which controls meet the baseline and where gaps remain [1, 3].

SEAL certification answers one assurance question: have the operational controls within an agreed scope been independently assessed and found to meet a public, crypto-native operational security baseline? Crypto organizations such as protocols, exchanges, payment platforms, and custodians may need this assurance when investors, listing teams, compliance stakeholders, internal governance bodies, insurers, or due-diligence reviewers ask for independent evidence of their operational controls. The result names the modules and boundaries assessed and records whether that scope met the baseline [5, 6].

The scope of that assurance becomes clearer when compared with adjacent security activities. The assessment may examine code-related operational evidence for repository, CI/CD, and infrastructure controls: permissions, branch-protection settings, code-review records, security-scan results, pipeline controls, and infrastructure configurations [7]. It does not review source code to find implementation vulnerabilities or determine whether protocol logic is correct [1]. The table below compares SEAL certification with Code Audit and Penetration Testing.

These services address different assessment objectives. Testing can provide evidence for some SEAL controls, but an audit or penetration test does not by itself establish SEAL certification.

SEAL certification is a standalone assessment program. Certification is issued only when the selected scope meets SEAL's requirements [6]. Code Audit and Penetration Testing are separate activities; neither is a prerequisite for certification.

The same distinction applies to broader assurance standards. According to SEAL's request-for-comments post, SOC 2 and ISO 27001 remain valuable and will ultimately be necessary for many organizations, but they were not designed around crypto-specific operating models such as small distributed teams controlling substantial on-chain value [5]. The SEAL framework provides a more focused starting point for crypto operational controls and can sit alongside those broader standards.

2. What certification proves

A SEAL certification result applies to the operational controls, modules, and boundaries selected for the engagement. When the selected controls meet SEAL's requirements, a SEAL-accredited assessment firm, such as BlockSec, issues the on-chain attestation through the Ethereum Attestation Service, together with the applicable SEAL badge, under its accreditation [4]. The attestation is public; detailed assessment reports and evidence remain confidential between the assessment firm and the client [1]. The table separates the conclusions supported by a passing result from claims that remain outside its scope.

Those limits continue after issuance. A SEAL attestation does not indicate that a protocol is free from security issues [1]. It is time-limited, requires periodic reassessment, and may be revoked after sustained noncompliance; SEAL does not publish a fixed validity period [1].

3. What the framework covers

The six modules can be assessed individually or together. The current baseline contains 99 controls [1, 2]. The When it may apply column is an editorial guide based on the module definitions, not SEAL's official scoping rule; we confirm the final scope with the client during the engagement.

For more on the DNS & Registrar module, see Beyond the Smart Contract: Domain and DNS Operational Security in Web3.

The modules remain operationally connected even when assessed independently. Some controls in DevOps & Infrastructure and DNS & Registrar rely on account-security practices defined under Identity & Accounts. Incident-response requirements also appear in several modules, such as coordinating multisig signers or recovering accounts during an incident [2].

These cross-module references affect the evidence needed for an in-scope control; they do not automatically certify the referenced module, create a required certification order, or expand the engagement. A DNS & Registrar attestation does not become an Identity & Accounts attestation merely because a DNS control relies on account-security practices. The attestation applies only to the modules and boundaries named in its scope [1, 6].

4. How the assessment works

SEAL maintains the framework and operates the certification program. As a SEAL-accredited assessment firm, we conduct each client assessment in five steps [1, 4]:

Figure 1. A SEAL certification engagement moves from an agreed scope to evidence review, remediation, and reassessment before an attestation is issued.

1. Scoping. We work with the client to agree which modules, controls, systems, operations, and organizational boundaries are in scope.

2. Evidence collection. The client provides material showing how the in-scope controls are designed, assigned, operated, and reviewed.

3. Assessment. We evaluate that evidence against SEAL's published requirements and identify missing or insufficient support.

4. Remediation and Re-assessment. If the agreed scope does not meet the baseline, we provide a gap report. The client addresses the identified gaps and submits updated evidence for reassessment.

5. Certification. When the agreed scope meets the baseline, we issue the formal on-chain attestation under our SEAL accreditation.

Evidence collection and assessment work together: the client provides supporting materials, and BlockSec evaluates whether they demonstrate that each control operates in practice. SEAL's Certification Guidelines group supporting evidence into five categories, summarized below with examples from the guidelines and module baseline [2, 3, 7]:

Using that evidence, BlockSec records each in-scope control as Implemented, Partially Implemented, Not Implemented, or N/A with justification. Formal certification requires the controls in the agreed scope to be Implemented or justified as N/A, with evidence supporting the claims. The overall certification decision is therefore binary across the full agreed scope even though the underlying assessment remains control by control [3, 6].

5. How to prepare

Before starting a SEAL certification engagement, prepare four things:

1. A proposed scope: the modules, systems, entities, teams, and boundaries that matter to the intended certification claim.

2. A control-by-control self-assessment: which requirements appear Implemented, Partially Implemented, Not Implemented, or N/A, with the basis for each answer.

3. An evidence inventory: existing procedures, operating records, test results, ownership records, and technical artifacts mapped to the proposed scope.

4. Named participants: the people responsible for scope decisions, evidence collection, and remediation coordination.

Because the framework and checklists are public, a team can begin this work before a formal engagement. Self-assessment is useful for finding undocumented processes, missing operating evidence, unassigned controls, and known remediation work. It remains an internal checkpoint: it is not independently verified and does not produce a SEAL attestation [1, 3].

These four items support initial scoping; the detailed material request depends on the modules selected. The module names above define subject areas, not a required certification sequence. Dedicated articles will provide module-level control guidance as they are published. Please contact us at [email protected] to discuss module selection, evidence readiness, and engagement scope.

References

1. Security Alliance, SEAL Certification Framework: Overview.
2. Security Alliance, Export All Certifications (XLSX), available from the framework overview. Control counts and cross-module references also checked against the six published module pages in October 2026.
3. Security Alliance, Certification Guidelines.
4. Security Alliance, Auditor Accreditation; SEAL Certifications.
5. Security Alliance Radar, Request for Comments: SEAL Certifications.
6. Isaac Patka, Security Alliance Radar, SEAL Certifications: Now Open for Business (2 June 2026).
7. Security Alliance, SFC: DevOps & Infrastructure.