PHP Vulnerabilities: Why Cloud Management Systems Matter

Cloud Management Systems · ISO 9001 · ISO 14001 · ISO 13485

By Diana Lynn, President and Principal ISO Consultant, MSI · Updated October 22, 2026

PHP vulnerabilities are security flaws in the PHP language, its frameworks, or the code written with it that expose data or control to attackers. Your procedures can be flawless. The cloud platform that stores them, routes their approvals, and keeps your records may not be.

That gap is where the risk lives. Management systems have moved to the cloud. Document control, training records, CAPA logs, complaint files, internal audit reports, environmental aspect registers, and compliance calendars now sit on web platforms, and many cloud platforms and websites rely on PHP. According to W3Techs usage data, 69.3% of websites with a known server-side language run PHP as of October 22, 2026, and 34.7% of those sites still run PHP 7 or older.

For a quality or environmental manager, that means PHP vulnerabilities are no longer an IT topic you can leave to someone else. They reach the records that prove your system works. For medical device makers the stakes climb further, because the same web layer often surrounds the product itself: patient portals, clinic dashboards, remote monitoring back ends, and update servers. Under ISO 13485:2016, as under ISO 9001 and ISO 14001, that web layer is part of the management system.

The Definition

What Are PHP Vulnerabilities, and Why Should Management System Owners Care?

Define. Locate. Control.

PHP is a server-side scripting language. It runs on a web server, builds the pages a user sees, talks to the database behind them, and handles everything a user submits. When PHP code or the PHP runtime has a flaw, an attacker does not need to break into your building. They only need to reach the web application that holds your records.

PHP vulnerabilities fall into three broad groups. The first group sits in the PHP runtime itself, the engine that executes the code. The second sits in frameworks, plugins, and libraries pulled into an application. The third, and by far the largest, sits in the custom code a development team or contractor wrote. Each group creates a different control problem for a quality system.

Runtime flaws: the engine under the hood

Runtime PHP vulnerabilities are fixed by the PHP project and shipped as new releases. The catch is that fixes only flow to supported branches. The official PHP supported versions page shows that each branch gets two years of active support and two years of security-only fixes, then reaches end of life. As of October 22, 2026, PHP 8.2 receives security fixes only until December 31, 2026. PHP 8.1 and every earlier branch receive none.

A real example shows what this means. In June 2024, CISA added a PHP-CGI command injection flaw (CVE-2024-4577) to its Known Exploited Vulnerabilities Catalog, based on evidence of active exploitation. It affected certain PHP configurations on Windows servers. Supported branches received a fix. Unsupported branches did not.

Component flaws: the parts you bought

Most PHP applications are assembled, not written from scratch. Content management systems, form builders, reporting libraries, and authentication packages all arrive as components. The OWASP Top 10:2025 now lists Software Supply Chain Failures as the third most critical web application security risk, directly behind Broken Access Control and Security Misconfiguration. For a management system owner, component PHP vulnerabilities are a purchasing and supplier control question as much as a technical one.

Custom code flaws: the parts you built

The most common PHP vulnerabilities come from how code handles input and permissions. Injection, broken access control, unsafe file uploads, and weak session handling all start as ordinary coding decisions. In a cloud management system, those decisions decide whether your records can be trusted. In a medical device context, they also become design outputs. If they live in software that connects to a device or stores device data, they belong under design control.

The Exposure

Where Do PHP Vulnerabilities Touch Cloud Management Systems?

Map. Measure. Manage.

In MSI’s 28 years of ISO consulting, the surprise rarely lives where teams expect it. It lives in the systems nobody listed when the management system was scoped. Here are the six touchpoints where PHP vulnerabilities are worth checking first, starting with the one every certified organization has.

1. The management system platform: eQMS, records, complaints, and environmental data

This is the touchpoint most organizations miss. Complaint intake forms on a company website, document control systems, training trackers, CAPA databases, internal audit tools, environmental aspect registers, and compliance calendars are frequently built on PHP or on PHP platforms such as WordPress. PHP vulnerabilities here rarely hurt anyone directly. They can delete a complaint, alter an approved procedure, expose personal information, or quietly corrupt the evidence your next audit depends on.

ISO 9001:2026 Clause 7.5.3.1 and ISO 14001:2026 Clause 7.5.3 both require documented information to be adequately protected, for example from loss of confidentiality, improper use, or loss of integrity. An unsupported PHP version does not mean your records have already been compromised. It means you have a technology risk to that requirement, one that should be evaluated and controlled, whichever standard you are certified to.

For medical device makers: five more touchpoints around the device

Device makers carry the same platform risk plus a second layer. PHP rarely runs inside device firmware, which is usually written in C or C++. It does run in the web systems that surround the product.

2. Cloud patient and clinic portals

Connected devices often send readings to a cloud portal where clinicians review trends and patients see their own data. These portals hold exactly what ISO 13485 Clause 4.2.5 calls confidential health information.

A real advisory shows the stakes. In September 2024, CISA published ICS Medical Advisory ICSMA-24-249-01 for a connected health portal that stored patient, clinician, and clinic information. It described a SQL injection flaw scored 10.0 on CVSS v3.1 and an access control flaw scored 8.2.

The advisory does not name the web language used. The flaw classes are the same ones PHP developers work against every day, and the vendor reported patching them with no known exploitation.

3. Device configuration dashboards

Many systems let authorized users change thresholds, alarm limits, schedules, or user roles through a browser. If access control fails, the wrong person can change the right setting. That moves PHP vulnerabilities out of the data privacy column and into the patient safety column, which is exactly where ISO 14971:2019 risk management expects you to look. ISO 14971:2019 recognizes that hazards can arise from data and systems security, not only from physical failure.

4. Embedded web consoles on devices and gateways

Lab analyzers, imaging workstations, network gateways, and hub devices running embedded Linux often carry a small built-in web server for setup and service. Some use PHP. These consoles are easy to forget because nobody browses to them during normal use. If the PHP version inside is frozen at release, the device carries PHP vulnerabilities for its entire service life unless the design team plans an update path.

5. Remote patient monitoring back ends

Remote monitoring links home devices, mobile apps, and clinical reviewers through application programming interfaces, and many of those APIs are written in PHP. MSI’s article on remote patient monitoring compliance covers the wider quality picture. The web layer is where PHP vulnerabilities in a weak API can leak readings, accept forged data, or go offline when clinicians need it.

6. Software update and download servers

Firmware updates, labeling, instructions for use, and service software are often distributed through a web portal. PHP vulnerabilities in a download page can let an attacker serve altered files. Code signing on the device side is the primary control, but the portal still needs protection, because it is part of how labeling and updates reach users.

MSI’s sibling article on medical device cybersecurity explains how FDA moved device security into the quality system. This article widens the lens to the cloud platforms every management system now depends on, where PHP vulnerabilities do most of their damage.

The Conversation

What Should Quality and Environmental Managers Ask IT About PHP Vulnerabilities and the Cloud?

Ask. Listen. Record.

Moving the management system to the cloud is convenient, and when those platforms run on PHP, PHP vulnerabilities travel with them. It also means the quality manager and the environmental manager now depend on systems they cannot see.

You do not need to speak the language of IT to manage this. You only need to ask clear questions and write down the answers. Both standards already expect it.

ISO 9001:2026 Clause 7.5.3.1 and ISO 14001:2026 Clause 7.5.3 each require documented information to be adequately protected, for example from loss of confidentiality, improper use, or loss of integrity. ISO 9001:2026 Clause 7.1.3 requires the organization to determine, provide, and maintain the infrastructure its processes need, and its NOTE lists information and communication technology as an example. A cloud-hosted system is part of that picture.

Here are 12 plain questions to bring to your next conversation with IT. Each one comes with the reason you are asking and what a good answer sounds like.

Where does it live?

How is it kept current?

Who can touch it?

How do we recover?

What to do with the answers

Write the answers down and keep them as a record of how PHP vulnerabilities and other cloud risks are controlled. File the provider’s answers in the supplier file, because a cloud provider is an external provider. ISO 9001:2026 Clause 8.4 covers control of externally provided processes, products and services. ISO 14001:2026 Clause 8.1 requires externally provided processes relevant to the environmental management system to be controlled or influenced. ISO 13485 covers the same ground through purchasing in Clause 7.4 and software validation in Clause 4.1.6.

Any question IT cannot answer is not a failure. It is the next action. Open it as a preventive action, give it an owner and a date, and bring the open items to management review. MSI client experience suggests that this one conversation closes more hidden gaps in a cloud-based management system than any single software purchase.

Environmental managers updating their system to ISO 14001:2026 can fold these questions straight into the documented information and operational control work the transition already requires. MSI’s ISO 14001:2026 Procedure Templates & Guides were built to help experienced EHS managers update their ISO 14001:2015 system to 2026 in a week’s time.

The Consequences

How Could PHP Vulnerabilities Affect Records, Patients, and Recalls?

Expose. Alter. Interrupt.

Security teams describe impact as confidentiality, integrity, and availability. Quality teams describe it as patient harm, record integrity, and continuity of supply. The two vocabularies describe the same events. Translating between them is where ISO consulting earns its keep.

Confidentiality: patient data leaves the building

PHP vulnerabilities such as injection or access control flaws in a portal can expose patient identities, readings, and clinician notes. Clause 4.2.5 of ISO 13485 requires the organization to define and implement methods for protecting confidential health information contained in records, in accordance with applicable regulatory requirements. A portal breach is not only a privacy event. It is evidence that a records control did not work.

Integrity: settings and records change without anyone noticing

Integrity failures caused by PHP vulnerabilities are the most dangerous category for device makers. A changed alarm threshold, a forged reading, or an altered device history record can lead to wrong clinical decisions or a wrong release decision. Integrity failures are also the hardest to detect, because the system keeps running and the data looks normal. That is why audit trails and change logs in PHP applications should be treated as quality records, not as optional developer tooling.

Availability: the dashboard goes dark

Ransomware groups routinely target unpatched web servers and known PHP vulnerabilities. When a monitoring dashboard or service portal goes offline, clinicians lose visibility and field service teams lose access to configuration data. ISO 13485 Clause 6.3 requires the organization to document requirements for infrastructure, including supporting services such as information systems, and to maintain it. A web server running an unsupported PHP branch is an infrastructure maintenance gap.

The downstream cost: complaints, reports, and recalls

Each of these failures can surface as a complaint under Clause 8.2.2, trigger an assessment for reporting to regulatory authorities under Clause 8.2.3, and, in serious cases, lead to field action. MSI’s guide to product recall prevention shows how early signals get missed. MSI client experience suggests that PHP vulnerabilities and other web-layer issues are often logged as IT incidents and never reach the complaint file, which is precisely the break in the chain that prevents a system from learning.

“Having systems, acting on what the records are reporting, and never letting anyone deny the facts is what prevents good systems from deteriorating.”
— Diana Lynn, President and Principal ISO Consultant, MSI

The Clause Map

Which ISO 13485 Clauses Govern PHP Vulnerabilities?

Clause. Control. Record.

ISO 13485 never mentions PHP, and it does not need to. The standard is written around outcomes and controls, which means it already covers PHP vulnerabilities in the web layer once you recognize where that layer sits. One accuracy note matters here. ISO 13485 predates the harmonized structure used by ISO 9001, so its clause numbers and its corrective and preventive action structure differ from ISO 9001. The references below use ISO 13485:2016 numbering.

Clause 4.1.6: validating software used in the quality system

Clause 4.1.6 requires documented procedures for validating the application of computer software used in the quality management system, before initial use and after changes, with an approach proportionate to the risk of using the software. A PHP-based complaint portal, eQMS, or training tracker falls squarely here. When its PHP runtime is upgraded, that is a change that triggers revalidation thinking. MSI’s article on ISO compliance automation discusses how to keep validation proportionate rather than paralyzing.

Clauses 4.2.4 and 4.2.5: documents and records

Document and record controls apply to electronic records regardless of the platform. Clause 4.2.5 adds the specific duty to protect confidential health information. MSI’s document and records control procedure guide explains how to build that control into daily work.

Clause 7.3: design and development

For device-connected web applications, security requirements are design inputs under Clause 7.3.3, secure code is a design output under Clause 7.3.4, and a patch is a design change under Clause 7.3.9, with review, verification, and validation as appropriate. MSI covers the full flow in its ISO 13485 design and development guide, and the companion article on medical device threat modeling shows how threat analysis feeds those design inputs.

Clause 7.4: purchasing and supplier control

PHP itself, frameworks, plugins, hosting providers, and outsourced developers are all purchased products or externally provided services. Clause 7.4.1 requires criteria for supplier evaluation and selection proportionate to the risk associated with the product. MSI’s purchasing and supplier control procedure article walks through how to apply that to software suppliers.

Clauses 7.5.6 and 7.6: software used in production and measurement

If a PHP application drives production records, labeling, or test data, Clause 7.5.6 requires documented procedures for validating the application of that software. Clause 7.6 carries a similar requirement for software used to monitor and measure. MSI’s article on control of monitoring and measuring equipment covers the measurement side in depth.

Clauses 8.5.2 and 8.5.3: corrective and preventive action

Discovered PHP vulnerabilities in your own system are nonconformity candidates. Published PHP vulnerabilities that have not yet affected you are preventive action candidates. MSI’s guide to how CAPA works under ISO 13485 explains why the two are kept separate in this standard.

Required versus recommended: what the standard actually demands

The table below separates what ISO 13485 and U.S. law require from what MSI recommends. Keeping that line clear protects your team from over-building and from under-building.

The Regulators

What Do FDA and International Regulators Expect About Web-Layer Risk?

Plan. Disclose. Patch.

Regulators do not single out PHP vulnerabilities by name. They do expect a device maker to know which software components it ships, to monitor them, and to fix them. That expectation reaches the web layer whenever the web layer is part of the device system.

FDA’s February 2026 cybersecurity guidance

On February 3, 2026, FDA issued the final guidance Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. It supersedes the June 27, 2025 version, and its new title signals the shift toward the quality management system. The guidance also covers FDA’s recommendations for Section 524B cyber devices. FDA maintains a helpful cybersecurity FAQ page for scoping questions.

Section 524B and the software bill of materials

Section 524B of the Federal Food, Drug, and Cosmetic Act, summarized in FDA’s Section 524B reference document, applies to cyber devices: devices that include software, can connect to the internet, and could be vulnerable to cybersecurity threats. Sponsors must provide a plan to monitor, identify, and address postmarket vulnerabilities, maintain processes that provide reasonable assurance of cybersecurity, and supply a software bill of materials covering commercial, open-source, and off-the-shelf components. If PHP or a PHP framework is part of the device system, it belongs in that bill of materials.

The QMSR and ISO 13485

FDA’s Quality Management System Regulation took effect on February 2, 2026, incorporating ISO 13485:2016 by reference into 21 CFR Part 820, as published in the Federal Register final rule. MSI’s overview of the QMSR and ISO 13485 alignment explains the background. The practical result is simple: ISO 13485 controls for software validation, records, and purchasing now carry regulatory weight in the United States as well as certification weight.

International and lifecycle standards

Outside the United States, the International Medical Device Regulators Forum published IMDRF N60, Principles and Practices for Medical Device Cybersecurity, which emphasizes shared responsibility across the product lifecycle.

Two lifecycle standards frame the software work. IEC 62304 covers medical device software lifecycle processes, including software of unknown provenance, a category PHP and its libraries often fall into. IEC 81001-5-1 covers security activities across the health software lifecycle. For threat analysis methods, the MDIC and MITRE Playbook for Threat Modeling Medical Devices is a practical reference.

Healthcare delivery organizations, your customers, often follow the HHS 405(d) Health Industry Cybersecurity Practices, so expect their procurement teams to ask about your web stack.

As of October 22, 2026, ISO 13485:2016 remains the current edition and has been reconfirmed, so the clause references in this article stay stable for planning purposes.

The Original Asset

The PHP Exposure-to-Record Map: Score Your Web Layer in 30 Minutes

Score. Decide. Act.

This map is new with this article. It connects each touchpoint to the ISO 13485 clause that governs it and to the record an auditor, a customer, or your own team would ask to see. Score each row honestly, then add the column.

Scoring rules: 0 = no record exists. 1 = a record exists but is older than 12 months or does not reflect the current PHP version. 2 = a current record exists and has been reviewed within the last 12 months.

Decision rules: 10–12 points means maintain the current controls and re-score each year. 6–9 points means open preventive actions for every row scoring 0 and schedule a planning session. 0–5 points means bring the map to your next management review as a priority input, because the system cannot yet show control of its web layer.

MSI client experience suggests that the eQMS and complaint form row scores lowest most often. Teams validate the quality software once at purchase and never again, even after several PHP upgrades by the hosting provider.

The Method

How Should a Quality System Respond to PHP Vulnerabilities?

Inventory. Assess. Correct.

The method below works for a five-person startup and a multi-site manufacturer. The difference is scale, not structure. MSI has applied this pattern of inventory, risk, change, verification, and review across 80+ certifications supported, and it holds up because it uses controls the quality system already has.

Step 1: Build the inventory

List every system that runs PHP and could carry PHP vulnerabilities, who owns it, which PHP version it runs, and what data or device function it touches. Include the company website if it hosts a complaint form. Include contractor-hosted portals. Many teams discover that their marketing website is the front door for complaint intake, which makes it part of Clause 8.2.2.

Step 2: Assess risk with the tools you already own

Feed each item into the existing risk management process rather than starting a separate security spreadsheet. MSI’s article on ISO 13485 risk management explains how to keep one risk file. Ask two questions for each system: what happens to a patient if this data is wrong, and what happens to a release decision if this record is wrong.

The headline rule: a significant technology alert triggers an immediate impact assessment

Some risks do not wait for the next scheduled review. When a PHP flaw reaches CISA’s Known Exploited Vulnerabilities Catalog, appears in a medical device advisory, or makes industry headlines, attackers already know about it. Diana Lynn’s position is direct: headline technology alerts should cause immediate consideration of product safety issues. The alert itself is the trigger, not the next patch cycle or the next management review.

Not every bug report or routine list of PHP vulnerabilities qualifies. The rule applies to significant technology security alerts: an actively exploited flaw, a government advisory, or a widely reported incident in a technology you might use. Whether you are affected is the question the review answers, not the condition for starting it.

The rule is not limited to PHP vulnerabilities. It covers any technology your devices or quality system depend on: an operating system flaw, a compromised open-source library, a cloud provider outage, a widely reported ransomware campaign, or a warning about artificial intelligence. AI shows why the rule must reach that far. Diana views AI’s current trajectory as one of the most serious technology threats of our time, and AI-related warnings now arrive faster than standards and regulations can respond. MSI’s article on AI risk management and emerging threats explores that wider picture.

Write the headline rule into your risk management or CAPA procedure so it runs the same way every time. Name who watches the alert sources, define the time allowed to open a documented impact assessment, and record the outcome even when the answer is “not affected.”

MSI recommends opening that assessment within one business day of the alert. The record answers three questions: Do any of our products, systems, or suppliers use the affected technology, version, or component? Could the flaw change device behavior, clinical data, or quality records? Does this meet the threshold for complaint handling under Clause 8.2.2 or reporting under Clause 8.2.3? A documented “not affected” decision is as valuable as a fix, because it proves the system looked.

Step 3: Route fixes through change control

A PHP upgrade on a device-connected system is a design change. Document it, review its impact, verify it, and validate where needed. For quality system software, revalidate proportionate to risk under Clause 4.1.6. MSI’s guide to regulatory change management covers the governance side.

Step 4: Verify that the fix worked

Verification means evidence, not a ticket marked closed. Rescan, retest the affected functions, and confirm that records written before and after the change remain intact. Keep the evidence where an internal auditor can find it.

Step 5: Close the loop through CAPA and review

Log significant PHP vulnerabilities as corrective or preventive actions, trend them, and report them upward. This is where a working system separates from a paper one. MSI has seen this pattern first-hand in 200+ audits attended: the procedures look complete, but the web systems never appear in the records that leadership reads.

Five measures that prove control

Authority comes from measurement. These five indicators give leadership and auditors a clear, numeric view of how well PHP vulnerabilities are controlled.

The Suppliers

Why Are PHP Vulnerabilities a Supplier Control Problem?

Select. Verify. Monitor.

Few medical device companies write their own web platforms from scratch. They buy hosting, hire agencies, license eQMS platforms, and install plugins. Each of those choices hands part of the web layer, and part of the responsibility for PHP vulnerabilities, to an external provider. That makes PHP vulnerabilities a supplier control topic under Clause 7.4.

Start with three questions for every web supplier. Which PHP version do you run for us today? How fast do you apply security releases, and how will you tell us? What happens to our data and records if you stop supporting this platform?

Write the answers into the supplier file. A supplier who cannot answer the first question has told you something important about their controls.

Hosting providers deserve particular attention. Many upgrade PHP on shared servers on their own schedule, which can quietly invalidate the validation of a quality system application. A supplier agreement that requires advance notice of runtime changes turns a surprise into a planned change.

The same logic applies to contract developers. If a contractor builds a device-connected portal, the code they write is your design output. Require secure coding practices, code review evidence, and a component list as deliverables. Those become records in your design history file, not just files in the contractor’s repository.

MSI’s article on connected quality management explores how quality data flows across these supplier boundaries, and the article on AI as an externally provided process applies the same supplier logic to another fast-moving technology.

The Leadership View

How Should Management Review Handle PHP Vulnerabilities?

Report. Decide. Resource.

Clause 5.6.2 of ISO 13485 lists the inputs management review must include, such as feedback, complaint handling, reporting to regulatory authorities, audits, process monitoring, corrective and preventive action, changes that could affect the quality system, and applicable new or revised regulatory requirements. Evidence about PHP vulnerabilities fits naturally inside several of those inputs. The FDA guidance update of February 2026 is a new regulatory requirement input. An open PHP-related CAPA is a CAPA input. A missing complaint caused by a broken form is a complaint handling input.

The output side matters just as much. Clause 5.6.3 expects recorded decisions and actions, including resource needs. An upcoming end-of-life date, such as PHP 8.2 on December 31, 2026, is exactly the kind of resource decision leadership should own rather than discover after the fact. MSI’s ISO 13485 management review guide and the article connecting audit findings to management review show how to present this evidence so leadership can act on it.

For teams that want a ready structure, MSI’s free 5 Steps to a Decision-Ready ISO Management Review guide is a fast starting point.

The Audit Lens

What Will an Internal Auditor Look for Around PHP-Based Systems?

Sample. Trace. Confirm.

Internal audits are where web-layer controls either show up or quietly fall apart. A capable internal auditor does not need to be a software developer. They need to follow the records. Registrars across the industry expect every requirement of the standard to be internally audited each year, and PHP vulnerabilities touch enough clauses that the web layer should appear in the audit program.

Here is what a well-trained auditor samples. They pick one PHP-based quality application and ask for its validation record, then compare the validated version with the version running today.

They pick one recent PHP security release and trace whether anyone assessed it. They pull a complaint submitted through the website and confirm it reached the complaint file intact. They open a supplier file for the hosting provider and look for evidence of evaluation. Each sample takes minutes and tells the auditor whether the procedure works in practice.

MSI’s internal audit services page explains how MSI performs these audits for clients, and the article on internal audit planning shows how to build web systems into an annual schedule. Teams that want to build this skill in-house can train with MSI’s ISO 13485 Internal Auditing course, part of a training catalog that has reached 600+ professionals trained.

The Starting Point

Where Should Your Team Start This Week?

Start. Small. Now.

You do not need a new department to get control of PHP vulnerabilities. You need one afternoon and the people who already own the systems. Gather your quality lead, your IT or web lead, and whoever manages your device software. Score the PHP Exposure-to-Record Map together. Write down every PHP version you find, and compare each one to the php.net supported versions table.

Then take three actions. First, add every PHP system to the risk file and the supplier file. Second, open a preventive action for any system running PHP 8.2 or older, because the clock runs out on December 31, 2026. Third, put the map on the agenda of your next management review.

If your quality system was built before connected products became part of your portfolio, an outside view helps. MSI’s ISO 13485 consulting team can review the web layer as part of a broader system check, and our ISO 13485 gap analysis page explains what that review covers. For companies earlier in the journey, SurePath provides a structured route to certification, and SureResults keeps controls current year after year. You can also explore MSI’s full range of ISO consulting services.

Frequently Asked Questions

PHP Vulnerabilities and Cloud Management Systems: Frequently Asked Questions

Ask. Answer. Apply.

Do PHP vulnerabilities affect cloud-based quality and environmental management systems?

Can PHP vulnerabilities directly harm a patient?

Does ISO 13485 require cybersecurity controls for PHP applications?

When does PHP 8.2 reach end of life?

Should PHP be listed in a software bill of materials?

What should happen when a technology vulnerability makes the headlines?

Is a PHP upgrade a design change under ISO 13485?

How does ISO consulting help with PHP vulnerabilities?

Keep Reading

Related Reading from MSI

Learn. Link. Lead.