Safe-to-Host Certificate: What It Is, Who Needs It, and How to Obtain It

The Safe-to-Host certificate is one of the most misunderstood documents in India's government IT ecosystem. Technically, it is a formal declaration issued by a CERT-In empanelled Information Security Auditing Organisation, confirming that a specific system, application, or website has been assessed against a defined security baseline and found acceptable for hosting on government infrastructure. Practically, it is the gating document that the National Informatics Centre (NIC), state IT departments, and central government agencies require before a new or significantly updated website or application is moved to production on government-managed hosting (NIC Data Centres, NICSI hosting, State Data Centres).

The regulatory basis for Safe-to-Host

Safe-to-Host requirements originate from MeitY guidelines for government website security, NIC's Website Policy, and various state-level IT security policies that reference CERT-In's technical standards. The Government of India's Guidelines for Indian Government Websites (GIGW) specify minimum security requirements that a website must meet before going live on .gov.in or .nic.in domains. NIC's own hosting policies extend these requirements and make CERT-In empanelled audit a pre-condition for hosting approval. For central PSUs, the Department of Public Enterprises has issued advisories aligning PSU IT security practices with CERT-In standards, effectively making Safe-to-Host a de facto requirement for any new application deployment.

Who needs a Safe-to-Host certificate

The explicit requirement applies to: central government ministries and departments deploying new or significantly updated websites and web applications; NIC-hosted applications for state and central government; PSUs hosted on government or government-affiliated infrastructure; state government portals on State Data Centres. Beyond explicit requirements, Safe-to-Host certificates are increasingly cited in central government procurement tenders as a pre-qualification criterion for vendors supplying IT systems to government — not just for the vendor's own applications, but as evidence of the vendor's security assessment capability.

There is also a growing commercial overlap: private sector firms that supply SaaS or hosted applications to government clients are asked to provide Safe-to-Host certificates or CERT-In empanelled audit reports as part of vendor onboarding. This is most common in defence, critical infrastructure (power, water, telecom), and banking sector government entities. A CERT-In audit engagement is the starting point for any of these scenarios.

What a Safe-to-Host audit actually covers

A Safe-to-Host assessment is a security review aligned to CERT-In's prescribed audit scope for government applications. The assessment typically covers: web application vulnerability assessment and penetration testing (OWASP Top 10, injection, authentication, access control, sensitive data exposure), infrastructure review (server configuration hardening, OS patch level, web server and application server configuration), SSL/TLS configuration (certificate validity, cipher suites, protocol versions), content security (absence of malicious scripts, drive-by download vectors, defacement vulnerability), and code review scope where source code is available. The output is a formal report plus a declaration letter on the empanelled auditor's letterhead, certifying the system has been assessed.

The audit process: how long and what to prepare

A Safe-to-Host engagement typically takes five to ten working days depending on application complexity. Preparation from the client side includes: providing the staging or pre-production URL and test credentials with sufficient permissions to exercise all application functions, completing a scoping questionnaire (technology stack, hosting environment, data sensitivity, user roles), and ensuring the application is feature-complete and code-frozen during the assessment window. Assessments conducted on applications that are actively being changed produce unreliable results — a finding may be remediated during the test window without the tester being aware, or a new vulnerability may be introduced.

What disqualifies an application from receiving the certificate

Applications with critical or high-severity findings are not issued a Safe-to-Host certificate until those findings are remediated and verified by the auditor. CERT-In's prescribed severity thresholds define what must be fixed before certification: any Remote Code Execution, SQL injection, authentication bypass, or sensitive data exposure finding at CVSS score 7.0 or above must be resolved before the certificate can be issued. This means the audit must be scheduled with sufficient lead time before the deployment date — attempting to rush a Safe-to-Host audit in the week before a government launch is a recipe for delays. Medium-severity findings are documented with remediation recommendations and a timeline but typically do not block certification, depending on the nature of the finding.

CyVigilant gets you CERT-In audit-ready and delivers Safe-to-Host audits through its CERT-In empanelled partners. To schedule an assessment, visit our CERT-In audit service page or talk to an expert.