​​What Is SEAL Certification?

Most crypto losses no longer start in a contract. They start with a signer, a domain registrar, a CI pipeline or a support inbox. SEAL Certifications is an operational security framework for digital asset issuers and protocols, and Hacken is now certifying against it.

What is SEAL certification?

SEAL certification is an operational security certification for crypto protocols, maintained by the Security Alliance (SEAL).

The framework is open source. SEAL maintains it and accredits the auditing firms; the accredited assessor performs the review, and SEAL issues the certification on-chain. It has been refined through pilot analyses, protocols, and feedback from auditing firms and independent researchers.

What it assesses is whether your organisation can defend itself, detect an incident and respond when something goes wrong. That means people, processes, accounts and infrastructure: the layer a code audit structurally does not look at.

Three things it is not. It's not a penetration test. It's not a code review. And the attestation does not say a protocol is free from security issues, only that a defined set of operational controls was assessed and found to be in place.

What does SEAL cover?

SEAL consists of six modules, each independently scopeable. During scoping, you and the assessor agree which controls and which systems apply to your architecture.

SEAL vs CCSS standards

Isn't this CCSS with a new logo? In fact, they barely overlap.

CCSS goes deep on cryptographic asset management, where six of its nine aspects cover key generation, wallet creation, storage, usage, compromise policy, and keyholder grant and revoke. If you hold customer assets, you probably would want to maintain a CCSS certificate.

SEAL is wider instead. It covers the domain registrar, the pipeline (GitHub, server, npm, frontend buckets, etc.), the email, Slack, cloud console, X accounts with privileges, and the documented plan in case of an exploit. Just reminding you that CCSS is almost entirely about keys and how you make, store, use them; and what to do in case of a leak. 

In conclusion, SEAL cannot substitute CCSS, and CCSS is not the same as SEAL. Instead, they complement each other well, assessing different scopes that interest different counterparties. 

What does the SEAL certification flow look like?

SEAL Certification happens in five steps:

1. Scoping. You and the assessor define the applicable modules, controls and infrastructure based on your architecture and operating model.
2. Evidence collection. You provide documentation and proof: signer registries, playbooks, configuration records, logs, screenshots, interviews. 
3. Assessment. The assessor evaluates whether each control exists, is documented and is operating as described (it’s not a pentest!).
4. Remediation. The assessor reports gaps, you fix them. The auditor reassesses.
5. Certification. Congrats, you now meet the standard, and SEAL issues you a public, cryptographically verifiable on-chain attestation through the Ethereum Attestation Service.

In the end, you get a detailed, public report, while evidence stays confidential between you and the assessor.

Who needs a SEAL Certificate?

Good fit today:

• Protocols and DAOs with a treasury under multisig control.
• Teams whose last incident, or last near-miss, was connected to operations or dependencies.
• Anyone whose institutional diligence calls have started including questions about signer devices, MFA and who can change a DNS record.
• Teams that buy audits regularly and keep collecting the same operational findings in the appendix.
• Post-incident teams that need to show counterparties the fix was structural rather than a patch.

Poor fit today:

• Pre-launch, no treasury, no production infrastructure. Self-assess against the open framework and come back when there's something to assess.
• Custodial businesses that are more in need of CCSS, SOC 2 or ISO 27001. 

You can generally self-assess by:

1. Pulling the controls from the framework. Put them onto a sheet.
2. Cutting the scope that doesn’t apply to your organisation. Some controls probably won’t apply to you and it’s okay.
3. Naming every control owner that remains. Who is responsible for this and that in the framework.
4. Showing evidence of controls. For example, do you have a confirmation that you enforced MFA for all accounts? Usually, you will find out the nuances there
5. Discovering if work is assessed from a second perspective. For example, you have a CI pipeline, and a person who built it says it’s fine (obviously). But, in fact, you have nothing to show that it was properly assessed. Ideally, there must be a second opinion within a team assessing work deliverables.
6. Finding out what your status is: based on the sheet, you know what is okay-ish and what needs to be improved to SEALtify. 

What do you need to qualify?

To qualify for certification, you need to pass on every applicable control. 

Certification is issued when:

• Every control in the agreed scope is rated Implemented, or N/A with documented justification.
• Evidence substantiates each implementation claim.
• Your overall operational security posture meets the framework's requirements.
• Anything rated Partially Implemented or Not Implemented has been remediated and verified.

In practice, this means that SEAL wants evidence that you follow documented policies and produce logs of controls in action. Everything less counts as partial implementation and needs remediation.

Heads-up: SEAL Certifications are time-limited and require periodic reassessment. And they can be revoked if a protocol stays non-compliant for an extended period.

How to get started with SEALtification

Hacken is accepting SEAL Certification clients under SEAL's auditor accreditation program. 

The path is short:

1. Engage Hacken to define the certification scope and the evidence plan.
2. Close identified gaps and complete remediation verification.
3. Meet the standard and receive the on-chain SEAL attestation.

You can also start with self-assessment from above.