01 | EXECUTIVE PERSPECTIVE
Make accountability part of everyday lab work.
A shared instrument workstation can be essential to scientific continuity. A long acquisition, a vendor application or a sequence running overnight may depend on a persistent Windows session. Yet the account keeping the instrument running may say little about the person interacting with it. That creates a question for both laboratory leadership and cybersecurity: can the organisation explain access and activity without forcing scientists to reconstruct events after the fact?
CYRA addresses this challenge at the workstation: authenticate the person while retaining the shared Windows session, control interaction without ending the instrument application, and connect supported access events to the individual. Its wider platform extends this foundation towards application and data context, local file control and anomaly detection.
For laboratory leadership, the opportunity is to make security part of normal operation: simpler operator handovers, clearer responsibility and evidence that can be retrieved when it is needed. For cybersecurity and audit teams, the same workflow provides a basis for assessing who had access, whether policy was followed and where further investigation is required.
CYRA's objective is to preserve established instrument applications and scientific workflows on compatible workstations. Individual authentication, access policy and evidence collection sit around that workflow. Deployment includes configuration, compatibility checks and proportionate validation.
02 | RESEARCH CONTEXT
Readiness is improving. Evidence still matters.
IDC's January 2026 InfoBrief, Preparing for NIS2 and Beyond: The Next Phase of Cyber Resilience in EMEA, was sponsored by Microsoft. It draws on a survey of 2,000 European organisations across sectors. The following are organisational self-reports, not independent audit results. [1, pp. 4-5]
believed they were already NIS2 compliant.
IDC, p. 5expected to have the required measures within 12 months.
IDC, p. 5; survey-time expectationof Swedish respondents ranked inadequate timely, clear authority guidance among their top three challenges.
IDC, p. 8These cross-sector findings describe enterprise readiness and guidance challenges; they do not measure compliance or audit-failure rates within pharmaceutical discovery labs.
For R&D leaders, the operational question is closer to home: does the evidence on an instrument workstation support the organisation's access policy? Closing that gap begins with the everyday moments when people share equipment, leave a run unattended, retrieve raw data or investigate an unexpected change.
03 | SIX LABORATORY USE CASES
Turn everyday lab activity into accountable work.
The gap between a shared account and an identifiable person appears at predictable points in a lab's working day. The following use cases show how CYRA addresses those points, from operator handover to investigation and data access. Access and basic Log workflows are in evaluation; the data-context and intelligence capabilities are in development.
USE CASE 01 | ACCESS + LOG (BASIC) | IN EVALUATION
Hand over the workstation without ending the run.
The lab problem. Two scientists share an instrument PC. Ending the Windows session between users can interrupt the application or create additional setup work. Keeping the same account open preserves continuity but leaves the next person's use difficult to distinguish.
The CYRA workflow. CYRA Access authenticates each operator using a personal PIN, registered RFID badge or Azure AD (Microsoft Entra ID) credentials, according to the deployment. The transparent lock controls interaction while the underlying Windows session and instrument applications continue. The next operator authenticates individually; basic Log records the supported access events against the person, device and time.
Control and evidence. A named authentication record establishes who accessed the workstation at the handover. Application-level records provide the detail of scientific actions within that session.
Business value. Preserve the familiar instrument application and reduce avoidable session switching. Measure handover time, support requests and acquisition continuity across representative operator changes.
USE CASE 02 | ACCESS + LOG (BASIC) | IN EVALUATION
Protect interaction while an acquisition continues unattended.
The lab problem. A scientist leaves a workstation while an acquisition or file transfer continues. The application needs to remain active, but an unattended keyboard should not become an open invitation to change the run.
The CYRA workflow. The operator locks interaction through CYRA Access while the application remains in its existing session. An authorised person authenticates to resume interaction. Windows auto logon and auto-start are configured as part of CYRA Access; lab users do not need to handle the shared Windows password.
Control and evidence. Test locked-state behaviour and supported access records alongside an observable acquisition or transfer. IT retains responsibility for the underlying account, privileges and remote access. Network loss and recovery procedures form part of the continuity assessment.
Business value. Allow scientists to leave the workstation without relying on an exposed interactive session to keep work moving. Measure completion of ongoing tasks, time to resume work and the frequency of operator workarounds.
USE CASE 03 | LOG (BASIC) | IN EVALUATION
Answer who used the device before an investigation stalls.
The lab problem. An unexpected result or an audit sample triggers a request for the people who used a workstation during a particular period. A generic account, booking entry or paper note may leave the team searching through several records and asking scientists to remember events.
The CYRA workflow. Basic Log connects supported authentication and access events to individual users, devices and timestamps. An authorised reviewer uses those records to establish the access timeline, then examines the relevant instrument and application evidence. Log (premium), including the e-logbook, is in development to extend the logging capability.
Control and evidence. Record the events covered by the evaluated build, align clocks and agree retention and review responsibilities. Keep unexplained gaps visible. Access evidence narrows the investigation; it does not by itself prove who changed a method or produced a result.
Business value. Give laboratory, security and audit teams a shared starting point. Measure the time required to reconstruct a sampled access window and the completeness of records against observed workstation use.
USE CASE 04 | TRACE | IN DEVELOPMENT
Connect a lab session to its application and data context.
The lab problem. Raw data accumulates in local folders used by several people. When a file needs review, the team must work backwards from its location and timestamp to understand which session and application activity may be relevant.
The CYRA approach. Trace is being developed to observe application usage and data folders during sessions and build session metadata. This context is intended to connect user, device, time and data activity, giving reviewers a clearer route from a workstation session to the records they need to examine.
Control and evidence. Distinguish the person using the workstation from the run initiator, sample submitter and scientific data owner. For queued or asynchronous runs, a file may be created during someone else's session. Reliable ownership attribution therefore requires run or sample identifiers and a validated link to the scientific record.
Business value. Reduce manual searching across folders and applications. An evaluation of Trace should measure retrieval time and the accuracy and completeness of session-to-data links against a known set of runs.
USE CASE 05 | VAULT | IN DEVELOPMENT
Give shared-device data a defined access boundary.
The lab problem. Several scientists use the same workstation, but they do not necessarily need access to every locally stored dataset. A shared session can make that distinction difficult to maintain through account permissions alone.
The CYRA approach. Vault is being developed to securely store data generated during a session on the shared lab device and authorise which stored files each person may open. Its role is to bring individual file-access decisions into a shared-device workflow.
Control and evidence. Define authorised users, collaboration needs and recovery responsibilities with the data owner. Evaluate permitted and denied file access, instrument write behaviour and recovery. File authorisation, application access and backup remain distinct requirements.
Business value. Support controlled access to local session data while preserving the shared workstation model. Measure the effort needed to administer access and retrieve authorised files, together with the impact on routine scientific work.
USE CASE 06 | TRACK + AURA | IN DEVELOPMENT
Focus review on unusual session activity.
The lab problem. As access and session records grow, reviewing every entry becomes less practical. Teams need a way to identify activity that merits attention without treating ordinary differences in research work as incidents.
The CYRA approach. Track is being developed to learn the empirical session signature of each user and device. Aura is being developed to detect anomalies and flag deviations for investigation. Together, their intended role is to add context and prioritisation to the review process.
Control and evidence. Establish representative operating patterns, account for legitimate changes in experiments and assign a reviewer to each flagged event. Assess missed events, false positives and the evidence available to explain a flag. A deviation is a reason to investigate, not a finding of wrongdoing.
Business value. Direct attention towards activity that warrants investigation. Future evaluation should measure review effort, actionable findings and the effect of changing lab workflows on detection quality.
The scientist needs continuity. The lab manager needs accountability. IT needs manageable access. Security and audit need records they can interpret. CYRA's platform connects these needs around the shared workstation, with capability scope and responsibilities established for each deployment.
04 | PRESERVE SCIENTIFIC WORK
Design the control around the real workflow.
NIST's OT security guidance treats performance, reliability and safety as important constraints when securing systems that interact with the physical environment. That is a useful starting point for compatible instrument workstations, rather than assuming every office-desktop control transfers unchanged to a lab. [4]
Bring discovery into the cybersecurity control environment.
NIS2 Annex I includes entities carrying out medicinal-product R&D. Applicability depends on the entity, scope rules and national implementation. Article 21 addresses risk-management measures including incident handling, continuity, access policies and asset management. A workflow's non-GxP status alone does not establish a cybersecurity exemption. [2, Articles 2 and 21; Annex I]
Sweden's cybersecurity law entered into force on 15 January 2026, introducing protective measures, significant-incident reporting and supervision for in-scope operators. [3] Workstation controls should sit alongside the instrument and application controls required for the scientific workflow's intended use.
Introduce CYRA with continuity as an acceptance criterion.
- Describe what must keep running. Record application versions, acquisition duration, data paths, licence dependencies, vendor restrictions and the consequences of logoff, reboot or network loss. Include unattended and overnight work.
- Separate the shared session from the named person. Where justified, retain the application session while authenticating the individual at an approved interaction boundary. IT must still own the underlying account, its privileges and credential lifecycle.
- Test ordinary work and difficult transitions. Observe acquisition progress and data output through lock, unlock and handover. Test an unauthorised user, a revoked identity, network loss, service restart and recovery using agreed safe procedures. Record the actual failure behaviour.
- Approve the exception and its limits. A shared-account arrangement needs documented scope, a risk owner and review dates. If the added control cannot meet the objective, agree a different design or additional safeguards before broader use.
The aim is to retain instruments, application sessions and established scientific procedures. What changes is the individual authentication step, the surrounding access policy and the evidence process. Compatibility, performance and the impact of deployment must be demonstrated for the selected environment.
CYRA operates within the lab's wider security environment. Account privileges, remote access, network controls, patching, backup, recovery and endpoint protection retain their own owners and evidence. Include alternate access paths and privileged accounts in the assessment so the control boundary is clear.
05 | AUDIT EVIDENCE CHECKLIST
Prepare evidence an independent reviewer can follow.
A useful audit record connects a control objective to the way the lab actually operates. The following checklist organises that evidence around the Govern, Identify, Protect, Detect, Respond and Recover functions of NIST CSF 2.0. It covers the wider lab control environment alongside CYRA. [5]
On smaller screens, scroll the table horizontally.
| Control objective | Evidence to prepare | Question to test | Suggested owner / CSF theme |
|---|---|---|---|
| Know the scope | Workstation/instrument inventory, intended use, network and data dependencies, named business and technical owners. | Does the inventory match a walk-through of the lab, including vendor-managed devices? | Lab IT + instrument owner Govern / Identify |
| Control individual access | Approved users and roles, enrolment and revocation records, shared-account rationale, privilege and credential controls. | Can an unauthorised or revoked user interact with the system through any supported access path? | Identity team + lab manager Protect |
| Produce usable records | Supported-event catalogue, sample user/device/time records, time synchronisation, access to logs, retention and protection settings. | Can a reviewer reconstruct a sampled handover and identify missing or ambiguous records? | Security operations + system owner Protect / Detect |
| Explain data attribution | Application audit trails and run/sample identifiers where available; documented linkage rules and known attribution limits. | Could a queued run finish under a different person's session? How is ownership verified? | Scientific data owner + quality Identify / Protect |
| Respond to suspicious activity | Review responsibilities, escalation contacts, incident exercise, evidence-preservation steps and decision records. | Who acts on an unexplained event, and can they reach the instrument owner promptly? | Security operations + lab leadership Detect / Respond |
| Preserve and restore operation | Continuity tests, backup scope, restore results, approved fallback, recovery responsibilities and rollback procedure. | What happens to the run and its data when identity, network or workstation components fail? | Lab IT + continuity owner Recover / Protect |
| Govern change and suppliers | Approved configuration baseline, compatibility evidence, vendor support conditions, change history, residual risks and review dates. | Who reassesses controls after an application upgrade or a change in intended use? | System owner + quality + security Govern |
For an internal audit
Agree the control objective and sampling method before testing. Select normal shifts, handovers, unattended periods and relevant exceptions. Examine both control design and actual operation. Record who tested, when, on which build and configuration, what evidence was reviewed and which findings remain open. Give every finding an owner, priority and due date.
For an external audit
Prepare a concise evidence index linking each requirement to its owner, procedure, configuration and operating records. Preserve original records and document how extracts were produced. Restrict access to personal or sensitive scientific data. Make limitations visible: unsupported events, review gaps and approved exceptions should have explanations and remediation plans. The external assessor determines whether the evidence is sufficient for the applicable scope.
A useful evidence pack
Bring the scope and asset list; an approved access matrix; the shared-account risk decision; a configuration baseline; representative event samples; a continuity and recovery test record; access-review results; an incident exercise; and a findings register. A screenshot of a dashboard can illustrate a control. Operating records show whether people actually used and reviewed it.
06 | A PRACTICAL START
A 90-day preparation plan.
A focused CYRA evaluation starts with one representative workflow and a joint laboratory, IT and security team. The following 90-day sequence establishes the baseline, tests the control and supports an informed rollout decision. Timing depends on instrument criticality and local change-control requirements.
Establish the baseline
Choose a representative workflow and a jointly accountable lab/security team. Map people, devices, sessions and data. Confirm the audit scope and existing controls. Measure handover effort and evidence-retrieval time before introducing a change.
Output: a scoped risk assessment, baseline measurements and agreed success/failure criteria.
Evaluate safely
Use a suitable test environment or an approved low-risk pilot. Configure named access and supported records, then test normal use, revocation, unattended operation and recovery. Train operators on the small number of changed steps and how to report problems.
Output: observed results, compatibility findings, user feedback and a tested rollback plan.
Review the evidence
Repeat the baseline tasks, assemble the evidence pack and run a mock audit. Resolve or explicitly accept residual risks. Decide whether to expand, adjust the design or stop. Set owners and a recurring review cadence for any continued operation.
Output: a documented decision with measured value, retained controls, open findings and next steps.
07 | BUSINESS VALUE
Measure what the lab gets back.
CYRA's business case connects control quality with time returned to the laboratory. Named access records can reduce the work involved in reconstructing workstation use. Session continuity can reduce avoidable waiting at handover. Evaluate these benefits against the lab's existing process, including the effort required to administer and review the new control.
| Current approach | Measure before and during evaluation | Decision the evidence supports |
|---|---|---|
| Paper logs or no digital attribution | Record completeness, time to retrieve a user/device/time record, credential-administration requests and investigation effort. | Does the new process improve evidence quality with acceptable operating effort? |
| Personal Windows sessions | Handover time, profile administration, observed application interruptions and instrument waiting attributable to the handover. | Can session continuity improve without weakening access control? |
| An existing identity solution | Incremental evidence, user effort, integration burden, overlap, migration and retained-tool costs. | Is there a demonstrable reason to add or replace a control? |
Annual recoverable staff-hours = comparable events per year × observed minutes saved per event ÷ 60. Count net value only after licence, deployment, hosting, integration, support, training and retained-control costs.
Illustrative business case: 20 workstations × 4 handovers per working day × 220 days × 1 measured minute saved would equal about 293 staff-hours annually. This scenario assumes a one-minute saving; it is not a measured CYRA outcome. Use observed timings for an investment decision, count each benefit once and distinguish recoverable capacity from cash savings.
Track control quality alongside time: supported-event completeness against observed events, time to revoke access, unexplained evidence gaps and continuity-test results. Define thresholds with lab and security owners. Faster handovers would not justify a failed access control; more evidence would not justify an unacceptable risk to an acquisition.
08 | THE CYRA APPROACH
Shared devices. Accountable science.
CYRA brings six complementary capabilities to shared-account laboratory environments. Access establishes the individual identity; Log records supported events. Trace, Vault, Track and Aura extend that foundation towards session context, control of local data and investigation of unusual activity.
Access and Log (basic) are in evaluation. Log (premium), including the e-logbook, and Trace, Vault, Track and Aura are in development. Evaluation scope identifies the supported events, authentication methods and compatible applications for each deployment.
| Product | Role | Status |
|---|---|---|
| Access | Authenticate the person within the shared-session workflow. | In evaluation |
| Log | Record supported activity with user, device and time. Premium includes the e-logbook. | Basic in evaluation; premium in development |
| Trace | Observe application usage and data folders during sessions to build session metadata. | In development |
| Vault | Secure local session-generated data and authorise which stored files a person can open. | In development |
| Track | Learn the empirical session signature of each device and user. | In development |
| Aura | Detect anomalies and flag deviations for investigation. | In development |
The platform connects workstation identity with the evidence available at each layer. Application records remain important for scientific actions, and run or sample identifiers are needed where a session spans several people's work. This layered approach lets teams improve accountability while retaining the controls already serving their instruments.
A workstation-level approach offers a common starting point across compatible endpoints. The evaluation determines how CYRA fits with existing identity tools, vendor applications and security operations, and where it adds measurable value.
Start with one workstation and one evidence question.
Bring a representative lab workflow. Together, define what must keep running, which control needs evidence and how success will be measured.
Discuss a scoped evaluationRead the platform brochure (PDF)09 | REFERENCES & SCOPE
References.
- IDC. Preparing for NIS2 and Beyond: The Next Phase of Cyber Resilience in EMEA. January 2026, IDC #EUR154204026. InfoBrief sponsored by Microsoft. Page 4: full survey, n=2,000; page 5: self-reported readiness; page 8: country guidance challenges. Results reflect respondents' views at the time of the survey.
- European Parliament and Council. Directive (EU) 2022/2555 (NIS2). Article 2: scope; Article 21: cybersecurity risk-management measures; Annex I, Health: medicinal-product R&D entities. Applicability is subject to national implementation and entity scope.
- Government Offices of Sweden. Nu skärps kraven på svensk cybersäkerhet, 15 January 2026. Official announcement of the Swedish law's entry into force.
- NIST. SP 800-82 Revision 3, Guide to Operational Technology (OT) Security, September 2023. Guidance on OT security, including performance, reliability and safety considerations.
- NIST. The NIST Cybersecurity Framework (CSF) 2.0, February 2024. Framework for organisational cybersecurity risk management.
Published by ABRA Solutions AB, October 2026. Microsoft sponsored the cited IDC research; neither organisation endorses CYRA. Cybersecurity compliance depends on the organisation's applicable requirements, implemented controls and operating evidence.