GSTN emSigner Migration: Legal Impact of FIPS 140-3 in India

Summary: GSTN Advisory No. 672 on emSigner v3.3, read with the CCA migration from FIPS 140-2 to FIPS 140-3, represents a significant change in the cryptographic infrastructure supporting Digital Signature Certificates rather than merely a routine software update. The transition affects hardware-level security, private-key protection, entropy generation, side-channel resistance and the technical basis of electronic authentication and non-repudiation. Its legal implications extend across the Information Technology Act, 2000, GST authentication requirements, judicial challenges to unsigned notices and orders, and electronic evidence under the Bharatiya Sakshya Adhiniyam, 2023. Judicial precedents including Ramani Suchit Malushte, Railsys Engineers, Marg ERP, A.V. Bhanoji Row, Nominee Works Committee Kalavalla and Silver Oak Villas LLP demonstrate the importance courts have attached to authentication of GST notices and orders. At the same time, taxpayers relying on electronic records must consider Section 63 BSA certification, cryptographic hashes and digital chain-of-custody issues. The FIPS migration also creates practical compliance requirements involving DSC-token inventories, emSigner compatibility, operating systems, Java environments and token custody. Corporate legal, finance and information-security teams therefore need coordinated cryptographic governance, workstation controls, evidentiary preservation and litigation-readiness measures as the transition progresses toward the scheduled retirement of legacy FIPS 140-2 modules.

The Cryptographic Architectural Shift: Deconstructing the Myth of the Routine IT Utility Tweak

FIPS 140-3 Migration and the Cryptographic Architecture of GST Authentication

The positioning propagated across corporate boardrooms and revenue circles characterises Goods and Services Tax Network (GSTN) Advisory No. 672, issued on September 19, 2026, as an ordinary middleware maintenance patch. This characterisation is a legal fiction. The mandatory deployment of emSigner version 3.3, operating together with the Controller of Certifying Authorities’ (CCA) regulatory migration from Federal Information Processing Standard (FIPS) 140-2 to FIPS 140-3, represents an architectural restructuring of hardware-level cryptographic assurance for the exchequer.

In high-stakes tax litigation, legal enforceability, transactional integrity, and statutory non-repudiation do not emanate from subjective administrative intent; they depend on the physical and mathematical integrity of the cryptographic boundary that signs the electronic record.

The legacy standard, FIPS 140-2, codified by the National Institute of Standards and Technology (NIST) in 2001, was premised on computational assumptions formulated for a static era. Over two decades of adversarial computing, physical micro-probing, automated side-channel telemetry, and advanced fault-injection attacks have systematically undermined its operational security.

Recognising these systemic vulnerabilities, the international community instituted ISO/IEC 19790:2012 (Security requirements for cryptographic modules) and ISO/IEC 24759:2017 (Test requirements for cryptographic modules), which NIST adopted as the core foundation of FIPS 140-3. By aligning the Indian Public Key Infrastructure (PKI) ecosystem with FIPS 140-3, the CCA has mandated a shift in physical and computational trust.

Cryptographic Assurance Dimension	Legacy Framework: FIPS 140-2	Modern Framework: FIPS 140-3	Statutory and Forensic Significance
Architectural Benchmark	NIST-proprietary standard (codified in 2001).	ISO/IEC 19790:2012 and ISO/IEC 24759:2017.	Internationalises domestic evidentiary standards for commercial electronic proof.
Physical Tamper Resistance	Passive visual inspection barriers (e.g., standard opaque resins, tamper-evident tape).	Active tamper detection envelopes; dynamic Environmental Failure Protection (EFP) and Testing (EFT).	Prevents physical micro-probing of the cryptographic boundary to harvest stored private keys.
Cryptographic Zeroization	Software-driven overwrite routines vulnerable to physical electron charge remanence.	Active, microsecond hardware zeroisation across all unprotected security parameters.	Eliminates cold-boot forensic attacks and memory remanence exploitation on disconnected hardware.
Side-Channel Attack Mitigation	Optional, loosely tested parameters at lower security thresholds; largely unverified in USB tokens.	Mandatory non-invasive attack testing across all security levels, including SPA, DPA, and SEMA.	Neutralises external physical eavesdropping on power traces, execution timing, and RF radiation.
Entropy and Random Generation	Deterministic Pseudo-Random Number Generation (PRNG) seeded by system clock events.	NIST SP 800-90B/C compliant True Random Number Generators (TRNGs) with live health tests.	Guarantees non-predictability of ephemeral signature nonces, satisfying Section 3 of the IT Act.
Service Authentication and State	Basic role-based authorisation without granular operational state separation.	Enforced service-based authentication requiring distinct validation per cryptographic operation.	Establishes the technical foundation for personal non-repudiation under Section 3A of the IT Act.
Module Lifecycle Assurance	High reliance on vendor self-assertion during laboratory evaluations.	Continuous laboratory-driven Cryptographic Module Validation Program (CMVP) validation.	Provides trial courts with verifiable operational integrity under Section 63 of the BSA.

To understand this transition, one must examine how asymmetric cryptography functions under the Information Technology Act, 2000 (IT Act). Section 3 provides that an electronic record is authenticated when an asymmetric key pair mathematically binds the subscriber’s private key to the underlying hash of the data.

Section 3A broadens this paradigm to electronic signatures, while Section 5 establishes legal recognition, providing that an electronic signature satisfies statutory mandates for a physical signature. Section 35 regulates the issuance of Digital Signature Certificates (DSCs) by licensed Certifying Authorities.

This entire statutory structure rests upon an indispensable technical premise: that the asymmetric private key remains under the sole, uncompromised, and exclusive custody of the subscriber. If the physical or logical boundary of the cryptographic module permits key cloning, unauthorised leakage, or predictable entropy generation, the legal presumption of attribution collapses.

FIPS 140-3 restructures this protective framework across four main dimensions:

Physical Tamper Resistance and Enclosure Integrity

Under legacy FIPS 140-2 Level 2 parameters, USB cryptographic dongles frequently relied on passive tamper-evident seals or brittle coatings. Once an adversary physically breached these enclosures, standard laboratory micro-probes could directly interface with the circuit traces connecting the secure microcontroller to external flash memory, extracting the raw asymmetric private key.

FIPS 140-3 mandates active tamper-detection envelopes. The cryptographic module must be encapsulated in an opaque, chemically resistant enclosure that actively detects physical penetration, thermal variations, and chemical solvent attacks.

Active Cryptographic Zeroisation

When an intrusion attempt or an environmental anomaly—such as intentional voltage fluctuations designed to cause computational errors—is detected, the cryptographic module must protect its secrets. Under FIPS 140-2, zeroisation routines frequently consisted of software-initiated write-over commands, which could leave residual charge footprints in non-volatile flash memory that specialised scanning electron microscopes could recover.

FIPS 140-3 mandates active zeroisation circuits. Upon detecting a physical or environmental breach, the module deploys dedicated capacitive discharge paths to destroy all Critical Security Parameters (CSPs) and private signing keys within microseconds, preventing post-compromise key recovery.

Non-Invasive Side-Channel Attack Mitigation

The transition to FIPS 140-3 directly confronts non-invasive cryptanalysis. In operational environments, cryptographic processing leaks physical side-channel information. By measuring micro-fluctuations in current consumption across the USB interface (Simple Power Analysis and Differential Power Analysis), recording electromagnetic radiation emanations (Simple Electromagnetic Analysis), or timing cryptographic operations to the nanosecond, an attacker can mathematically isolate the private key without opening the token’s casing.

FIPS 140-3 makes side-channel mitigation mandatory across all module evaluation tiers. It requires hardware tokens to implement algorithmic blinding, constant-time arithmetic processing, and dynamic internal power-balancing to obscure computational signatures.

Non-Deterministic Entropy and True Random Number Generation

The mathematical security of asymmetric signing rests on the random values used to generate key pairs and digital signature nonces. FIPS 140-2 permitted deterministic pseudorandom number generators that were frequently seeded by predictable host system states. If the initial seed had low entropy, the resulting key space collapsed, leaving the private key vulnerable to modern cryptanalysis.

FIPS 140-3 requires hardware-level True Random Number Generators (TRNGs) that meet NIST Special Publication 800-90B/C requirements. These generators harvest non-deterministic entropy from physical quantum phenomena, such as thermal noise across reverse-biased semiconductor junctions or ring oscillator jitter. Continuous operational health tests run in the background; if the entropy harvest degrades, the module halts cryptographic signing, preventing the creation of vulnerable signatures.

These hardware-level protections form the bedrock of the legal doctrine of non-repudiation. Non-repudiation is not an abstract legal concept; it is an evidentiary presumption created by mathematics and hardware design.

If the underlying hardware security module allows side-channel private key leakage, permits the injection of unauthorised payloads, or relies on predictable entropy, a subscriber can legitimately challenge the attribution of an electronic signature.

By issuing Advisory No. 672, the GSTN has acknowledged that legacy cryptographic tokens no longer provide the assurance level required to guarantee non-repudiation in an adversarial digital landscape.

Constitutional and Jurisdictional Validity: The Fatal Defect of Defective and Unsigned Departmental Enactments

When the Revenue exercises statutory assessment powers through automated portals, administrative expedience frequently clashes with mandatory legal requirements. Under the Central Goods and Services Tax Rules, 2017 (CGST Rules), statutory notices and adjudication orders require rigorous authentication.

Rule 26(1) provides that every submission, return, application, and response filed by a taxpayer must be authenticated via a digital signature certificate (mandatory for incorporated companies) or an approved electronic verification code. Rule 26(3) applies these standards to the state, requiring notices, certificates, and orders issued by tax authorities to be authenticated by a valid digital signature certificate or approved electronic signature.

Despite this rule, tax officers frequently upload auto-generated, unauthenticated PDF documents to the GST common portal. Summaries in Form GST DRC-01 (Show Cause Notices) and Form GST DRC-07 (Orders-in-Original) are often issued without digital signatures, bearing only blank spaces, placeholders stating “SD/-“, or invalidated cryptographic signatures resulting from obsolete middleware handshakes.

When assessees challenge these defective orders, the Department typically raises two statutory defences:

• It characterises the missing signature as a minor defect cured by Section 160 of the CGST Act.
• It claims that publishing the document on the GST common portal constitutes valid electronic service under Section 169(1)(d), rendering lack of authentication irrelevant.

High Courts across multiple jurisdictions have systematically rejected these contentions, holding that an unsigned or cryptographically invalid order is an incurable jurisdictional nullity (non est).

Judicial Precedent	Forum and Citation	Subject Matter of Challenge	Primary Revenue Defence	Decisional Ratio and Jurisdictional Rule
Ramani Suchit Malushte v. Union of India	High Court of Bombay (W.P. No. 9331 of 2022)	Unsigned registration cancellation order; uploaded without DSC under Rule 26(3).	Section 169 portal delivery cures absence of DSC; taxpayer received electronic copy.	An unsigned order has no legal effect (non est); portal delivery cannot cure non-authentication; limitation runs only from actual signed delivery.
Railsys Engineers Pvt. Ltd. v. Additional Commissioner	High Court of Delhi (W.P.(C) 4712/2022)	Unsigned show cause notice and cancellation order lacking digital signature authentication.	Portal-generated automated transmission satisfies statutory notification objectives.	An unsigned notice or order cannot be sustained in law; digital signature authentication is a condition precedent for validity.
Marg ERP Ltd. v. Commissioner. of Delhi GST	High Court of Delhi (W.P.(C) 872/2023)	Unsigned demand assessment order under Section 73 issued with vague narrative grounds.	Invoked curing mechanisms for administrative IT notifications; draft reflected officer’s intent.	Affirmed Railsys Engineers and Ramani Suchit; an unsigned demand order is invalid in law and must be quashed.
A.V. Bhanoji Row v. Assistant Commissioner	High Court of Andhra Pradesh (W.P. No. 2830 of 2023)	Show-cause notice in DRC-01 and final order in DRC-07 uploaded completely unsigned.	Sections 160 and 169 insulate the demand against technical procedural defects.	Section 160 does not cover failure to sign; Section 169 does not dispense with signatures; the orders are void ab initio.
Nominee Works Committee Kalavalla v. Deputy Assistant Commissioner	High Court of Andhra Pradesh (W.P. No. 7693 of 2026)	Belated challenge to unsigned DRC-07 assessment order followed by DRC-16 recovery.	Gross taxpayer delay; portal upload under Section 169(1)(d) finalised the demand.	Reaffirmed A.V. Bhanoji Row; missing signature is an incurable jurisdictional defect; delayed writ allowed subject to 20% deposit.
Silver Oak Villas LLP v. Assistant Commissioner	High Court of Telangana (W.P. No. 6671 of 2024)	Unsigned DRC-01 SCN and unsigned assessment order under Section 73.	Portal login authentication by the issuing officer replaces explicit document DSC.	SCN and final order quashed; internal portal access cannot replace document-level digital signatures.

The foundation of this jurisprudence was established by the Bombay High Court in Ramani Suchit Malushte v. Union of India & Others. In that dispute, the Revenue argued that an unsigned order cancelling a taxpayer’s registration remained enforceable because the taxpayer received it electronically through the portal.

Rejecting this defence, the Division Bench held that accepting the Revenue’s position would render Rule 26 of the CGST Rules meaningless. The Court held that unless a digital signature is affixed by the issuing authority, the order has no effect in the eyes of the law. As a result, the statutory period of limitation for filing an appeal never began to run.

The Delhi High Court applied this principle to tax adjudications in Railsys Engineers Private Limited v. The Additional Commissioner of Central Goods and Services Tax. The Court held that an unsigned show cause notice and subsequent cancellation order are invalid in law. This precedent was reaffirmed in Marg ERP Ltd. v. Commissioner of Delhi Goods and Services Tax, where the Court quashed an unsigned demand order under Section 73, establishing that an unauthenticated document cannot be treated as an enforceable tax order.

The Andhra Pradesh High Court analysed the limits of statutory curing provisions in A.V. Bhanoji Row v. Assistant Commissioner (ST). In that case, the Revenue argued that Section 160(1) preserved an unsigned show cause notice (DRC-01) and assessment order (DRC-07) as a mere “mistake, defect or omission” occurring in a proceeding that was otherwise in conformity with the Act.

The Division Bench rejected this construction. It held that Section 160 cannot validate a failure of statutory authentication. Section 160 is designed to cure minor clerical, typographical, or computational errors in an otherwise valid instrument. It cannot bring into legal existence a document that has not been authenticated by the designated officer.

The Andhra Pradesh High Court reaffirmed this principle in Nominee Works Committee Kalavalla v. Deputy Assistant Commissioner (STII). Confronting an assessment order issued in Form GST DRC-07 that lacked an Assessing Officer’s signature, the Revenue opposed the taxpayer’s writ petition on grounds of delay, arguing that uploading the document to the GST common portal constituted complete service under Section 169(1)(d).

The Court held that the absence of a signature is an incurable jurisdictional defect that cannot be rectified by Section 160 or Section 169. Section 169 provides mechanisms for serving an existing order; it cannot validate a document that is non est. A document that lacks legal existence cannot be served.

Because the unsigned DRC-07 was void ab initio, the Court entertained the delayed writ petition and set aside the assessment, remanding the matter for fresh adjudication subject to a 20% disputed tax deposit.

The argument that an assessing officer’s portal login credentials substitute for an explicit digital signature on the underlying document is unpersuasive. A portal login merely authenticates the user’s session with a remote server; it does not sign the resulting PDF document. A digital signature, under Section 3 of the IT Act, mathematically binds a specific private key to the hash of an immutable document.

Session authentication fails to secure the document once downloaded. An unauthenticated PDF can be manipulated, altered, or forged without breaking a cryptographic seal.

When a tax officer issues a show cause notice (DRC-01) or an assessment order (DRC-07) using a non-compliant or compromised cryptographic module, such as a legacy FIPS 140-2 token deployed after the CCA cutoff without authorisation, the resulting document suffers from an incurable jurisdictional defect.

Without valid cryptographic authentication, the document fails the standard set out in Ramani Suchit Malushte and Nominee Works Committee Kalavalla. The state cannot enforce a statutory liability using an instrument that has no legal existence.

The Taxpayer’s Defensive Shield and Evidentiary Cross-Examination under Bharatiya Sakshya Adhiniyam, 2023

When corporate taxpayers defend against imputed tax liabilities, such as unauthorised return filings, illicit input tax credit allocations, fraudulent refund claims, or token compromises, they face the evidentiary challenge of rebutting a statutory digital signature. The legal landscape changed on July 1, 2024, when the Bharatiya Sakshya Adhiniyam, 2023 (BSA) replaced the Indian Evidence Act, 1872 (IEA).

The transition from Section 65B of the IEA to Sections 61, 62, and 63 of the BSA introduces stricter statutory standards for electronic evidence, transforming how parties challenge digital authentication in tax proceedings.

Under Section 57 of the BSA, electronic records stored across multiple systems or maintained in proper custody are recognised as primary evidence. However, whenever the Revenue relies on a “computer output”, such as printouts, exported database tables, or downloaded PDF records of portal filings, the document constitutes secondary electronic evidence governed by Section 63.

Under Section 65B(4) of the IEA, the Revenue often relied on a generic certificate signed by an officer stating that the computer systems operated normally. That practice is no longer sufficient under Section 63 of the BSA.

Evidentiary Dimension	Indian Evidence Act, 1872 (S. 65B)	Bharatiya Sakshya Adhiniyam, 2023 (S. 63)	Forensic Litigation Strategy under BSA
Certification Structure	Unstructured certificate; courts frequently accepted single-signatory filings.	Prescribed statutory format set out in the Schedule to the Act (Parts A and B).	File a formal motion in limine to exclude evidence lacking strict Schedule-format compliance.
Signatory Requirements	A single individual holding an official position regarding device operation.	Mandatory dual certification: Device Custodian (Part A) and Independent Technical Expert (Part B).	Object to any Revenue record signed solely by an assessing officer without an independent technical expert.
Cryptographic Hash Verification	No explicit statutory requirement to calculate, record, or submit cryptographic file hashes.	Mandatory identification of hash values (SHA-256) and explicit hashing algorithms in the certificate.	Challenge mismatched, absent, or outdated hash algorithms (e.g., MD5/SHA-1 collisions) across files.
Temporal Timing of Certificate	Often accepted retroactively during appellate stages or trial arguments.	Required upon each presentation of the electronic record for admission.	Exclude retrospective certificates introduced by the Revenue to cure fatal trial-stage omissions.
System and Network Scope	Broad references to computers; unclear coverage of modern microservices and APIs.	Covers computer systems, networks, semiconductor memories, and intermediaries.	Cross-examine the emSigner middleware loopback layer, web sockets, and token hardware interfaces.

Section 63(4)(c) of the BSA, read with the Schedule, requires a two-part certificate for admitting secondary electronic records:

• Part A must be executed by the person who owns, operates, or maintains the digital device, affirming lawful control and normal operation during the period when the data was generated or stored.
• Part B must be executed by a qualified technical expert who verifies the mechanical, software, and systems integrity of the device and confirms the electronic record’s authenticity.

The certificate must also record:

• The make, model, serial number, and hardware identifiers (such as IMEI, MAC address, or Cloud ID) of the originating device.
• The alphanumeric cryptographic hash value of the electronic file, along with the hashing algorithm used (such as SHA-256).
• An attached hash computation report generated at the time of evidence preservation.

This statutory requirement provides corporate taxpayers with a viable defence when contesting disputed portal filings. In practice, the Department routinely produces printouts of GST portal records, DRC forms, or GSTR return summaries without filing the mandatory two-part Section 63 certificate.

When the Revenue fails to supply a Part B expert certification or omits the SHA-256 hash value, the evidence is legally inadmissible. Counsel can move to exclude the secondary electronic evidence, stripping the assessment of its factual foundation.

Beyond statutory certification defences, taxpayers can challenge the operational integrity of the emSigner middleware itself. The client-side signing architecture uses a local web-server daemon running on the user’s desktop (listening on 127.0.0.1 via dedicated ports, such as 1585). When an assessee clicks “Sign” on the GSTN portal, the browser executes a WebSocket or loopback HTTP request to the local emSigner application.

This client-side handshake is vulnerable to multiple attack vectors:

• Localhost Hijacking and Port Manipulation: Malicious processes executing with standard user privileges on the workstation can bind to or intercept loopback ports, monitoring signing payloads.
• Cross-Origin Resource Sharing (CORS) and WebSocket Exploitation: If emSigner’s CORS rules are misconfigured or fail to isolate localhost web requests, external browser tabs can issue signing commands to the local emSigner daemon.
• Blind Signing Vulnerabilities: emSigner renders high-level metadata (such as the signer’s name and certificate expiration) in its graphical dialogue box rather than displaying the complete, canonical payload. As a result, users frequently sign cryptographic hashes without verifying the underlying data structures.

If a rogue employee, external accountant, or attacker uses an assessee’s cryptographic token, the taxpayer can rebut imputed liability by investigating the digital chain-of-custody. Defence counsel should consider moving for the production of the following digital forensic records:

• PKCS#11 Session Audit Trails: Extracting internal hardware access logs from the token to determine if single-session PIN authentications were reused across multiple unauthorised payloads.
• Host Operating System Volatile Memory: Inspecting process allocation logs on the host workstation to identify unauthorised local API calls to the emSigner daemon.
• Network Gateway and Firewall Captures: Comparing the external IP address reported by GSTN access logs against the enterprise’s private gateway to prove that filings were executed remotely rather than from corporate premises.
• Cryptographic Nonce and Entropy Analysis: Examining whether repetitive or predictable nonces were used, which would indicate legacy token vulnerabilities or broken random number generation.

By identifying breaks in the chain-of-custody and demonstrating non-compliance with Section 63 of the BSA, an assessee can rebut the presumption of valid execution. If the state cannot provide complete cryptographic and statutory proof linking the assessee to the specific filing, the tax demand fails.

Navigating the Transitional Minefield: Regulatory Windows, Workstation Fragility, and Corporate Exposure

The transition from legacy cryptographic modules to FIPS 140-3 involves complex operational and compliance timelines. The CCA migration framework establishes a dual-timeline transitional window spanning September 21, 2026, to the complete sunset on September 21, 2029.

Regulatory Transition Milestone	Effective Date	Operational Mandate	Legal and Corporate Impact
Audit Application Freeze	January 1, 2026	CCA ceased accepting fresh compliance audit applications for legacy FIPS 140-2 modules.	Prevents vendors from introducing new FIPS 140-2 hardware into the Indian commercial pipeline.
Mandatory Issuance Cutoff	September 21, 2026	Certifying Authorities must halt issuing DSCs onto FIPS 140-2 modules. All fresh issuances and renewals require FIPS 140-3 hardware.	Creates an evidentiary divide: post-cutoff DSCs downloaded onto legacy tokens fail statutory verification.
emSigner v3.3 Enforcement	September 21, 2026	Taxpayers and tax officers receiving new tokens must deploy emSigner v3.3. Existing tokens are supported via backward compatibility.	Failure to upgrade prevents DSC selection; workstations failing system specifications face signing lockouts.
Grandfathering Window	September 21, 2026 to September 21, 2029	Pre-existing DSCs downloaded on or before September 21, 2026, remain valid until their natural expiry.	Prevents immediate operational disruptions, preserving the legal validity of existing certificates.
Government Exemption Window	September 21, 2026 to September 21, 2029	Government entities may receive a one-time free reissuance of FIPS 140-2 modules for remaining certificate validity.	Requires a formal Ministerial risk waiver; private corporate entities are strictly ineligible.
Absolute Sunset Deadline	September 21, 2029	Complete retirement of all FIPS 140-2 cryptographic modules across the Indian PKI ecosystem.	Any document signed via FIPS 140-2 hardware after this date is legally invalid and inadmissible in judicial proceedings.

The CCA migration framework establishes three operational mechanisms:

The Grandfathering Exception and Issuance Freeze

Effective September 21, 2026, Certifying Authorities are prohibited from issuing fresh or renewed DSCs onto legacy FIPS 140-2 cryptographic dongles. However, an explicit grandfathering clause protects existing certificates: any valid DSC downloaded onto a FIPS 140-2 token on or before September 21, 2026, remains legally valid and operational until its natural certificate expiration.

The arrival of the September 21, 2026 deadline does not automatically invalidate functional tokens.

The One-Time Free Reissuance Exception

The CCA framework provides a limited exception for government organisations. Where a public sector entity’s security policies require the continued use of FIPS 140-2 modules, Certifying Authorities may issue a DSC onto a FIPS 140-2 module on or after September 21, 2026, but only for the remaining validity of the existing certificate.

This reissuance is allowed once, free of charge, and requires an explicit risk and compliance waiver signed by an authorised officer with approval from their supervising Ministry. This exception expires on September 21, 2029, when all FIPS 140-2 modules are permanently retired.

The Absolute Sunset Deadline

On September 21, 2029, the transition window closes. All FIPS 140-2 tokens, HSMs, and associated hardware cryptographic modules will reach end-of-life status.

Beyond this date, legacy tokens lose both operational compatibility with the GSTN portal and legal recognition under the IT Act, as they will no longer meet statutory security standards.

Alongside this hardware transition, GSTN Advisory No. 672 imposes strict workstation constraints that can disrupt enterprise finance departments:

• 64-bit Operating System Mandate: emSigner v3.3 operates exclusively on 64-bit platforms: Windows 10/11 (64-bit), Linux (Ubuntu 18+), or macOS (10.6+). Workstations running legacy 32-bit operating systems cannot run the middleware, preventing DSC-based tax filings.
• Hardware Thresholds: Systems must have at least 8 GB of installed RAM and 64 GB of available storage.
• The Java Runtime Environment Constraint: emSigner v3.3 requires Java 1.8 (Oracle JRE or OpenJDK). Java runtime environments version 9 and above are unsupported and cause the application to fail.

This Java restriction stems from changes in the runtime’s underlying architecture. In Java 9, the Java Platform Module System (Project Jigsaw) altered the internal package structure and encapsulated legacy cryptographic provider APIs.

Furthermore, Java 9 removed the Java EE modules—specifically the Java Architecture for XML Binding (javax.xml.bind or JAXB) and Web Services APIs (javax.xml.ws)—which emSigner relies on to handle XML/JSON signature profiles.

Deploying emSigner v3.3 within enterprise environments running modern Java runtimes (such as Java 11, 17, or 21) causes runtime linkage errors, such as:

java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException

These errors disable the middleware loopback service and prevent users from completing tax filings.

Beyond operational disruptions, relying on sunsetted or vulnerable cryptographic hardware exposes corporations to statutory liability under Section 43A of the IT Act. Section 43A provides that if a corporate body handles sensitive personal data or financial information within its computer systems, it must implement reasonable security practices and procedures.

Failure to do so makes the corporation liable for damages if an unauthorised breach or security incident occurs.

These statutory obligations are reinforced by CERT-In’s Technical Guidelines on SBOM, QBOM & CBOM Version 2.0. Under these guidelines, enterprises must maintain a Cryptographic Bill of Materials (CBOM) tracking all encryption algorithms, hardware security modules, USB tokens, cryptographic libraries, and key lifecycles.

The CBOM tracks 21 distinct data points, including algorithm names, key lengths, hardware serial numbers, and quantum vulnerability profiles.

If an enterprise processes high-value tax transactions using legacy, unsupported FIPS 140-2 tokens after September 2026 without an approved risk waiver, it fails to meet the standard of “reasonable security practices”.

If an employee’s private key is extracted or forged via side-channel analysis, the company risks substantial damage claims under Section 43A, while its general counsel faces regulatory penalties from CERT-In for non-compliance with national cybersecurity directives.

Strategic Playbook for General Counsel, CFOs, and Tax Litigators

To navigate this regulatory transition, corporate legal counsel, financial controllers, and tax litigators should implement a coordinated compliance and dispute-readiness strategy.

Phase and Focus	Strategic Action Item	Statutory and Regulatory Authority	Operational Protocols and Preservation Controls
Phase I: Cryptographic Inventory Audit	Build an enterprise Cryptographic Bill of Materials (CBOM).	CERT-In CBOM v2.0 Guidelines; Section 43A of the IT Act.	Scan, catalogue, and classify every hardware token, CA issuer, serial number, and FIPS validation tier (140-2 vs 140-3).
Phase II: Workstation Hardening	Deploy isolated virtual machines or dedicated tax-filing endpoints.	GSTN Advisory No. 672; Rule 26 of the CGST Rules.	Enforce 64-bit OS architectures; install isolated Java 1.8 runtimes; block Java 9+ updates on signing workstations.
Phase III: Token Custody and Governance	Implement strict chain-of-custody protocols for hardware tokens.	Section 3A of the IT Act; BSA 2023, Sections 62 and 63.	Eliminate shared token access; deploy biometric sign-out logs; configure PKCS#11 PIN entry timeouts and session controls.
Phase IV: Litigating Unsigned Orders	Challenge unauthenticated departmental notices and assessment orders.	Rule 26(3) of the CGST Rules; Ramani Suchit; Nominee Works.	File Article 226 writ petitions against unsigned DRC-01 and DRC-07 forms; assert incurable jurisdictional defect (non est).
Phase V: Evidentiary Appellate Defence	Enforce statutory compliance for electronic evidence submitted by the Revenue.	Section 63 of the BSA (Schedule Parts A and B).	Challenge Revenue exhibits lacking expert Part B certification or SHA-256 hash values; commission independent forensic audits.

Phase I: Enterprise Cryptographic Audit and CBOM Implementation

The general counsel and chief information security officer must catalogue every hardware dongle, HSM, and DSC deployed across all operating entities, branch locations, subsidiaries, and retained accounting firms.

Each device must be cross-referenced against the NIST Cryptographic Module Validation Program (CMVP) database to distinguish legacy FIPS 140-2 modules from certified FIPS 140-3 hardware. Expiration dates for grandfathered FIPS 140-2 tokens must be mapped to prevent procurement disruptions, and procurement guidelines must prohibit purchasing non-compliant legacy inventory.

Phase II: Workstation Architecture and Operational Hardening

Enterprise IT must audit every workstation used for tax compliance to verify that it meets the requirements of GSTN Advisory No. 672. Systems must run 64-bit operating systems with at least 8 GB of RAM and 64 GB of free storage.

IT departments must deploy isolated Java 1.8 runtimes (Oracle JRE or OpenJDK) and implement Group Policy Objects (GPOs) to prevent automatic updates to Java 9 or higher on dedicated tax-filing machines.

Furthermore, emSigner v3.3 must be sourced directly from official GSTN repositories, and local host firewalls must restrict loopback port communication (such as 127.0.0.1:1585) to authorised local browser sessions, preventing unauthorised cross-site requests.

Phase III: Authentication Protocols and Token Custody Governance

Corporate leadership must end the practice of leaving cryptographic dongles permanently attached to shared office computers or distributing PINs among finance personnel. Shared access destroys the legal presumption of exclusive subscriber custody under Section 3 of the IT Act.

Cryptographic tokens must be secured in central physical safes, with sign-in and sign-out registers tracking the date, time, business purpose, and identity of the authorised signatory.

Operating systems on filing endpoints must also log token insertion, cryptographic access, and removal events to maintain an audit trail for future evidentiary proceedings.

Phase IV: Litigation Strategy Before High Courts and Appellate Tribunals

When the Revenue issues an unauthenticated show cause notice (Form GST DRC-01) or summary assessment order (Form GST DRC-07), tax litigators should evaluate challenging the proceedings via a writ petition under Article 226 of the Constitution of India rather than pursuing statutory appellate remedies.

Drawing upon Ramani Suchit Malushte, Railsys Engineers, Marg ERP, A.V. Bhanoji Row, and Nominee Works Committee Kalavalla, counsel should argue that the lack of statutory authentication constitutes an incurable jurisdictional defect rendering the instrument non est.

Counsel should counter the Department’s reliance on statutory curing provisions by arguing that Section 160 cannot validate a non-existent order, and that electronic publication under Section 169(1)(d) cannot effectuate service of a nullity.

Phase V: Evidentiary Appellate Defence

In disputes involving alleged portal filings, unapproved credits, or disputed assessments, defence counsel should require the Revenue to establish the admissibility of its electronic evidence under Section 63 of the Bharatiya Sakshya Adhiniyam.

Counsel should inspect the Department’s Section 63 certificate against statutory requirements:

• Does the certificate contain both a Part A declaration from the lawful custodian and an independent Part B technical expert certification?
• Does the certificate record the device’s unique hardware identifiers alongside the SHA-256 cryptographic hash value of the underlying data files?
• Can the Department produce access logs establishing that the filing originated from the assessee’s authorised IP address, rather than through an exploited emSigner loopback or unauthorised token operation?

If an internal token is compromised or used without authorisation, counsel should commission an independent forensic analysis of the host workstation’s volatile memory and token driver registries.

Submitting this expert evidence alongside a completed Part B Section 63 certificate allows an enterprise to rebut the statutory presumption of valid execution, establishing that the disputed filing was executed without lawful corporate authority.

Systemic Integration: The Converging Futures of Tax Litigation and Cryptography

The transition from FIPS 140-2 to FIPS 140-3, accompanied by the rollout of emSigner v3.3, alters the dynamic between tax enforcement, cybersecurity, and Indian evidentiary doctrine. By shifting the technical foundations of electronic signatures toward active tamper-response mechanisms, advanced side-channel mitigation, and non-deterministic entropy generation, this migration makes clear that cryptographic assurance is the prerequisite for legal non-repudiation.

For tax administrators, the era of relying on automated, unsigned PDFs and asserting immunity under Sections 160 and 169 of the CGST Act is ending. As the High Courts have established, statutory authentication is an essential condition for administrative validity; an unauthenticated order remains void and unenforceable in law.

Concurrently, corporate taxpayers face heightened expectations. In high-stakes tax controversies, evidentiary outcomes will depend on compliance with Section 63 of the Bharatiya Sakshya Adhiniyam, the operational health of signing middleware, and the cryptographic strength of the underlying hardware tokens.

Corporate leadership must align IT operations with these evidentiary requirements, recognising that managing the technical components of cryptographic authentication is now central to defending against substantive tax exposure.