For the engagement owner. An approved supplier login should lead only to the agreed task, for the agreed period, with a session that the organisation can end and explain.
Start with the maintenance task
List the maintenance activities the supplier actually performs: applying an application update, diagnosing an interface fault or supporting a hosted portal. For each activity, identify the person or service identity, the entry point, the target system and the owner who approves access. A contract that says “technical support” is not a sufficient permission model. Two suppliers using the same gateway may need very different access to clinical applications and infrastructure.
Build the assessment around a dedicated test account and an agreed maintenance scenario. Confirm whether the gateway, endpoint and identity service are owned by the healthcare organisation or another party. Testing permission must cover each part of the proposed activity.
Read diagram text
- Approval
- Named person and maintenance task
- Session
- Gateway to approved target
- Revocation
- End access and reconcile events
Establish the expected session lifecycle
Describe how access starts, how long it lasts and what should happen when approval expires. Include existing sessions, browser sessions, cached credentials and any downstream service tokens within the agreed scope. Disabling a login account and terminating an already established session are different actions. Record the intended behaviour before testing so the result is compared with a real requirement.
Prepare an owner who can apply and reverse the access change during the window. Use a harmless synthetic object to observe continuing access; avoid viewing real patient records merely to show that a session remains usable. The test should leave a short, intelligible evidence trail.
Check reach after the gateway
A gateway can authenticate a user correctly while allowing an unnecessarily broad route beyond it. Compare the approved support destination with one explicitly prohibited canary destination. Choose a method that demonstrates reach without changing the target system. Check whether the supplier can choose a different destination, inherit an unintended role or use a shared identity that prevents attribution. Any further activity requires its own authorisation.
The hospital remote maintenance access guide develops this boundary for clinical estates where medical engineering and IT may control different portions of the route. The operational contacts need to be able to act together.
Read diagram text
- Approved destination
- Permit the authorised task
- Other destination
- Deny the comparison route
- Expired approval
- Apply the documented expiry rule
Observe revocation with the defenders
Agree a short sequence: open the approved test session, record its identifier, revoke the relevant permission and attempt the same harmless operation again. Record elapsed time and the service's response without assuming that every product promises immediate termination. Ask the gateway and application owners to locate the corresponding events. A failure to correlate them can be an accountability issue even when the access decision itself is correct.
Where a session crosses several systems, state which component ended access. A disconnected gateway does not demonstrate that an independently issued application token was revoked; that token needs its own approved check.
Read diagram text
- Approval record
- Owner, task and expiry
- Session record
- Identity, target and timestamps
- Revocation record
- Observed access and audit events
Translate the result into a treatment plan
A recommendation should identify the failed boundary. Possible treatments include narrower destination rules, individual accounts, shorter approvals, explicit downstream revocation or better session-to-ticket correlation. Specify the tradeoff for support operations and the owner responsible for implementation. Avoid assuming that one new security product resolves an identity, network and process problem simultaneously.
For another perspective on layered access, our bank privileged access and segmentation guide separates authenticated entry from the authority to reach and act on a protected service. The control principle transfers; the clinical operating constraints remain specific to healthcare.
Leave a repeatable evidence package
Retain the approval reference, test identity, session identifier, permitted target, prohibited comparison, timestamps and observed results. Redact secrets and patient information. Record cleanup, including removal of temporary accounts and confirmation that no test session remains active. The package should let the service owner repeat the check after a gateway change without reconstructing the entire engagement.
Use the healthcare pentest readiness checklist to prepare the permission owners and test data. If any part of the lifecycle cannot be tested safely, report it as a specific coverage limitation with an owner and a proposed next step.
Read diagram text
- Create the canary
- Use synthetic data and a test identity
- Coordinate the change
- Have gateway and service owners ready
- Reconcile and clean up
- Remove accounts and close test sessions
Primary sources
General information, not a compliance opinion. Confirm legal applicability and testing requirements for your entity and jurisdiction.
This guide and the related sector publications linked above are published by Atlant Security. Technical examples are planning examples, not claims about completed client tests.
