India's DSC Rules Changed Again in 2026. The Headline Everyone's Repeating Is Five Years Old.

The DSC story getting repeated this year is already five years old

Search for a "digital signature certificate (DSC) guide 2026" and most results open with the same line: Class 1 and Class 2 certificates have been phased out, and only Class 3 remains. It is true. It is also not 2026 news. The Controller of Certifying Authorities stopped issuing Class 2 certificates from 1 January 2021, folding their use cases into Class 3. Five years on, that fact keeps getting recycled into fresh-dated guides because it is an easy sentence to restate and it sounds current.

The genuine change this year sits somewhere else: in the Identity Verification Guidelines the CCA published in February 2026, and in a quieter shift in how the certificate itself gets issued and where its private key lives. For anyone maintaining a signing integration in India, that second part is the one worth reading closely, because it changes an assumption a lot of integrations were built on without ever writing it down.

What the 2026 guidelines actually changed: identity verification, not certificate classes

Identity Verification Guidelines version 2.5 formalises video-based verification, sometimes referred to as V-CIP, as the default route for individual Class 3 applicants. The applicant records a short video stating their name and a supplied code while holding their original identity documents to the camera. For most individual applications, this replaces the older requirement to appear in person before a registration authority.

This is a change to how a person proves who they are before a certifying authority issues them a key, not a change to what the certificate does once it exists. The class of certificate, the cryptographic standard behind it, and the trust chain back to a licensed CA are all unaffected. What compliance teams should take from this is narrower than the headlines suggest: issuance is faster because the verification is differently evidenced, not because the bar for identity assurance has dropped.

For teams that keep their own vendor-onboarding or KYC-audit records, the practical follow-up is knowing what evidence a CA now holds on file. Where an in-person appearance used to leave a signed physical form, a video-based verification leaves a video artefact and a liveness-check result retained by the CA rather than by you. If a dispute ever turns on how a signatory was verified, the CA is the party holding that record, and it is worth confirming your vendor agreement with the CA actually covers producing it on request rather than assuming it will be available.

The change that actually matters to engineering teams: certificates without a token

Until recently, "DSC-based signing" meant a private key stored on a USB cryptographic token, a physical dongle plugged into a machine. Most BYO-DSC integrations, including the .pfx-style flows built for bulk filings, board resolutions, and payroll sign-off, were designed around that shape: one certificate, one physical object, one machine at a time.

Licensed certifying authorities are now issuing Class 3 certificates where the private key is generated and held inside a certified cloud HSM rather than a token the applicant carries, and government portals including the Ministry of Corporate Affairs, the GST portal, and DGFT accept signatures produced this way alongside traditional token-based ones.

The certificate does not announce which kind it is. A Class 3 certificate is a Class 3 certificate in its X.509 fields regardless of where the key sits; the distinction lives in how the signer authenticates to release a signing operation, not in anything a standard certificate parser will flag for you.

Why this matters for a BYO-DSC or bulk-signing pipeline specifically

Bulk-sign workflows, whether that is a finance team clearing GST filings or a set of directors signing board resolutions at scale, were often designed with a fixed roster of signatories, each holding a physical token, each session requiring that token to be present at a known machine. Physical possession quietly did double duty as a proxy for signer intent.

Cloud-hosted certificates remove the requirement for a token to be physically present, which is genuinely useful for distributed teams and remote signing. It also removes the control some integrations were leaning on without naming it. The fix is not to try to detect where a key lives; there is no reliable way to do that from the outside, and it would be the wrong signal even if there were. The fix is to validate what the certificate and its surrounding evidence actually assert.

Three things are worth checking directly rather than inferring: the certificate chain resolves to a CCA-licensed certifying authority, the CA's own record of how the signer was authenticated for that specific signing operation is captured in your audit trail, and the signature carries a timestamp from a trusted source rather than relying on the signing machine's clock.

One concrete symptom to watch for: audit-trail schemas built for token-based signing often include a field for token serial number, populated by reading it off the connected hardware at signing time. A cloud-hosted signer has no token to read a serial number from, so that field starts arriving blank or null. Left unhandled, a monitoring dashboard built to flag "missing token serial" as an anomaly will start treating a growing share of entirely legitimate, correctly authenticated signatures as suspicious, which is a false-positive problem, not a security one, but it is exactly the kind of alert fatigue that gets a genuine anomaly ignored later.

# Walk the certificate chain inside a signed PKCS#7 blob or signed PDF
# and confirm which CA actually issued the signing certificate.

openssl pkcs7 -print_certs -in signature.p7s -inform DER -text \
  | grep -A2 "Issuer:"

# For a signed PDF, extract the embedded signature first:
pdfsig -dump document-signed.pdf ./extracted-signatures

openssl pkcs7 -print_certs -in extracted-signatures/1 -inform DER \
  | openssl x509 -noout -issuer -subject -dates

What does not change: legal validity is not tied to key custody

Section 3A of the IT Act, 2000 conditions the legal recognition of an electronic signature on the reliability of the signature creation process, not on the physical form of the device holding the key. That framing was written to be technology-neutral on exactly this point, well before cloud HSMs were a mainstream issuance option.

A cloud-hosted Class 3 certificate used correctly is not weaker evidence than a token-based one. The risk here is operational rather than legal: an integration that hard-codes assumptions about tokens into its validation or audit-trail logic will keep producing audit trails that are technically accurate but describe the wrong mental model to whoever has to read them later, whether that is an internal auditor, a customer's legal team, or a court.

A short checklist before you touch a DSC integration this quarter

Four things are worth doing before the next audit cycle, not after: confirm your validation logic checks the CA chain and revocation status rather than inferring anything from a token driver being present; confirm your audit trail records the CA's authentication assertion for the signing session rather than just noting that a token was detected; re-test bulk-sign flows against a cloud-hosted test certificate, not only a token-based one, since the two paths can diverge in ways a token-only test suite will never surface; and ask your certifying authority which of the MCA, GST, or DGFT acceptance statements actually applies to your use case, because portal-level acceptance and general legal recognition are related but not identical claims.

Closing

As more certifying authorities move toward cloud-hosted key custody, certificate-class trivia stops being the useful thing to track. The more durable skill for engineering and compliance teams is making sure verification logic checks what actually establishes trust, the chain, the CA's attestation, and the timestamp, rather than a proxy like token presence that quietly stopped being universal somewhere in the last year.