Secure communication is built on trust.
Trust that identities are valid. Trust that keys are protected. Trust that certificates have been issued correctly. Trust that systems are speaking to the right systems. Trust that software has not been tampered with. Trust that partners are following agreed security procedures.
Most of the time, this trust sits quietly in the background.
It becomes visible when something goes wrong.
A privileged credential may be compromised. A certificate may expire unexpectedly. A signing key may be suspected of exposure. A supplier may disclose a vulnerability. A communication channel may show unusual traffic. A partner may report unauthorised access. A monitoring system may detect activity that does not match normal behaviour.
At that point, secure communication becomes an incident-response problem.
The question is no longer only whether the system was designed securely. The question is whether the organisation can act quickly, confidently and in coordination with others.
For space research environments, this matters because communication often crosses organisational and technical boundaries. Research institutions, technology providers, infrastructure operators, suppliers and public-sector stakeholders may all depend on shared trust assumptions. If one part of the communication chain is affected, the response may need to involve several parties.
Preparedness is therefore essential.
Ownership and visibility
The first requirement is clear ownership.
When a secure communication incident occurs, teams need to know who is responsible for making decisions. Who can revoke a certificate? Who can disable access? Who can rotate keys? Who can suspend a partner connection? Who can approve emergency changes? Who can communicate with suppliers or project partners?
If these responsibilities are unclear, response slows down.
In many organisations, communication security spans multiple teams: cybersecurity, network operations, identity management, application owners, infrastructure teams, legal, procurement and project leadership. Each may own part of the trust chain. Incident response must bring these responsibilities together before an incident occurs.
The second requirement is asset and dependency visibility.
It is difficult to respond to a communication incident if the organisation does not know which systems, certificates, keys, services or partners are affected. A suspected key exposure, for example, should immediately raise practical questions. Where is that key used? Which systems depend on it? Which certificates or sessions may be affected? Which partners need to be informed? Can it be rotated without disrupting critical services?
Without an inventory, these questions become guesswork.
For space research, where systems may be specialised and partnerships complex, visibility is especially important. Communication paths should be mapped. Critical certificates and keys should be documented. Supplier dependencies should be understood. Contact points should be maintained.
Revocation, replacement and containment
The third requirement is prepared revocation and replacement procedures.
Many communication incidents require changing trust material. Certificates may need to be revoked. Keys may need to be rotated. Credentials may need to be reset. Tokens may need to be invalidated. Access permissions may need to be reduced or removed.
These actions should not be improvised under pressure.
A well-prepared organisation should know how to revoke and replace trust material safely. It should understand the operational impact. It should have tested procedures for high-priority systems. It should know which services may require restart, reconfiguration or partner coordination.
In secure communication, the ability to replace trust quickly is part of resilience.
The fourth requirement is containment.
If a communication channel, identity or system is suspected of compromise, the first priority is to limit further exposure. This may involve disabling accounts, isolating systems, restricting network paths, suspending API access, blocking suspicious certificates, pausing file transfers or temporarily shifting to approved alternative channels.
Containment decisions must balance security with continuity.
In research environments, shutting down communication completely may disrupt important work. Allowing communication to continue without controls may increase exposure. Response plans should therefore identify graded containment options: restrict, isolate, monitor, suspend or fail over depending on the severity of the incident.
Evidence, partners and suppliers
The fifth requirement is evidence preservation.
Incident response depends on understanding what happened. Logs, alerts, certificate records, access events, network flows, endpoint data, API calls and administrative actions may all be relevant. If evidence is overwritten, deleted or inaccessible, investigation becomes harder.
Communication systems should therefore be designed with incident response in mind.
Logging should be sufficient to reconstruct key events. Time synchronisation should be reliable. Access to logs should be controlled. Retention periods should match risk. Sensitive metadata should be protected, but not unavailable when legitimately needed for investigation.
The sixth requirement is partner coordination.
In space research, incidents may not stay within one organisation. A compromised partner credential may affect shared infrastructure. A supplier vulnerability may apply to several systems. A certificate issue may interrupt interoperability. A communication anomaly may be visible in one environment but caused by another.
This requires clear coordination channels.
Partners should know who to contact, how quickly notifications should be made, what information can be shared, and how joint decisions will be handled. These arrangements should be documented before an incident occurs.
Trust between organisations is strengthened when response expectations are clear.
The seventh requirement is supplier engagement.
Suppliers often play a critical role in secure communication environments. They may manage software updates, cryptographic modules, identity services, hardware platforms, communication gateways or monitoring tools. When an incident involves a supplier component, organisations need timely and accurate information.
This requires more than a generic support email.
High-priority suppliers should have defined escalation paths, vulnerability disclosure procedures, support commitments and security contacts. Contracts should address incident notification, patch availability, forensic support and lifecycle responsibilities.
Supplier readiness can directly influence incident response speed.
Communication, recovery and learning
The eighth requirement is communication discipline.
During a security incident, internal and external communication must be controlled. Teams need accurate information, but uncontrolled updates can spread confusion. Partners may need to be informed, but premature or incomplete statements can create unnecessary concern. Technical teams may need to act quickly, but decisions should be recorded.
Good incident communication is clear, factual and role-based.
It should define what is known, what is uncertain, what actions are being taken and what decisions are required. In multi-partner research environments, this discipline is especially important because technical uncertainty can quickly become organisational uncertainty.
The ninth requirement is recovery planning.
Incident response does not end when the immediate threat is contained. Systems must return to a trusted state. Credentials must be reissued. Keys and certificates may need replacement. Monitoring may need to be heightened. Partners may need confirmation that communication can resume. Users may need new procedures.
Recovery should be deliberate.
A system should not be treated as trusted again simply because it is online. The organisation should confirm that the cause has been addressed, affected trust material has been replaced, access has been reviewed and monitoring is in place.
In secure communication, recovery is the process of rebuilding confidence.
The tenth requirement is learning.
Every incident or near miss should improve the system. Did the organisation know which assets were affected? Were owners clear? Were logs sufficient? Could keys be rotated quickly? Did suppliers respond as expected? Were partners informed through the right channels? Did containment options work? Were there manual workarounds that created additional risk?
The answers should feed back into architecture, governance and training.
Resilience improves when lessons become changes.
Exercises are one of the best ways to identify gaps before a real incident. A tabletop scenario involving an expired certificate, suspected key compromise, supplier vulnerability or unauthorised partner access can reveal weaknesses quickly. It can also help technical and leadership teams understand their roles.
For communication systems, exercises should include the trust chain, not only the network.
The COSMOS-SECURE perspective
COSMOS-SECURE focuses on secure communication in space research because trust must be protected throughout the lifecycle of a system — including moments when that trust is challenged.
Strong encryption, good architecture and careful planning reduce risk. They do not remove the need for response capability. Incidents can still happen through human error, supplier issues, software vulnerabilities, credential compromise or operational mistakes.
The organisations best prepared for those moments are the ones that have already asked the difficult questions.
What if a key is exposed? What if a certificate fails? What if a partner account is compromised? What if a supplier update is untrusted? What if communication metadata shows abnormal activity? What if systems need to continue operating under restricted conditions?
For space research, secure communication is too important to depend on improvisation.
Incident response should be built into the communication model from the beginning. Ownership, visibility, revocation, containment, evidence, coordination, supplier engagement, recovery and learning are all part of trusted communication.
Security is tested when something goes wrong.
Resilience is proven by how well the organisation responds.