By Quokka Advisory
An access change in an operational environment can affect production, maintenance or recovery. Before applying a control, understand the service it supports and what an interruption would mean. That operating context should shape the design and the change plan.
Quokka's approach connects security with the infrastructure and networks that keep the service running. We plan changes around dependencies, containment and recovery. A gateway or restricted network zone has to fit that wider design, including the legacy paths it cannot control.
Use the following method with engineering, operations and the service owner. Agree what the asset can support, which changes you can test and who will make the decision if the observed behaviour differs from the plan.
Map routine work and exceptional access
Document how operators, administrators, suppliers and workloads connect. Record the destination, protocol, business purpose and owner of each required flow. Include backup, recovery and local maintenance paths.
Use existing records and observations, then validate them with the people who operate the system. A connection that appears unusual during routine monitoring may support a planned shutdown or a recovery task. The team needs that context before blocking it.
For remote support, define the request, approval, identity check, destination and permitted activity. Include the process for extending a session when work takes longer than expected, along with the authority to end access.
Place controls on supported paths
A legacy web application may support an access proxy that adds stronger authentication. Another system may need a controlled administration host and restricted network routes. Select the pattern that fits the protocol, application behaviour and support constraints.
Prevent users from reaching the protected resource through an ungoverned route. Test direct connections, alternate interfaces and maintenance paths. If the team cannot close a route, document its controls and remaining exposure.
Keep the distinction between gateway identity and activity inside the application. When a downstream system requires a shared account, the team may need additional credential custody and session correlation to preserve accountability. Record the attribution limits that remain.
Handle unprotected protocols explicitly
Some systems cannot support the preferred transport protection. Identify the segment where information remains exposed and limit the systems and people that can reach it.
Use supported protection on other parts of the path where feasible. Verify the resulting design through configuration review or an approved observation method. Do not assume that encrypting the remote connection also encrypts the final connection to the asset.
Give the exception an owner and a review date. Include the exposure in the service's treatment plan, together with any replacement or retirement decision.
Validate changes against operational needs
Segmentation rules can interrupt required communications. Endpoint agents, scans and updates can also affect unsupported or fragile assets. Confirm the proposed method with the relevant engineering and support teams before deployment.
Test in a representative environment where possible. Use an approved change window and a rehearsed rollback for production changes. Define the observations that would trigger restoration of the previous configuration.
Containment needs the same discipline. Automatically isolating an asset may disrupt a physical process. Agree which conditions justify denying new access, restricting a route, ending a session or escalating to an operator. The appropriate response depends on the system and the operational consequence.
Keep residual risk and recovery visible
Retain evidence that shows the approved path works and the prohibited path fails. Record the support workflow, session expiry and revocation behaviour. Where the asset cannot provide detailed logs, describe the coverage available from the surrounding controls and the blind spots that remain.
Exercise emergency access and recovery with the operating team. They need to know who can authorise the action, which credentials or routes to use and how to return the service to normal control afterwards.
Use the next review to examine whether the compensating controls still match the service, its users and its dependencies. Keep longer-term treatment in the same conversation so temporary arrangements do not lose ownership as staff and suppliers change.
Download the Quokka Zero Trust Architecture Implementation Guide for the legacy and OT control matrix, broader implementation guidance and acceptance checks to use in your next access review.