Foundry Academy · Cybersecurity Fundamentals · Lesson 4 of 6

Devices, updates, and approved software

Maintain a visible baseline for supported devices and software using secure configuration, timely updates, protection, encryption, and controlled exceptions.

Start the lesson

Your learning work, on this device

No signup, cloud storage, cross-device sync or verified completion. Saving is optional. This browser profile is shared with anyone who can use it; private mode, browser cleanup or storage limits may remove work. Use only fictional or non-sensitive material. Export a copy before relying on this device.

Not saved. Worksheets, answers and practice notes currently last only in this tab.

Practice markers are self-reported, never credentials.

01 · Explanation

Devices, updates, and approved software

Objective: Maintain a visible baseline for supported devices and software using secure configuration, timely updates, protection, encryption, and controlled exceptions.

An organization cannot protect devices it does not know about. Record owner, user, device identifier, operating system, support status, encryption, screen lock, endpoint protection, backup coverage, administrator rights, and last review. Separate ordinary user activity from administrative access. Use organization-managed devices for sensitive work where required and define whether personal devices are permitted, what data they may access, and how lost or departed devices are handled. Physical control matters: unattended screens, shared family devices, and unencrypted removable media can bypass otherwise strong online controls.

Use supported software from approved sources and apply security updates within risk-based targets. Critical exploited vulnerabilities may require faster action, but updates should still follow tested change and rollback procedures appropriate to the system. Remove unused applications, browser extensions, local administrators, and end-of-life devices. An exception should name the business reason, risk owner, compensating controls, expiration, and replacement plan. Do not run scanners, exploit tools, or configuration changes against systems without authorization. Complex infrastructure, vulnerability management, mobile-device management, and regulated environments require qualified technical specialists and vendor-specific guidance.

Before you begin

  • Confirm F03, F06, and F07; record that the device identifier, network location, endpoint telemetry, approved forensic playbook, clean device, evidence image, isolation status, and recovery authorization are not supplied.
  • STOP. If device identity, network location, telemetry, forensic playbook, trusted tooling, evidence image, or isolation status is missing or conflicts with F03/F06/F07, route the branch to authorized incident leadership and the forensic/endpoint owner; do not claim recovery approval or execute isolation, cleanup, rebuild, or return to service.

Original overview module anchor →

02 · Compare the artifacts

Supported work. Visible uncertainty.

This fictional, sanitized defensive-security case contains no real credentials, account numbers, personal data, or exploitable instructions. It is not legal, forensic, insurance, or cybersecurity assurance.

SilverPine payment-change incident

SilverPine Fabrication is a fictional 38-person manufacturer. At 9:12 a.m., accounts payable received an email inside an existing supplier thread requesting that the next $84,600 payment move to a new bank. The message used the supplier controller's display name and included an attached letter, but the phone number on the letter differs from the approved supplier record. At 9:26, an employee opened the attachment and entered a cloud password on a page that later disappeared. At 9:31, a push-notification approval arrived; the employee denied it and called the office manager. The manager told the employee to change the password from the same laptop but did not contact the incident lead. Email logs available to the internal administrator show a new forwarding rule created at 9:29 and a login from an unfamiliar region. The laptop reports that endpoint protection last checked in 11 days ago. The supplier master record can be changed by three accounts; one belongs to a former contractor and has no recorded multi-factor authentication. Backups run nightly to a connected network share. The dashboard is green, but the last documented restoration test occurred 14 months ago and recovered only one folder. The company's incident sheet lists names but no after-hours method, severity criteria, evidence-preservation steps, payment-hold authority, or customer and regulatory decision process. No payment has been released. Learners must map assets and responsibility, protect authentication and recovery, verify communication independently, manage device and software actions, assess data, vendor, and backup controls, and construct an authorized incident response. They must not investigate outside authorization, contact an attacker, destroy evidence, or declare breach scope and legal notification obligations without qualified review.

Supported example — reference only

Element
Possibly affected laptop
From or trigger
Credential was entered after opening the attachment.
To or outcome
Preserve state and obtain qualified triage direction before containment or credential action.
Evidence and source ID
F03, F06
Owner
Security incident/device owner
Open question
Approved playbook, device identifier, trusted administrative path, and evidence-preservation method are not supplied.
Status
Blocked - direction pending

A well-handled evidence gap

Element
Endpoint-telemetry branch
From or trigger
Endpoint protection last checked in eleven days ago.
To or outcome
Treat health as unknown; determine connectivity and approved evidence-collection path.
Evidence and source ID
F07
Owner
Endpoint/security owner
Open question
Current telemetry, agent state, isolation record, and forensic evidence are not supplied.
Status
Open - device state unknown

Flawed approach — do not copy

Marking this device-triage decision tree “approved and complete” without the required evidence or reviewer is a flawed submission. Stop same-device credential changes, destructive cleanup, rebuild, or return-to-service without qualified direction and preserved evidence.

Repair: Rework the device-triage decision tree as an evidence-backed draft, not an approved result. Start from the observed credential-entry event and the possibly affected laptop. Branch first on qualified incident-owner direction and evidence-preservation requirements. Replace same-laptop credential change with a trusted-path decision gate. Check the revision against this requirement: Trusted-path, evidence-preservation, connectivity, telemetry, isolation, analysis, recovery, and exception branches are explicit. If the required evidence is still absent, keep the decision blocked and identify the missing input or authorized reviewer.

Full case record, ambiguities and all assignments →

03 · Bounded practice

Build the device-triage decision tree.

Replace improvised password changes with an authorized device and software response path.

Deliverable: A device triage decision tree and approved-software baseline exception.

Complete a bounded starter and gap analysis using only CB01, F03, F06, F07, and the assignment-scope record below. Populate supported fields, label every unavailable field “not supplied,” and cite the input ID for each material statement. You may design a proposed template, control, question, or decision rule, but must label it as a learner proposal rather than observed case evidence. Do not contact people, access live systems, run tests, sign records, claim approval, or invent names, dates, quotations, transactions, results, or source documents.

Exact supplied inputs for this assignment
  • M04-I01 · F03 — An employee entered a cloud password after opening the attachment.
  • M04-I02 · F06 — The manager advised a password change from the same possibly affected laptop.
  • M04-I03 · F07 — Endpoint protection on the laptop last checked in eleven days ago.
  • M04-B01 · CB01 — Use CB01, the full versioned case brief printed once at the start of this packet, as a citable narrative source for details not normalized into F01–F12. Preserve its uncertainty language and do not treat narrative detail as approval, complete operational records, or professional judgment.
  • M04-S01 · F03, F06, F07 — Build a starter version of “A device triage decision tree and approved-software baseline exception.” from the listed case facts. Treat requested structures, controls, questions, calculations, and templates as learner-designed proposals. Where an operational record or result is absent, add a gap entry naming the missing evidence and authorized owner instead of fabricating it.

Operating procedure

  1. Start from the observed credential-entry event and the possibly affected laptop.
  2. Branch first on qualified incident-owner direction and evidence-preservation requirements.
  3. Replace same-laptop credential change with a trusted-path decision gate.
  4. Branch on endpoint connectivity/check-in and availability of current telemetry.
  5. Define proposed preserve, isolate, collect, analyze, rebuild, or return-to-service paths as authorized decisions, not completed actions.
  6. Add exceptions for business criticality, remote device, unavailable tooling, and safety.
  7. Final-QC source IDs, sequence, owner, evidence needed, exception path, and pending result.
Field-by-field guidance
Element
Name the process node, asset, state, or transition. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
From or trigger
State the observable event that activates the path. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
To or outcome
State the proposed next state without implying execution. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
Evidence and source ID
Pair the observation with its exact supplied source ID. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
Owner
Name the authorized operating or specialist role. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
Open question
Record the unanswered question that prevents a final decision. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
Status
Use a truthful state such as draft, open—not supplied, review pending, or blocked. Module use: Use the tree to coordinate safe device decisions without destroying evidence or treating stale endpoint data as a clean bill of health.
Device-triage decision tree · learning draft
ElementFrom or triggerTo or outcomeEvidence and source IDOwnerOpen questionStatus

Start with 6 rows; the complete workbook specifies 10 stable rows for this artifact. Add rows here or use the full download. No action is saved until you explicitly choose saving above.

Download complete six-module workbook (.md) · Structured case packet (.json)

Keep private client data, unpublished inventions, personal identifiers and credentials out of these public learning tools.

Module 4 · 2-item formative check

Devices, updates, and approved software

Choose an answer and request feedback. Read why each option does or does not fit the evidence. Answers stay in this tab unless you choose device-only saving; they are never submitted.

Question 1 of 2 · MODULE 4 · knowledgeAn employee requests an unapproved browser extension for a deadline. Which response is safest?
Question 2 of 2 · MODULE 4 · scenarioF03 confirms entered credentials, F06 confirms advice to change the password from the same possibly affected laptop, and F07 confirms endpoint protection last checked in eleven days ago. Which device-response finding is actionable?

Answer either question to review its reasoning.

Inspect the artifact, not just your quiz answers

  • Trusted-path, evidence-preservation, connectivity, telemetry, isolation, analysis, recovery, and exception branches are explicit.
  • The endpoint result remains unknown.
  • No device action or forensic conclusion is fabricated.

Stop: Stop same-device credential changes, destructive cleanup, rebuild, or return-to-service without qualified direction and preserved evidence.

Go: Proceed through the approved branch only when device identity, trusted tooling, owner, and evidence method are confirmed.

Escalate: Escalate unavailable telemetry, critical business dependencies, or suspected widespread compromise to incident leadership.

04 · Evidence to keep

Leave with usable work.

Submit the corrected baseline, prioritized remediation plan, exception record, owners, deadlines, and a safe update-and-rollback checklist.

Download your artifact CSV and, if wanted, export the learning-work JSON above. Neither export is a reviewed submission or certificate. Device-only saving is optional; you must press Save my work now after edits.

When all six artifacts are ready, compare the full packet against the track rubric. Qualified human review is still required before real-world decisions.

Computer user working at a secured workstation during a cybersecurity exercise.
Learn the standard. Practice the work.
Technology professional reviewing account and device security controls.
Leave with evidence you can inspect.

Sources, scope and review boundaries

Curriculum 2026.10.08-learning-paths-1. External source dates below are record checks, not continuing guarantees. Verify current requirements before consequential use.

cisa-cross-sector-cpgs · Official guidance

CISA Cross-Sector Cybersecurity Performance Goals

CISA's prioritized voluntary baseline practices, designed to help organizations focus on high-impact risk reduction.

Open reviewed external source ↗

ws-cybersecurity-operating-standard · Academy internal operating standard

Wealth Synergy cybersecurity internal operating standard

Academy-selected asset, access, verification, device, backup, incident, and restoration controls; it does not authorize security testing. This is an internal operating standard selected by Foundry Academy; it is not law, accreditation, licensure, or an external-standard requirement.

Version 1.0 · reviewed 2026-09-01 · owner: Foundry Academy curriculum owner

A future Wealth Synergy private professional-development certificate would be issued only after its assessment, capstone, identity, reviewer, retention, access, deletion, appeal, and issuance controls pass quality review. No credential is currently issued. Any future certificate would not be an accredited academic qualification, professional license, or government certification.