Physical Security for Data Sovereignty in Enterprise File Sharing

Data sovereignty is often discussed in abstract terms: jurisdictions, legal frameworks, contractual rights, and compliance attestations. Physical security is where those abstractions stop. The hardware holding your organisation’s sensitive data either sits in a facility you control or it does not. The cryptographic keys protecting that data are either held in hardware modules you operate or they are not. When a storage device reaches end of life, your team either destroys it directly or it passes through a chain of custody you cannot fully verify.

These are not edge cases. They are the operational questions that distinguish genuine data sovereignty from compliance theatre. For physical security managers, audit teams, and CISOs responsible for data centre and hardware security posture, the evaluation of an enterprise file sharing platform must include four specific questions: where does the hardware live, who can physically access it, who controls the cryptographic keys and in what hardware, and what happens to storage media when it needs to be destroyed? This post addresses each question directly, examines the relevant certification and standards landscape, and explains how deployment model shapes the answers.

Executive Summary

Main idea: Physical security in enterprise file sharing is a deployment model question before it is a vendor certification question. An on-premises deployment places the hardware inside the customer’s own facility, making physical access controls, media destruction, and HSM operation entirely customer-determined. A vendor-operated cloud deployment transfers physical security responsibility to the vendor’s data centre partners, with BSI C5, ISO 27001, FedRAMP, and IRAP certifications providing third-party assurance. Customers with the highest physical sovereignty requirements — defence, critical infrastructure, financial market infrastructure — should evaluate on-premises deployment as the starting point, not a fallback.

Why you should care: NIS 2 Article 21 requires operators of essential services to implement appropriate physical and environmental security measures for information systems. ISO 27001 Annex A controls A.7 (Physical controls) apply to both customer-operated and vendor-operated facilities, but the customer’s ability to verify them is fundamentally different depending on whether the hardware is theirs. BSI C5 and FedRAMP High both include explicit physical protection (PE) control families, providing structured third-party assessment of vendor-operated infrastructure. Understanding which controls belong to which party — and how to verify them — is the core physical security due diligence task.

5 Key Takeaways

1. On-premises deployment gives customers complete physical sovereignty over their file infrastructure. When the Kiteworks appliance runs on hardware the customer owns and operates, every physical security decision — access control, facility standards, environmental monitoring, visitor management — is determined by the customer. The vendor has no physical access path to the hardware unless explicitly granted. This is the strongest possible physical sovereignty posture and is directly verifiable without relying on vendor certifications.
2. Customer-operated HSMs hold encryption keys outside the vendor’s reach. Hardware Security Modules provide tamper-resistant key storage in dedicated cryptographic hardware. When the HSM is customer-operated and FIPS 140-3 validated, the vendor cannot access encryption keys regardless of its administrative access to the application layer. The Hold Your Own Key (HYOK) model — supported by validated providers including the SafeNet Luna Network HSM from Thales — means that even in hosted deployments, key custody can remain with the customer.
3. Media destruction control is a frequently overlooked sovereignty requirement. Who destroys storage media, under what procedure, with what evidence? In an on-premises deployment, the customer directly controls media destruction — no vendor chain of custody, no reliance on third-party certificates, no destruction scheduling that requires vendor coordination. In cloud deployments, media destruction responsibility sits with the vendor and is attested through certifications such as BSI C5 and ISO 27001.
4. Key ceremony procedures are as important as HSM hardware. A FIPS 140-3 validated HSM provides hardware-grade tamper resistance, but the security of the key it holds depends on the key generation ceremony: how the key was created, by whom, under what procedural controls, and with what audit trail. Formal, documented key ceremonies conducted under customer control are the procedural complement to HSM hardware and are required by frameworks including NIST SP 800-57 and PCI DSS.
5. Vendor certification of cloud facilities provides assurance, not control. BSI C5 Type 2, ISO 27001, FedRAMP High, and IRAP PROTECTED all include physical security assessment components and provide third-party evidence that vendor-operated facilities meet defined standards. But certification is an attestation of point-in-time compliance, not a live control. Organisations requiring real-time, independently verifiable physical security control must own the hardware.

Deployment Model and Physical Sovereignty

Physical sovereignty questions cannot be answered independently of deployment model. Whether the hardware is customer-owned on-premises, vendor-operated in a private cloud, or running in a public cloud depends on the deployment choice — and that choice determines the entire physical security landscape. Most enterprise file sharing evaluations focus on features and certifications without first resolving the deployment model question. That is the wrong sequence.

On-Premises: Full Customer Physical Control

In an on-premises deployment, the Kiteworks appliance runs on hardware the customer owns and installs in a facility the customer operates. Physical access to the server, storage, and network hardware is governed entirely by the customer’s own physical security programme. The customer determines which personnel are authorised to enter the server room, what environmental monitoring is in place, what multi-factor physical access mechanisms protect equipment, and what surveillance systems cover the facility. None of these are vendor decisions.

This matters for several specific reasons that are directly addressed in regulatory frameworks. NIS 2 Article 21(2)(e) requires “physical security and environmental security” as one of the baseline measures for essential services. ISO 27001 Annex A.7 (Physical controls) includes controls covering secure areas, physical entry controls, securing offices and equipment, monitoring physical security, and protecting against environmental threats. When the customer operates the hardware, every one of these controls is within the customer’s direct implementation and audit scope — verifiable through first-party evidence without dependence on vendor attestations.

The on-premises model also determines who can conduct an unannounced physical inspection. Regulators and internal audit teams can walk into the customer’s facility at any time and verify physical controls directly. In a cloud deployment, access to the vendor’s data centre for physical inspection requires prior coordination, is typically limited to indirect observation, and may require the vendor’s facilitation. For organisations subject to supervisory inspection requirements — particularly in financial services, defence, and critical infrastructure — this is not a procedural detail. It is an audit rights question.

What to verify: Confirm with the vendor whether on-premises deployment gives your team complete physical access to the appliance hardware — including the ability to add or replace physical security controls on the hardware itself (for example, tamper-evident sealing). Understand whether the vendor retains any remote access path to the appliance and under what conditions.

Vendor-Operated Infrastructure: Certification as Assurance

Kiteworks-operated cloud deployments run in facilities subject to structured third-party physical security assessment. BSI C5 (Cloud Computing Compliance Criteria Catalogue) Type 2 attestation covers physical security as an explicit component of its control framework, including requirements for physical access controls, surveillance, environmental protection, and media handling. A Type 2 report provides evidence of operating effectiveness over an assessment period — not just design adequacy at a single point in time.

ISO 27001 certification applies to the full information security management system, including physical and environmental security controls under Annex A.7. ISO 27001:2022 expanded the physical controls annex relative to the 2013 edition, adding explicit requirements for clear desk policy, equipment siting, and physical security monitoring. Kiteworks’ ISO 27001 certification covers its cloud infrastructure operations.

For Australian government workloads, IRAP PROTECTED classification requires physical security assessment under the Australian Government’s ISM (Information Security Manual), which includes specific requirements for the physical security of facilities processing PROTECTED information. For US government and defence-adjacent workloads, Kiteworks’ FedRAMP High In Process status involves assessment of the Physical and Environmental Protection (PE) control family at the High baseline — one of the most demanding physical security control sets in the US federal framework.

The key point is that these certifications provide credible, structured third-party evidence of physical security controls in vendor-operated facilities. They do not give the customer direct control over those controls. Organisations that require control — not just assurance — need the on-premises deployment model.

Hardware Security Modules: Key Custody and Cryptographic Sovereignty

Encryption at rest protects data from unauthorised access at the storage layer. But the protection only extends as far as the security of the encryption keys. If the vendor holds the encryption keys — or can access them — then the vendor can, in principle, decrypt the data. That is the fundamental cryptographic sovereignty question that HSM integration addresses.

A Hardware Security Module is a dedicated cryptographic device designed to generate, store, and manage encryption keys in tamper-resistant hardware. HSMs are distinct from software key management in that the key material never exists in plaintext outside the HSM boundary — key operations (encryption, decryption, signing) occur inside the device, and the device is designed to destroy key material on physical tamper detection. For high-assurance environments, HSMs are the expected mechanism for key management, not an optional enhancement.

FIPS 140-3 Validation: The Hardware Standard for Cryptographic Trust

FIPS 140-3 (Federal Information Processing Standard 140-3) is the US government standard for cryptographic module validation, jointly administered by NIST and the Canadian Centre for Cyber Security. It replaced FIPS 140-2 as the active standard and aligns with ISO/IEC 19790. FIPS 140-3 defines four security levels — Level 1 through Level 4 — with each level adding progressively stronger physical tamper resistance requirements.

Level 3 is the baseline typically required for enterprise HSM deployments in regulated environments: it requires physical tamper-evidence, tamper-detection and response mechanisms that zeroize critical security parameters on tamper detection, and identity-based authentication. Level 4 adds environmental attack resistance and is typically found in payment security and classified systems.

Kiteworks supports integration with customer-operated HSMs validated at FIPS 140-3 level. The documented integration partner for on-premises deployments is the SafeNet Luna Network HSM from Thales (formerly Gemalto) — a FIPS 140-3 validated module widely deployed in regulated financial services, government, healthcare, and defence environments. The SafeNet Luna HSM provides tamper-resistant key storage, formal key ceremony support, and audit logging at the hardware level. The HSM validation certificate can be verified directly on the NIST Cryptographic Module Validation Program (CMVP) database, providing independently verifiable evidence of the module’s cryptographic assurance level.

Hold Your Own Key (HYOK): Keeping Key Custody with the Customer

The Hold Your Own Key model is the architectural pattern by which key custody remains entirely with the customer regardless of where the application runs. In a HYOK configuration, the encryption key never leaves the customer’s HSM — or more precisely, the plaintext key never leaves the HSM boundary. When the application needs to decrypt data, it sends a decryption request to the HSM; the HSM performs the operation and returns the decrypted data (not the key). The vendor’s application layer never has access to the key material itself.

This distinction matters because it separates logical access (the vendor’s application can process data) from key custody (the vendor cannot independently decrypt data without the customer’s HSM being available and the request being authorised). If the customer withdraws the HSM from the key management path — by policy, by physical disconnection, or in response to a legal demand — the vendor cannot decrypt the data, regardless of what access it has to the application or storage layer.

Kiteworks supports HYOK for on-premises deployments, where the HSM is physically located within the customer’s facility and entirely under customer operational control. This configuration provides the strongest possible cryptographic sovereignty posture: the physical hardware holding the keys is in the customer’s facility, operated by the customer’s team, with no remote access path for the vendor to reach it.

Key Ceremony: Procedural Controls for Key Generation

A formal key ceremony is the documented procedure by which a cryptographic key is generated, split (if key splitting is used), loaded into an HSM, and activated under procedural controls that ensure no single individual has full access to the key material at any point. Key ceremony requirements are specified in NIST SP 800-57 Part 1 (Recommendation for Key Management), PCI DSS Requirement 3.7, and various sector-specific standards.

The ceremony matters because the security of all subsequent cryptographic operations depends on the integrity of the key generation event. A key generated without procedural controls — by a single operator, without witnesses, without documentation — is no more trustworthy than a software key managed in application memory, regardless of how secure the HSM is that stores it. The ceremony is the procedural trust anchor for the entire key lifecycle.

In on-premises Kiteworks deployments, key ceremony procedures are conducted entirely under customer control. The customer’s team sets the procedural requirements, selects participants and witnesses, determines whether split knowledge and dual control are applied, and generates the audit documentation. This is directly auditable by the customer’s own audit team and by external auditors — the ceremony records are first-party evidence held by the customer, not a vendor-provided attestation.

Media Destruction: The End of the Data Lifecycle

Data lifecycle management ends with storage media destruction. Most discussions of enterprise security focus on the beginning and middle of the lifecycle — encryption at rest, access controls, audit logging — and treat media disposal as a procedural footnote. For organisations subject to data protection regulation or classified information handling requirements, this is a mistake. The question of who physically destroys storage media, using what method, with what verification, is a sovereignty question with direct regulatory and contractual implications.

Customer-Controlled Destruction in On-Premises Deployments

When the Kiteworks appliance runs on customer-owned hardware, storage media destruction is entirely within the customer’s control. The customer’s team decides the destruction method — degaussing, physical shredding, cryptographic erasure, or a combination — implements the procedure, witnesses the destruction, and generates the disposal certificate. No vendor involvement is required, no scheduling coordination is needed, and no reliance on a third-party destruction chain is introduced.

This matters most for two specific regulatory scenarios. First, when regulatory requirements mandate that media destruction be performed within the customer’s own security perimeter — common in defence and classified environments — on-premises deployment is the only configuration that satisfies the requirement. Second, when an investigation or legal proceeding requires immediate cessation of all media operations, the customer team can act without any vendor coordination delay.

ISO 27001 Annex A.7.10 (Storage media) requires that storage media be managed through its full lifecycle, including secure disposal. The standard does not prescribe a specific destruction method but requires that disposal be performed in a manner appropriate to the sensitivity of the information stored. NIST SP 800-88 (Guidelines for Media Sanitization) provides the most widely referenced technical guidance for destruction methods and their applicability to different media types and sensitivity levels. In an on-premises deployment, the customer selects the appropriate method per NIST SP 800-88 guidance and applies it directly.

Vendor-Managed Destruction: Certification and Chain of Custody

In vendor-operated cloud deployments, storage media is part of the vendor’s (or the cloud provider’s) infrastructure. Media destruction is performed by the vendor or its data centre partners, attested through the relevant certifications. BSI C5 requires documented media handling and destruction procedures as part of its physical security criteria. ISO 27001 covers the same area under Annex A.7.10. FedRAMP’s PE control family includes media protection controls (MP family) that address sanitisation and disposal.

These certifications provide third-party evidence that documented destruction procedures exist and are followed. They do not give the customer direct visibility into when specific media is destroyed, which media held their data, or what destruction method was applied to their specific storage. For most regulated commercial organisations, this level of attested assurance is adequate. For organisations in the highest-sensitivity tiers — classified data, material non-public information, critical national infrastructure data — the absence of direct control and direct verification is a genuine limitation of the cloud deployment model.

What to verify: Ask the vendor to specify the contractual and operational chain of custody for storage media disposal. Confirm which certifications cover the data centre where your data resides — not just the vendor’s overall certification portfolio. Request the most recent BSI C5 or ISO 27001 attestation letter that covers the specific facility processing your data and confirm that media disposal is within scope.

Shared Responsibility: What the Model Means in Practice

The shared responsibility model is widely discussed in the context of cloud security, but it is particularly important for physical security because the responsibilities are cleanest at the extremes: fully on-premises or fully cloud-native. The ambiguity sits in hybrid and co-location configurations, which are where many enterprise deployments actually live.

Understanding which physical security controls belong to the customer and which belong to the vendor is not just a compliance exercise — it determines where your audit evidence needs to come from, which controls need to be tested in your own assessments, and where gaps are most likely to appear in a supervisory inspection.

Kiteworks Differentiation: Physical Security Across Deployment Models

Kiteworks supports a deployment spectrum from fully on-premises to vendor-operated cloud, with the physical security posture shifting along that spectrum. The following summarises the documented capability differentiators for physical security and HSM integration.

On-Premises Appliance Model

The Kiteworks appliance is designed to run on customer-owned hardware within the customer’s own facility. This is not a co-location arrangement or a private cloud hosted by Kiteworks — it is hardware the customer provisions, operates, and physically controls. The appliance can be deployed in data centres the customer operates under its own ISO 27001, BSI IT-Grundschutz, or sector-specific security programme, giving the customer complete physical sovereignty over the deployment.

Customer control extends to hardware selection, physical security mechanisms applied to the appliance (tamper-evident sealing, rack locking, access card requirements for the equipment room), environmental monitoring configuration, and media destruction procedures. The vendor has no physical access path to the hardware in this configuration — any remote access for support purposes requires explicit customer authorisation and is separately governed by the customer’s remote access policy.

HSM Integration with Leading Enterprise Providers

Kiteworks supports integration with the SafeNet Luna Network HSM from Thales, a FIPS 140-3 validated hardware module widely deployed across regulated industries. In on-premises deployments, the HSM is physically located within the customer’s facility and operates entirely under customer management. The HYOK architecture ensures that Kiteworks application processes submit cryptographic requests to the HSM but do not receive key material in return — only the result of the cryptographic operation. This means that access to the Kiteworks application layer — whether through a compromised credential, a support session, or a legal order directed at the software vendor — does not translate into access to decryption capability. The keys are in customer-controlled hardware that the vendor cannot reach.

Certifications for Vendor-Operated Infrastructure

For organisations using Kiteworks-operated cloud deployments, physical security assurance rests on the certification portfolio covering Kiteworks’ data centre infrastructure. BSI C5 Type 2 attestation provides the most detailed physical security evidence for EMEA organisations, with an assessment period that covers operating effectiveness rather than design-only. ISO 27001 certification covers the broader information security management system including physical controls. FedRAMP High In Process status indicates that the full PE control family at the High baseline is under assessment, which represents the most rigorous US government physical security control set for cloud services. IRAP PROTECTED classification provides equivalent assurance for Australian government workloads.

These certifications are cumulative evidence of physical security controls in vendor-operated facilities, independently assessed by qualified third-party assessors. They are the appropriate assurance mechanism for organisations that have determined that vendor-operated infrastructure is the right deployment model and need third-party verification that physical security meets regulatory and contractual requirements.

Conclusion

Physical security is the layer of data sovereignty that cannot be abstracted away by software controls or compliance certifications. The question of whether the hardware holding sensitive data is in a facility the customer controls — and whether the cryptographic keys protecting that data are in hardware modules the customer operates — has a direct operational answer that depends on deployment model, not vendor certification portfolio. For organisations where physical sovereignty is a genuine requirement rather than a compliance checkbox, the on-premises deployment model with customer-operated HSM integration provides the strongest and most directly verifiable posture available in enterprise file sharing today.

The regulatory direction across EMEA, the US federal sector, and Australia is toward more explicit physical security requirements, not fewer — NIS 2’s essential services provisions, BSI’s C5 evolution, and FedRAMP’s continued stringency on PE controls all point in the same direction. Organisations that establish clear, first-party-verifiable physical security controls now — through deployment model decisions, HSM architecture, and media destruction procedures — are building the evidence base that supervisory inspections will increasingly expect to see documented, not just attested.

Frequently Asked Questions