ML-DSA digital signatures are a planned foundation for proving identity and authenticating signed data. Integration must bind each operation to an authorised user, device and policy.
BHISMA / INDIAN POST-QUANTUM HARDWARE
SECURING INDIA’S
DIGITAL FOUNDATIONS.
Developing post-quantum security hardware for enterprises, financial systems and critical infrastructure.
Under development · Open to research and pilot collaborations
Connected infrastructure. A stronger foundation of trust.
02 / SHAKTI PQC-KEY
Security starts
in the hardware.
A proposed physical security device for protected-key operations and post-quantum integration.
Inside SHAKTI →
03 / INSIDE SHAKTI
Explore the
architecture
of trust.
Enclosure, circuit board and cryptographic processing—an illustrative design, subject to engineering validation.
Explore SHAKTI RISC-V PQC →
04 / INTENDED SECURITY FUNCTIONS
Protect keys.
Verify devices.
Establish trust.
Development objectives, not validated specifications. Operations depend on application, protocol and key-management integration.
Explore intended functions →05 / INTENDED APPLICATIONS
Built around
India’s digital
future.
Banking, telecom, energy, data centres and government systems. Each environment needs its own integration and evaluation.
Explore the sectors →ILLUSTRATIVE CONCEPT · UNDER DEVELOPMENT
01 / THE VISION
The hardware foundation
for India’s transition to
post-quantum security.
BHISMA
INDIAN POST-QUANTUM HARDWARE
INDIAN POST-QUANTUM HARDWARE
BHISMA is developing the hardware foundation for India’s transition to post-quantum security.
BHISMA Defence Technology is an Indian company developing post-quantum security hardware for enterprises and critical infrastructure. SHAKTI PQC-Key is the main product concept, with protected-key operations, device identity and controlled firmware as development objectives. A token does not automatically make an organisation quantum-safe: deployment requires integration with its applications, protocols and key-management systems.
Under development. Not a production system. No government or armed-forces approval, certification or operational deployment is claimed.
02 / INSIDE THE TRUST BOUNDARY
Protect keys. Verify devices.
Establish trust.
Explore four intended security layers.
Capabilities below are development objectives, not validated product specifications.
Planned ML-KEM support would help establish shared secrets for secure sessions. A KEM is one part of a complete protocol—not a replacement for every layer of encryption or authentication.
The design aims to isolate sensitive keys and private-key operations from the connected host, with controlled provisioning, use, rotation and retirement.
Secure boot and authenticated updates are intended to keep the token’s firmware within an approved trust chain. Debug control, rollback policy and tamper-response measures require validation.
Algorithm references: NIST FIPS 203 (ML-KEM) · NIST FIPS 204 (ML-DSA). Referencing a standard does not imply product certification.
03 / THE INTENDED EXPERIENCE
Connect. Verify.
Establish trust.
Connect to an authorised system
The token is intended to work with host software through a defined interface. Connector choice, operating-system support and APIs remain under evaluation.
Apply policy before an operation
Verify the request and the permitted identity or device context. Sensitive operations should be authorised, not merely triggered by possession of the token.
Keep the key within the boundary
Perform approved cryptographic operations in protected hardware and return the protocol output. Local and disconnected workflows require explicit lifecycle and revocation policies.
INTENDED SECTOR APPLICATIONS
Built around
India’s digital future.
These are potential applications, not deployments or validated product capabilities. Specific integration requirements, interoperability, security controls and applicable assurance requirements must be evaluated for each environment.
Banking and financial services
Hardware-protected keys and post-quantum integration pilots.
Telecom
Device identity and secure management communications.
Energy and utilities
Trusted maintenance access and authenticated updates.
Data centres and enterprises
Key protection, administrative identity and secure infrastructure connections.
Government
Device trust and protection of sensitive digital workflows.
Healthcare
Secure device connectivity and protection of sensitive data.
Transport and logistics
Gateway identity and authenticated communications across distributed systems.
Defence is another intended application, with distinct integration and assurance requirements. Explore SAMUDRA-M, the proposed maritime trust gateway →
DISTINCT PRODUCTS. A SHARED DEVELOPMENT DIRECTION.
Hardware, technology
and application programmes.
SHAKTI PQC-Key
A proposed physical security token for protected keys, identity and post-quantum integration. Final interfaces and specifications remain under evaluation.
Explore the product story →SHAKTI RISC-V PQC
A proposed processor programme combining a RISC-V control foundation with dedicated PQC hardware, firmware and a hardware root of trust.
Explore the technology programme →SAMUDRA-M
A proposed quantum-safe trust gateway for ship-shore and autonomous maritime networks. No Navy approval or deployment is claimed.
Explore the maritime application →05 / ENGINEERING, NOT ASSUMPTIONS
Built on evidence.
Not promises.
RISC-V and FPGA are enabling technologies in the proposed development path. They support controlled compute and early hardware validation—not a claim of finished silicon.
Request a Technical Brief ↗- Product direction
- Physical PQC security token
- Cryptographic targets
- ML-KEM · ML-DSA
- Hardware development
- RISC-V control · FPGA prototyping
- Trust objectives
- Protected keys · Verified firmware
- To be validated
- Interfaces, performance, power, physical assurance and interoperability
- Availability
- Under development · Not commercially released
06 / DEVELOPMENT PATH
From a clear architecture
to measurable assurance.
Define
Threat model, user and device identities, key lifecycle, host interfaces and authorised use.
Demonstrate
FPGA cryptographic demonstrator, secure firmware and a host-integration test harness.
Evaluate
Correctness, performance, implementation attacks, update recovery and interoperability.
Integrate
Partner evaluation and a productisation path informed by evidence and applicable assurance requirements.
07 / CLARITY FIRST
Understanding
the token.
Is this a cryptocurrency token?
No. “Token” means a proposed physical cryptographic security device. It is not a coin, blockchain asset or investment product.
Does it require a quantum computer?
No. Post-quantum cryptography is designed for conventional computing hardware. Its algorithms aim to resist attacks from both classical and sufficiently capable quantum computers.
Is BHISMA SHAKTI already available?
No. This is a development-stage concept. Product imagery is illustrative. Final specifications, benchmarks, availability and qualification have not been announced.
Is the token certified or approved for defence use?
No government or armed-forces approval, certification or operational deployment is claimed. Any such status would require the relevant testing and formal evaluation.
Can a token make an entire system quantum-safe?
Not by itself. Migration also requires an inventory of cryptographic dependencies, suitable protocols, upgraded software, lifecycle controls and implementation testing.
How can an organisation collaborate?
Use the contact form to discuss non-confidential requirements, host integration, research or evaluation. Please do not send classified information, operational details or secret keys.
08 / LET’S BUILD RESPONSIBLY
Build your quantum-readiness
roadmap with us.
Discuss a research collaboration or a scoped integration pilot with BHISMA. Tell us about your sector, application, protocols and key-management environment. Pilot scope, readiness, evaluation criteria and timelines would be agreed together.
bhismadefence@gmail.com ↗Please share non-confidential information only.