CERT-In's space framework: an annual empanelled audit, five testing phases

CERT-In has published a cyber security framework for space systems and satellite communication. CERT-In's guidelines register dates it 26 February 2026 and records it as issued by CERT-In in collaboration with SIA-India. It runs to fifty pages across twelve sections and four annexures.

For anyone who buys or runs security testing, one line in the executive summary sets the tone: the document "can be used as a baseline guiding document for assessing and auditing the cyber security posture of the space ecosystem". The rest of this piece is what that baseline actually asks for.

Its scope statement names who it is written for: "government agencies, satellite service providers, ground station operators, terminal equipment vendors, and private space entities". Terminal equipment vendors are in that list, which pulls in a set of manufacturers who may not think of themselves as space entities at all.

Two audit cadences, and they are not the same exercise

The framework sets its audit obligation twice, in two different chapters, and the two readings agree.

Paragraph 3.2.6, under Periodic Auditing and Compliance Verification:

"Entities shall undergo cyber security audits through CERT-In empanelled auditing organizations at least once in a year... Findings and remediation actions shall be submitted to CERT-In for review"

Paragraph 5.10, under Governance, Accountability, and Compliance, adds the internal half:

"Conduct internal cyber security audits at least once in six months and external cyber security audit through CERT-In empanelled auditing organization at least once in a year."

So the annual external audit runs through a CERT-In empanelled auditing organisation, and the findings go to CERT-In rather than staying in a drawer. That last clause is the one that changes how a report has to be written. An audit whose findings are submitted to the regulator needs remediation actions stated alongside them, and it needs to survive being read by someone who was not in the room.

Paragraph 3.2.6 also points to CERT-In's Comprehensive Cyber Security Audit Policy Guidelines for the shape of a holistic audit, so the audit follows a document CERT-In had already published.

A third trigger most calendars will miss

The two cadences above are time-based. Paragraph 9.3(b) adds an event-based one:

"Review security controls after each major satellite launch, ground network expansion, or vendor onboarding."

That is the clause an annual compliance calendar tends to lose. A constellation operator adding a ground station, or an operator onboarding a new modem supplier, has a control review to schedule whether or not the yearly audit is due.

Section 10: five testing phases across the mission lifecycle

Section 10 is the engineering half, and it is organised by lifecycle phase rather than by control family.

Phase	When	What is tested
Design validation	Design reviews	Threat modelling, secure coding, architecture validation, encryption design
Component and integration testing	Assembly and integration of subsystems	Hardware and firmware integrity, interface testing, cryptographic key management, supply chain verification
Pre-launch security testing	Before launch	Penetration testing of ground stations, command authentication, RF link robustness, access control
In-orbit and operational testing	During mission operations	Vulnerability scanning, anomaly detection, intrusion simulation, update and patch validation
End-of-life verification	Before decommissioning	Secure data erasure, command link disablement, system isolation

The pre-launch row is the one with a hard deadline attached to it. Everything else in a launch campaign is already scheduled against the launch date; a penetration test of the ground segment and the command authentication path now sits on the same critical path.

Six named techniques, and what each one needs before it can start

Paragraph 10.2 names the techniques rather than leaving "security testing" undefined. Each carries a scoping question worth settling before an engagement letter is signed.

Penetration testing, described as red team assessments, covering "ground stations, TT&C (Telemetry, Tracking, and Command) systems, and network infrastructure". TT&C is the part that needs a decision early: testing command authentication against a live spacecraft is not the same engagement as testing it against a simulator or an engineering model, and which one is in scope determines the whole rules of engagement.

Vulnerability scanning across onboard software, ground infrastructure and communication protocols. Scope this one by environment. Onboard software and ground infrastructure are different targets, and the onboard half belongs on a bench or in the build rather than under a live network scan.

Cryptographic validation against standards such as FIPS 140-3 and CCSDS SDLS. The framework names three things to verify: encryption algorithms, key lengths, and key management systems. The third is the one that needs evidence out of an HSM or a key ceremony rather than a configuration file.

RF and signal integrity testing for susceptibility to jamming, spoofing and interference. This one needs instrumentation and a controlled RF environment, so plan it furthest ahead.

Software assurance testing, static and dynamic analysis of onboard software and firmware. Scope it by build artefact, because firmware for a spacecraft and firmware for a user terminal are different codebases with different toolchains.

Supply chain testing for tamper detection, hardware provenance verification and third-party component validation. Paragraph 3.2.3 makes the procurement side of this explicit: "Supply chain risk assessments and third-party audits shall be mandatory before integration or deployment." Before integration, not after.

Who signs, and what they report

The framework names a governance owner in two places. The executive summary points to a Chief Information Security Officer. Paragraph 5.10 asks entities to "Appoint a Chief Satellite Security Officer (CSSO) to oversee cybersecurity governance within the organization", with a dedicated team beneath that role.

Paragraph 9.2(b) states what the role is accountable for: the CISO and team "shall be responsible for conducting cyber security audits and compliance", and the CISO "shall share the reports to senior management and CERT-In". Cyber threats are escalated to CERT-In and IN-SPACe within defined timelines, and a cyber risk register is maintained with periodic review.

Whichever title an organisation uses, the reporting line runs to senior management and to CERT-In, so the audit report has an external reader by design.

The clocks that were already running

Paragraph 3.2.1 restates obligations that trace back to the CERT-In Directions of 28 April 2022 rather than originating here. Incidents are reported to CERT-In within six hours of being noticed. Incident logs are kept for "a minimum rolling period of 180 days, accessible to authorities for audit or forensic investigation". Point-of-contact details are shared with CERT-In and kept current.

A six-hour clock is a rehearsal problem rather than a policy problem. Six hours is short enough that whoever is on shift at three in the morning needs the form, the address and the authority to send it without waking anyone up first. The framework supplies two of those three: Annexure C carries CERT-In's incident reporting format and Annexure D the contacts. The authority to send is the one the organisation has to grant itself.

Vendors, and the report you are entitled to

Paragraph 9.3(c) covers outsourcing, and one line in it is worth putting into procurement templates: "Information security audit report of the vendor to be made available to Procuring entity on periodic basis or when required." The same paragraph lists a right to audit the vendor's contractual responsibilities, or to have those audits carried out by third parties, and background verification of all officials.

For an operator assembling a ground segment from suppliers, that is a contract clause rather than a testing activity, and it is cheaper to write into the first contract than to negotiate into the fifth.

Where to start

Settle the TT&C scope before anything else. Live spacecraft, engineering model or simulator is the decision that sets the cost, the timeline and the rules of engagement for the whole pre-launch test.

Put the event triggers on the compliance calendar. Each major launch, each ground network expansion and each vendor onboarding carries a control review under paragraph 9.3(b), and none of them arrives on a fixed date.

Work Annexure B before the auditor does. The framework closes with a self-assessment maturity checklist, and paragraph 9.3(b) points entities at it to measure progress from baseline compliance to advanced resilience. It is the cheapest gap assessment available, because it is the one the framework wrote for itself.

Security Brigade has been CERT-In empanelled since 2008 and works across network, application and API penetration testing, source code review, and the annual audits Indian regulators require.