Embedded and IoT devices
Assess custom hardware, firmware, debug interfaces, wireless links, update mechanisms, provisioning, and physical access paths. Review secure boot, key handling, and the behavior of the product when assumptions fail.
Device security & penetration testing
Find the exposure.
Understand the impact.
Build the fix.
Security assessment for products and systems where software can change the physical world. Delivered through Green Shoe Lab, the security practice of Green Shoe Garage.
We connect hardware, firmware, communications, applications, and architecture findings to their practical consequences—and to work your team can do to improve the product.
01 / Hardware to cloud
Follow the actual attack surface.
An exposed debug port, an update mechanism, a mobile app, and a control network can be parts of the same problem. We review the boundaries between them.
Software and architecture
Combine source-code and architecture review with tests of web interfaces, companion applications, APIs, cloud connections, authentication, user authorization, and access control.
Industrial and building systems
Evaluate the controllers and networks behind connected equipment, including ICS, SCADA, BAS, and EMS environments. Consider operational consequences alongside network and application exposure.
Secure development
Bring threat modeling, trust-boundary review, secure embedded design, and update strategy into development. Turn findings into specific hardware, firmware, or application changes.
Explore the full Green Shoe Lab practice for IoT, industrial controls, and cyber-physical security.
02 / Assessment methods
Manual investigation. Targeted automation.
We select the methods around the system, the questions you need answered, and the authorized engagement scope.
Application and interface testing
- Vulnerability scanning
- Cross-site scripting checks
- SQL injection checks
- Remote code execution exposure
- SSL/TLS configuration review
- Authentication review
- User authorization
- Access control
- Web, API, and mobile penetration testing
Device and firmware investigation
- Hardware teardown and review
- JTAG, SWD, and UART exposure
- Firmware extraction and reverse engineering
- Source-code review
- Secure-boot review
- Key-management review
- Wireless and RF assessment
- Over-the-air update testing
System and operational review
- Threat modeling
- Architecture review
- Trust-boundary mapping
- Protocol and network analysis
- Segmentation review
- PLC, RTU, and HMI assessment
- Modbus/TCP
- DNP3
- BACnet
- PROFINET
Resilience and recovery
- Controlled DoS/DDoS emulation
- Availability and resource-exhaustion testing
- Fault behavior
- Recovery paths
- Update interruption and rollback review
Testing begins with agreed targets, versions, access, methods, and rules of engagement. Availability and denial-of-service work uses an approved environment and defined limits; operational systems require a plan that protects the physical process.
03 / Evidence to action
An assessment with a clear next step.
Scope, technical evidence, practical impact, and remediation stay connected throughout the engagement.
- 01
Define the engagement
What is in scope?
Identify the product, system boundaries, hardware revisions, firmware and software versions, interfaces, and environments.
Focus: Business concerns, threat assumptions, authorization, operational constraints, and rules of engagement.
What you receive: An agreed assessment scope and test plan.
- 02
Examine and test
What can be demonstrated?
Review the architecture and available design information, then apply the agreed manual and automated methods.
Focus: Observable behavior, configuration, reproducibility, and the relationship between findings.
What you receive: Technical evidence with the conditions and limits of each observation.
- 03
Prioritize and remediate
What should change first?
Connect weaknesses to practical impact on the device, users, data, and physical processes.
Focus: Risk prioritization, feasible fixes, hardening, and development or operational changes.
What you receive: A prioritized remediation plan and engineering recommendations.
- 04
Retest and hand over
Did the change address the finding?
Where included, retest the agreed fixes against the identified versions and conditions.
Focus: Verification of remediation and documentation of remaining exposure.
What you receive: An updated finding status and a clear record of any residual limitations.
04 / Requirements & evidence
Make the assessment useful to the wider review.
Some projects need technical evidence mapped to customer, sector, or regulatory requirements. That work is defined separately from the penetration test itself.
The scoping discussion can include HIPAA, HL7, FDA-related requirements, PCI DSS, GDPR, or FedRAMP references supplied for the project, along with the applicable product, environment, and review objectives. These references serve different purposes and are not interchangeable certifications.
We agree on the technical questions, evidence, and documentation GSG will provide and identify where a specialist assessor, laboratory, regulator, or other reviewer is needed. Security assessment does not by itself establish regulatory compliance, certification, or authorization.
Evidence that can be followed
Tie findings to versions, configurations, observations, and test conditions. Distinguish confirmed behavior from assumptions and questions that need further investigation.
Engineering follow-through
Use the findings to inform hardening, secure updates, component and dependency records, and practical changes to hardware, firmware, software, and operating procedures.
05 / Findings you can use
A repair plan for the attack surface.
Reporting detail, audiences, and retest arrangements are agreed at the start.
- Assessment record: scope, targets, versions, methods, assumptions, exclusions, and limitations.
- Findings: observed evidence, reproduction context appropriate to the engagement, and an explanation of practical impact.
- Priorities: recommended remediation order, mitigations, and engineering or operational next steps.
- Supporting work: threat models, hardening guidance, component or software-bill-of-materials records, and update strategy where included.
- Retesting: an agreed process for checking fixes and recording the remaining issues.
Bring the device or system description, version information, known concerns, available documentation, and the constraints on testing. Discuss an assessment.
Ready when you are
Bring the question.
Let’s build the next step.
An idea, a drawing, a stubborn problem, or a prototype that needs another set of eyes. Tell us where you are and what you need to learn.
Schedule a consultation