Extended validation

Extended Validation (EV) SSL/TLS certificates represent the highest level of identity assurance available in the public PKI ecosystem. Before a Certificate Authority (CA) issues one, your organization goes through a structured vetting process that confirms legal existence, physical address, operational status, and the authority of the person requesting the certificate. The result is a certificate that binds a domain to a verified legal entity, not just to whoever controls the DNS record.

What Extended Validation Actually Verifies

EV issuance is governed by the CA/Browser Forum EV Guidelines. Every CA that issues publicly trusted EV certificates must follow the same baseline requirements. The vetting process covers five distinct checks:

This is meaningfully different from Organization Validation (OV), which confirms legal existence and domain control but does not require the same depth of documentation or the applicant authority check.

EV vs. OV vs. DV: Where the Differences Actually Matter

Domain Validation (DV) certificates verify only that you control a domain. They are issued in minutes, often automatically via ACME protocol. OV certificates add a layer of organizational identity, but the validated data is embedded in the certificate's Subject fields and not always surfaced to end users in a meaningful way.

For Canadian fintech companies operating under FINTRAC oversight or offering payment services subject to PSD2-equivalent frameworks, EV certificates signal to counterparties and auditors that identity verification happened before the certificate was issued. That is not a marketing claim - it is documented in the certificate's certificatePolicies extension, which contains the EV OID (Object Identifier) specific to the issuing CA.

How the EV OID Works Technically

Every EV certificate contains a certificatePolicies extension with one or more OIDs. Browsers and relying-party software use these OIDs to classify a certificate as EV-qualified. For example:

• DigiCert EV OID: 2.16.840.1.114412.2.1
• Sectigo EV OID: 1.3.6.1.4.1.38897.1.1
• GlobalSign EV OID: 1.3.6.1.4.1.4146.1.1

When a browser's root store recognizes an EV OID from a trusted CA, it previously triggered the green address bar. Modern browsers (Chrome 77+, Firefox 70+) removed the green bar UI treatment, but the OID data remains in the certificate and is readable by:

• TLS inspection appliances used by enterprise security teams
• Compliance monitoring tools
• API clients that perform certificate pinning with identity validation
• eIDAS-compliant relying party software in the European context

So the practical value of EV has shifted from a consumer-facing visual signal to a machine-readable identity assertion that matters in B2B, regulated, and cross-border contexts.

eIDAS, PSD2, and Why EV Matters for Canadian Fintechs

The eIDAS Regulation (EU No 910/2014) and its updated version eIDAS 2.0 define Qualified Website Authentication Certificates (QWACs) as the EU standard for high-assurance website identity. QWACs are, structurally, EV certificates with additional EU-specific extensions. If a Canadian fintech is:

• Processing payments involving European cardholders
• Operating as a Third Party Provider (TPP) under PSD2
• Seeking to connect to EU Open Banking APIs

then EV-level validation is the floor, not the ceiling. Many EU banks and Payment Service Providers (PSPs) check for QWAC or EV OIDs when validating incoming mTLS connections. A DV or OV certificate will fail those checks silently or visibly depending on the implementation.

Under Canada's own digital identity and open banking framework, which the Department of Finance has been developing since the 2022 open banking consultations, the expectation is moving toward FAPI (Financial-grade API) security profiles. FAPI 2.0 requires mTLS for sender-constrained tokens, and the identity of the certificate holder becomes a factor in access authorization. EV certificates fit into this model directly.

The Vetting Process Step by Step

Understanding the timeline helps organizations plan deployments without delays:

1. Submit the Certificate Signing Request (CSR) with complete organization details
2. CA sends a verification questionnaire - respond with articles of incorporation, government-issued registration number
3. CA makes a Verified Professional Letter (VPL) request or calls a verified phone number listed in a third-party directory (not a number you provide)
4. Applicant authority verification - CA confirms via HR records, legal attestation, or a notarized letter that the requester is authorized
5. Domain control validation - standard methods (email, DNS CNAME, or file-based)
6. Final review by the CA's vetting team
7. Certificate issued and delivered

Steps 3 and 4 are where most delays happen. Having your legal registration documents, corporate registry number, and an authorization letter from a C-level officer ready before submission reduces issuance time from 10 days to closer to 3-4.

Certificate Lifetime and Renewal Planning

As of March 2026, the CA/Browser Forum has adopted a phased reduction in maximum TLS certificate lifetime:

EV certificates are subject to the same lifetime limits as DV and OV. This means EV certificates will require more frequent renewal - and more frequent re-vetting - as lifetimes shorten. Organizations should plan for automation-assisted renewal workflows even for EV, though the identity verification steps cannot be fully automated and will still require human action at the CA vetting stage.

Where EV Certificates Are Appropriate in 2026

Not every HTTPS endpoint needs EV. The decision depends on who is connecting and what they need to verify:

Strong candidates for EV:

• Customer-facing login portals for financial services platforms
• Payment processing pages and checkout flows
• Investor relations portals with document access
• Open banking API gateway endpoints where counterparty identity matters
• Government contractor portals
• Cross-border B2B platforms exchanging sensitive data

Cases where EV is unnecessary:

• Internal-only applications behind a VPN
• Static marketing pages with no authentication
• Microservices communicating within a private network
• Development and staging environments

A practical heuristic: if a counterparty's legal or compliance team might inspect your certificate during due diligence, use EV. If the only consumer is a browser user clicking through a public marketing page, OV is sufficient.

Multi-Domain EV Certificates and SANs

EV certificates support Subject Alternative Names (SANs), meaning one certificate can cover multiple domains. However, each SAN must pass the full EV vetting process. You cannot add a domain owned by a different legal entity to your EV certificate, even within a corporate group, unless that entity's details are separately verified.

Typical SAN configurations for Canadian organizations using EV:

• bank.example.ca + secure.example.ca + api.example.ca (same legal entity, different subdomains or domains)
• Wildcard SANs are not permitted under EV guidelines - each hostname must be explicitly listed

This is a deliberate design choice. Wildcards would undermine the identity binding, since any subdomain under *.example.ca would inherit the EV assertion without individual verification.