Compliance is necessary.
It sets expectations. It creates accountability. It helps organisations demonstrate that they follow recognised rules, standards and procedures. In cybersecurity, compliance can support better governance, clearer documentation and more consistent controls.
But compliance is not the same as resilience.
A system can satisfy a checklist and still be fragile. It can meet a formal requirement and still be difficult to recover. It can pass an audit and still depend on outdated assumptions, unmanaged access, weak supplier controls or communication channels that cannot adapt to new threats.
For space research, this distinction matters.
Space research environments are complex. They involve sensitive data, specialised infrastructure, distributed teams, public and private partners, research institutions, suppliers and long operational lifecycles. Communication systems often connect many of these elements. If communication fails, is compromised or cannot be trusted, the impact can extend beyond a single technical system.
This is why security needs to move beyond compliance alone.
Resilience as the better model
The better model is resilience.
Cyber resilience is the ability to prepare for, withstand, respond to and recover from cyber threats while maintaining essential functions. It assumes that prevention is important, but not perfect. It recognises that systems must operate in changing conditions. It also accepts that security is not a one-time state, but a capability that must be maintained over time.
In secure communication, resilience begins with architecture.
Communication systems should be designed around clear trust boundaries. Organisations need to know which users, systems, services and partners are allowed to communicate, under what conditions and for what purpose. Identity, authentication, encryption, key management, logging and monitoring should work together as part of the architecture, not as separate controls added late in deployment.
This matters because many security failures occur between controls.
A certificate is valid, but the issuing process is weak. Encryption is enabled, but keys are poorly managed. Access is restricted, but privileged accounts are not reviewed. Logs are collected, but no one can interpret them. A supplier provides a secure component, but updates are delayed or undocumented.
Compliance may check that controls exist.
Resilience asks whether they work together under pressure.
From static assurance to continuous understanding
The first shift is from static assurance to continuous understanding.
A compliance exercise often captures a point in time. A resilience model requires ongoing visibility. Organisations need to understand how communication systems are used, where cryptography is deployed, which suppliers are involved, which data flows are most sensitive and which changes could introduce risk.
This is particularly important in space research, where projects evolve. New partners join. Systems are upgraded. Data sets grow. Research outputs are shared. Infrastructure is extended. Security assumptions that were valid at the beginning of a project may not remain valid years later.
The second shift is from control ownership to risk ownership.
In many organisations, cybersecurity controls are assigned to technical teams. They manage tools, configure systems and respond to incidents. But resilience depends on decisions that go beyond technical configuration: procurement, architecture, contracts, governance, budget, lifecycle planning and partnership management.
For secure communication, this means leadership must understand the strategic role of trust.
Who owns cryptographic risk? Who decides when systems must migrate to new standards? Who assesses supplier readiness? Who ensures that communication channels remain secure when project structures change? Who prioritises resilience when cost and schedule pressures appear?
These are not only IT questions.
They are organisational risk questions.
From minimum requirements to mission continuity
The third shift is from minimum requirements to mission continuity.
Compliance can define a baseline. Resilience must consider what happens when something fails. If a certificate expires unexpectedly, can communication continue safely? If a supplier vulnerability is disclosed, who evaluates the exposure? If a partner account is compromised, can access be contained? If a secure channel becomes unavailable, are there trusted alternatives? If cryptographic standards change, can systems be upgraded without major disruption?
These scenarios are practical. They determine whether a system can continue to support research under stress.
For space research, continuity is important not only because systems may be expensive or complex, but because collaboration itself depends on confidence. Partners need to trust that communication channels remain reliable, that data is protected and that incidents can be handled responsibly.
The fourth shift is from today's threat model to future adaptability.
A compliance-focused system may be designed to meet current requirements. A resilient system must be able to evolve.
This is especially relevant for the post-quantum transition. Organisations are beginning to prepare for future cryptographic risks that may affect widely used public-key systems. The exact timeline is uncertain, but the migration effort will be significant. Systems that are rigid, poorly documented or dependent on hard-coded cryptography will be harder to adapt.
Crypto-agility should therefore become part of resilience planning.
Secure communication systems should support controlled updates to algorithms, keys, certificates and protocols. They should allow migration without unnecessary disruption. They should give organisations visibility into where cryptographic mechanisms are used and which systems are most exposed.
From isolated security to ecosystem security
The fifth shift is from isolated security to ecosystem security.
Space research rarely happens inside one organisation. It depends on partners, suppliers, platforms and shared infrastructure. A resilience model must therefore extend beyond internal controls.
Organisations need to understand the security posture of key suppliers, the lifecycle of critical components, the update practices of technology providers and the trust assumptions behind shared communication channels. Partners should have clear responsibilities for access, incident reporting, key management and data handling.
Compliance may evaluate individual organisations.
Resilience looks at the trust chain between them.
The sixth shift is from documentation to exercised capability.
Policies are important. Incident response plans are important. Migration roadmaps are important. But documents only become useful when they are tested.
Can teams revoke and replace keys quickly? Can they identify affected systems after a certificate issue? Can they coordinate with partners during an incident? Can they restore communication from backups? Can they operate securely during partial disruption? Can they validate software updates before deployment?
Resilience grows through practice.
This does not mean every organisation needs complex simulations from the beginning. It means that critical procedures should be tested before they are needed. Gaps discovered during exercises are far less costly than gaps discovered during incidents.
The COSMOS-SECURE perspective
COSMOS-SECURE is focused on secure communication in space research because communication is one of the foundations of resilience.
Trusted communication enables cooperation. It protects data. It supports operational continuity. It helps organisations maintain confidence across distributed technical environments. When communication is weak, resilience is weak.
The project's perspective is that future-ready security must combine strong technical foundations with governance, adaptability and partnership. Encryption alone is not enough. Compliance alone is not enough. Security must be designed, managed and maintained as a long-term capability.
For organisations involved in space research, the path from compliance to resilience can begin with practical steps.
Identify the communication systems that matter most. Map data flows and trust boundaries. Review cryptographic dependencies. Strengthen identity and key management. Assess supplier and partner risks. Build crypto-agility into new systems. Test incident response and recovery procedures. Treat secure communication as part of mission continuity, not only as a technical control.
Compliance provides a baseline.
Resilience provides confidence.
For space research, the goal is not only to meet requirements. The goal is to build communication systems that can remain trusted as technology, partnerships and threats evolve.