How to Enroll a Code Signing Certificate in Sectigo Certificate Manager

If you’ve been asked to get code signing certificates working inside Sectigo Certificate Manager (SCM) for your organization, the interface can feel scattered the first time through. The steps aren’t hard individually, but they live in different menus, and missing one breaks the chain. I’ve set this up for teams ranging from a two-person dev shop to enterprise release engineering groups, and the failure points are almost always the same: a profile that was never delegated, or a CSR submitted in the wrong format.

This guide walks through the full enrollment path in the order SCM actually expects it, not the order the UI happens to display it.

What You Need Before You Start

Enrollment in SCM breaks if any of these are missing, so confirm them before opening the console.

Administrator access with the MRAO role. Only a Master Registration Authority Officer can create certificate profiles and delegate them to an organization. If you’re a developer requesting a certificate but don’t have this role, you’ll need someone on your security or IT team to complete the setup steps first.

A CSR generated in PEM format. SCM will reject a CSR submitted in any other encoding. If your build tooling generates DER by default, convert it before you get to the submission step, trying to fix this mid-enrollment just wastes a cycle.

Confirmation of Key Attestation requirements. Some accounts require hardware-backed key attestation before a code signing certificate can be issued, tied to the CA/Browser Forum’s private key protection rules. If this applies to your account, get the attestation file ready in advance.

OV or EV validation completed, if applicable. Extended Validation code signing certificates carry additional organization checks that need to be finished before the certificate request goes anywhere. Don’t wait until submission to find out your EV validation is still pending.

Step 1: Create a Certificate Profile

The certificate profile is the template that governs everything downstream, issuance rules, validation level, validity period. Nothing can be requested until this exists.

1. Log in to SCM as an MRAO administrator.
2. Go to Enrollment → Certificate Profiles.
3. Click Add to start a new profile.
4. Fill in the required fields:
   • Name — something your team will recognize later; avoid generic labels if you’ll be managing multiple profiles
   • CA Backend — the certificate authority backend handling issuance
   • Certificate Type — select Code Signing Certificate
   • Template — Organization Validation (OV) or Extended Validation (EV)
   • Terms — the validity period for certificates issued under this profile
5. Click Save.

A mistake I see often: teams create a profile with the wrong template and don’t catch it until a requester’s certificate comes back at the wrong validation level. Double-check the Template field before saving, it’s not something you want to redo after certificates are already in circulation.

Step 2: Delegate the Profile to Your Organization

A saved profile does nothing on its own. Until it’s assigned to an organization, no one can request a certificate against it.

1. Go to Organization → Certificate Settings.
2. Enable code signing certificates for the organization.
3. Assign the profile you created in Step 1.

Skip this step and requesters will hit a dead end with no obvious explanation, the profile exists, but SCM has no path connecting it to anyone who can use it. This is the single most common reason enrollment stalls before it starts.

Step 3: Configure the Code Signing Enrollment Form

This is the piece your requesters will actually interact with. It’s what generates the URL they’ll use to submit their certificate request.

1. Go to Enrollment → Enrollment Forms.
2. Click Add (+) to create a new form.
3. Set the following:
   • Type — Code Signing Certificate Enrollment Form
   • Generate URL Extension — enable this so SCM produces a unique enrollment link
   • Authentication — choose Email Confirmation or Secret ID

Email Confirmation works well for most managed environments since it ties the request to a verified inbox without extra coordination. Secret ID is worth using when you’re distributing enrollment through a channel where email verification isn’t practical, a shared onboarding document, for instance.

4. Click Save.

Step 4: Add the Form to an Account and Send the Invitation

With the form built, it needs to be tied to an actual account before anyone can enroll through it.

1. Select the form you just created.
2. Click Accounts, then Add (+).
3. Enter the account details for the person or team requesting the certificate.
4. Assign the certificate profile from Step 1 to this account.

Once this is saved, the requester receives an invitation containing the enrollment URL. They don’t need SCM admin access, they just need the link and, depending on your authentication setting, either a confirmation email or the Secret ID you’ve distributed.

Step 5: Submit the CSR and Complete Enrollment

This is the requester-facing half of the process, and it’s where most of the prerequisite items from earlier actually get used.

1. The requester opens the enrollment URL from their invitation.
2. They complete authentication (email confirmation or Secret ID, per your Step 3 setup).
3. They submit their CSR in PEM format, along with a Key Attestation file if your profile requires one.
4. The request moves into validation.

Turnaround from here depends on validation level. OV requests typically clear faster since the organization checks were likely completed during account setup. EV requests can take longer if any extended validation items are still outstanding — which is exactly why confirming validation status before submission (back in the prerequisites) saves time here.

Once approved, the requester gets a notification with instructions to download and install the certificate, after which it’s ready for signing.

Alternative Enrollment Methods Beyond the Self-Enrollment Form

The form-based path covers most individual and small-team scenarios, but SCM supports three other methods worth knowing about if you’re scaling this beyond manual requests.

REST API. Useful if you want to trigger certificate requests programmatically, for example, as part of an internal provisioning tool rather than having someone fill out a form.

Admin API. Built for administrative operations at scale, including OAuth 2.0-based integration. This is the route to look at if you’re managing certificate lifecycle across a large number of accounts and don’t want to touch the SCM console for every change.

CA connector. Routes enrollment through a third-party CA connector configured in SCM, rather than SCM issuing directly. Relevant mainly for organizations with existing CA relationships they need to preserve.

For most teams setting this up for the first time, the form is the right starting point. The API routes make more sense once you’ve got enrollment volume that justifies building automation around it.

OV vs. EV Code Signing Enrollment: What Actually Changes

The difference shows up at two points in this process, not just in the certificate name.

At the profile level, the Template field in Step 1 determines which validation path a request under that profile follows. OV and EV can’t share a profile, if you need to issue both, you’ll need separate profiles.

At the validation stage, EV requires completed organization and extended validation checks before a request can even be submitted through the enrollment form. OV’s validation requirements are lighter, which is why OV requests generally move faster once submitted.

If your organization needs both certificate types, plan for two full setups — separate profiles, potentially separate enrollment forms, rather than trying to force one profile to cover both.

Common Enrollment Errors and How to Avoid Them

After running this process more times than I can count, these are the mistakes that come up repeatedly:

Missing Key Attestation. If your account requires it and the requester submits without the attestation file, the request stalls. Confirm this requirement before you even build the enrollment form, and communicate it clearly in whatever instructions you send along with the invitation.

Incomplete EV validation before submission. Requesters sometimes submit an EV request assuming validation happens after the fact. It doesn’t, the organization and extension validation needs to be done first, or the request just sits.

CSR format mismatches. DER instead of PEM is the most common version of this. If your team’s build environment defaults to a different encoding, document the conversion step so it’s not a surprise every time.

Role and permission gaps. Someone without the MRAO role trying to create a profile, or a requester account that was never properly delegated in Step 2 — both produce confusing dead ends rather than clear error messages. When enrollment seems stuck, checking permissions is often faster than troubleshooting the request itself.

Frequently Asked Questions

What role do I need to enroll code signing certificates in Sectigo? Creating certificate profiles and delegating them to an organization requires the Master Registration Authority Officer (MRAO) role. Requesters submitting through an enrollment form don’t need SCM admin access at all.

Why is Key Attestation required before code signing enrollment in SCM? Some accounts require proof that the private key is generated and stored on a hardware-backed device, in line with CA/Browser Forum private key protection requirements for code signing certificates. If your account has this requirement, the attestation file must be submitted alongside the CSR.

How long does code signing certificate issuance take after CSR submission? It depends on validation level. OV requests generally clear faster since organization checks are usually already complete. EV requests can take longer if extended validation items are still pending at submission time.

Can I enroll a code signing certificate through the API instead of the form? Yes. SCM supports REST API and Admin API enrollment alongside the self-enrollment form and CA connector option. The API routes are better suited to programmatic or large-scale provisioning than one-off requests.

Next Steps After Enrollment

Once your certificate is issued, downloading and installing it is only the first half of getting productive. From there, you’re into signing tool configuration — SignTool, KSP libraries, or whatever your build pipeline uses to actually apply signatures to your binaries.

If your enrollment involves a Key Attestation requirement or a hardware-backed key, confirm your signing environment is set up to work with that key storage before your first production signing run. Getting this wrong after certificates are already issued costs more time than catching it here.