PastWipe Strengthens Next Release With Client-Controlled Zero-Access Architecture

LONDON, UNITED KINGDOM — PastWipe has announced a substantial strengthening of the technical architecture planned for its next release, following detailed requirements raised by CISOs, security architects, incident-response specialists, insurers and enterprise technical evaluators.

The development programme is focused on making the PastWipe architecture more precise, deployable, measurable and suitable for integration into existing enterprise security environments.

At the centre of the next release is a strict zero-access operating model.

Client data will remain within the client’s own infrastructure, cloud account, virtual private cloud or approved trusted environment. Encryption and decryption will take place inside that client-controlled environment.

Cryptographic keys will remain under the client’s control through its own key-management system, hardware security module or equivalent security infrastructure.

PastWipe will not require access to client plaintext, client decryption keys or the underlying protected information.

The client controls the data. The client controls the keys. The client controls the security response.

PastWipe provides the technical framework through which those controls remain policy-bound, cryptographically enforceable and responsive to changes in the client’s security state.

A formally defined protection boundary

The next release will introduce a formally defined protection boundary covering approved files, records, database fields, documents, API payloads, backups and associated data flows.

The architecture will identify where encryption occurs, where authorised processing may take place, which systems may request access and which routes must pass through the enforcement layer.

This will allow enterprise customers to establish measurable enforcement coverage across primary systems, replicas, APIs, administrative tools, analytics platforms, data pipelines and approved third-party processors.

Authorisation based on more than identity

Access decisions will be based on more than the identity of the user requesting the information.

Short-lived, proof-of-possession authorisations will be bound to the requesting user or workload, the protected object, its current version, the permitted operation, the declared purpose, the applicable policy and the current incident state.

Possession of an authorisation token alone will therefore not be sufficient. The request must also originate from the approved workload or environment and satisfy the policy conditions attached to the protected information.

The system will include explicit controls against token replay, stale authorisation, policy rollback, object rollback and attempts to restore an earlier security state.

Workload and environment attestation

Workload and environment attestation will verify that protected information is being requested from an approved and current execution environment.

Depending on the client deployment, this may include verification of workload identity, software measurements, secure-boot status, trusted hardware, container or application integrity and the freshness of the attestation evidence.

Authorisation will therefore remain conditional on both the requester and the environment in which the protected operation is performed.

Scoped and deterministic incident response

The next release will introduce a more granular incident-state model, allowing security controls to be applied to an individual object, dataset, application, workload, key family, tenant, region or jurisdiction.

This will allow affected areas to be isolated without unnecessarily disrupting systems and information that remain trusted.

Revocation will be enforced through policy-controlled incident states and security epochs. When the applicable security state changes, authorisations issued under the previous state can be rejected across the defined scope.

The architecture will combine short-lived authorisations, signed security-state changes, revocation distribution, denial of further key operations and secure invalidation of cached authorisation state.

High-impact actions will support dual authorisation, customer-defined approval requirements and controlled escalation procedures.

Trusted operational recovery

The next release will include a structured recovery process covering containment, revalidation and the restoration of legitimate operations.

Recovery can require fresh environment attestation, replacement of affected credentials, key rotation, policy reissue, object rewrapping and reauthorisation of approved workloads.

This creates a controlled path from incident response to trusted operational recovery while keeping authority for the process with the client.

Stronger control-plane security

The PastWipe control architecture is also being strengthened through hardware-backed signing, mutual TLS, administrative separation, short-lived operational credentials, protected deployment processes and tamper-evident security logging.

Policy evaluation, authorisation issuance, incident-state management and key-management integration will operate as separately protected security functions.

Administration of the PastWipe software will remain technically separated from the client’s data and decryption keys.

Cryptographic evidence without exposing client information

Privacy-minimised cryptographic receipts will provide verifiable evidence of access decisions, policy state, revocation actions and recovery events.

These receipts can confirm that an approved action took place under a defined policy and security state without containing or exposing the underlying client data.

The evidence layer is being developed to support signature verification, trusted timestamps, tenant separation, selective disclosure, controlled retention and independent verification.

This will support technical audit, incident investigation, cybersecurity insurance assessment and regulatory reporting.

Validation through a complete breach lifecycle

The release will be validated through an end-to-end technical test covering the complete protected-data and incident-response lifecycle.

The planned validation process will include:

• Creation of protected information inside a client-controlled environment
• Encryption using client-controlled keys
• Authorised access from an approved and attested workload
• Simulated exfiltration of the protected object
• Prevention of unauthorised token replay
• Declaration of a scoped security incident
• Rejection of authorisations issued under the previous security state
• Migration to a clean and newly trusted environment
• Controlled restoration of legitimate access
• Independent verification of the resulting cryptographic evidence

Performance will be measured rather than assumed. The technical evaluation will record access latency, revocation propagation, recovery time, throughput, enforcement coverage and system behaviour during interrupted or degraded operating conditions.

Developed in response to enterprise requirements

The updated technical direction reflects the questions organisations ask when evaluating post-breach data-security technology.

Who controls the data? Who controls the keys? Which workloads may access protected information? How quickly can authorisation be withdrawn? Can a response be limited to the affected area? How is legitimate access restored? What evidence is available after the event?

The next PastWipe release is being designed to answer those questions through defined architecture, customer-controlled deployment and measurable technical evidence.

“Technical and customer feedback has helped us make the architecture more precise, more accountable and more suitable for enterprise deployment. PastWipe does not need access to the client’s data. Our role is to provide the framework through which the client retains control of the cryptographic right to use protected information beyond the traditional perimeter.”

The next stage of post-breach security

Traditional cybersecurity remains heavily concentrated on preventing information from leaving an organisation.

PastWipe addresses the security stage that follows by enabling protected information to remain dependent on current authorisation, trusted execution and the client’s own security state.

The next release represents an important engineering step in that direction, combining client-controlled encryption, short-lived cryptographic authorisation, workload attestation, scoped revocation, controlled recovery and independently verifiable evidence within one integrated architecture.

PastWipe will publish further technical information, validation results and controlled-pilot details as development progresses.