homechevron_rightDocschevron_rightDatasheetschevron_rightApplication Noteschevron_rightBlues Security, Reliability, and Governance

Blues Security, Reliability, and Governance

This guide provides a comprehensive overview of Blues' security and resiliency programs, covering hardware-level security, cloud infrastructure protection, and operational policies that ensure secure and reliable device-to-cloud connectivity.

Table of Contents

Introduction

Blues offers a simple, scalable, and secure device-to-cloud system for transforming your products into intelligent, connected services. It consists of hardware (Notecard) that you embed within your own product, and which securely communicates with our cloud service (Notehub). Notehub routes your data to your own application services. Notehub provides secure configuration and access control, enables secure “over-the-air” firmware updates, and offers real-time fleet management and monitoring. Cellular, satellite, and WiFi Notecards are pre-provisioned with a unique hardware TLS certificate at point of manufacture, which provides authentication and transport encryption. Notecard for LoRa does not contain a secure element and does not open its own connection to Notehub; it relies instead on the LoRaWAN standard’s device identity and session security, reaching Notehub through a LoRaWAN Network Server (LNS). By default, cellular traffic doesn’t traverse the internet. If configured to do so, the Notecard’s transport can be extended to include satellite connectivity, which also uses authenticated encryption.

Security of our customer’s data while transiting Blues' device-to-cloud system is our top priority. In contrast to many IoT services, Blues' hardware, systems and services are “secure by default”. We take a multi-layered approach that ensures security of your data from the Notecard through Notehub and onto your own cloud application. Our cybersecurity program has been developed to comply with industry best practices and audit standards such as SOC2 and ISO 27001.

Blues is committed to the highest level of connectivity and availability. Our resiliency program ensures around-the-clock availability of our services and rapid response and mitigation of any issues that do arise. It is ensured through a no-single-point-of-failure architecture, auto-scaling, thousands of automated tests, and highly-responsive 24x7 operations.

To report a security vulnerability in a Blues product, email security@blues.com; see Reporting a Vulnerability below for our Coordinated Vulnerability Disclosure Policy and published advisories.

This document describes our cybersecurity and resiliency programs. We intend its audience to be technical customers and prospects who want to understand how Blues helps you deliver secure and reliable services to your own customers. Some experience with Notecard and Notehub may be helpful but is not required.

Notecard and Starnote Security

Customers connect their product to a Notecard or Notecard+Starnote via a direct hardware connection, most typically I2C. Before a cellular, satellite, or WiFi Notecard may connect to our Notehub service, it is validated through a unique cryptographic key and certificate held in a tamper-resistant secure element embedded in that Notecard. A secure element is present on the cellular, WiFi, and Starnote lines only. Similarly, those Notecards validate that they are connected to the authentic Blues Notehub using A+ rated TLS server certificates. Notecard for LoRa follows a different model: it contains no secure element and does not establish its own session with Notehub. It is identified and authenticated by the LoRaWAN network using credentials installed at manufacture, and a LoRaWAN Network Server (LNS) relays its data to Notehub over a secure connection, as described under Notecard for LoRa Identity and Session Security below.

Notecards typically connect to Notehub via private networks, and not the public internet. Once a Notecard is connected, we encrypt all configuration settings during transfers. Even though private networks are used, you may elect to encrypt all data transfers at the cost of slightly higher data usage.

We design, implement, test, and support Notecard and Starnote firmware and hardware with security at the forefront. As described in the sections below, this includes secure design, repeatable and automated manufacturing, required security reviews for all changes, and automated testing of all hardware and firmware before release.

Blues Notecard’s cloud-based firmware updates originate from your private project, are encrypted in transit, and are verified both for integrity and to ensure that they contain the firmware you intended to update. You may use the same firmware update process to securely install or update firmware on your own “host” microcontroller.

All Notecard hardware is certified by 3rd party certification agents recognized by the relevant authorities. A complete list of certifications can be found in Certifications by Device.

Details

  • Connecting your Product’s Hardware: Typically, you will connect your product’s MCU either directly to the Notecard or through a data bus. Notecards support multiple hardware protocols but the most typically used is I2C. A standard Notecard exposes this connectivity via its M.2 connector, though we also offer a Notestamp version which you can directly solder to your own board. Starnotes connect to a Notecard and enhance it to provide satellite connectivity.

  • Secure Element (cellular, satellite, and WiFi Notecards): Each cellular, satellite, and WiFi Notecard, and each Starnote, uses a distinct STSAFE™ secure element to authenticate against Notehub. These secure elements from STMicroelectronics identify the specific Notecard using a unique cryptographic key pair and prevent spoofing from a non-Blues device or threat actor. Compliant with the most demanding security certifications, STSAFE secure elements are developed through a trusted supply chain with pre-provisioned secrets and certificates. The STSAFE element embedded on a Notecard is unique to Blues and only ST Microelectronics, in its enterprise Hardware Security Module (HSM), holds the root keys necessary to generate compliant ECC P-384 certificates used by TLS for device authentication. STMicroelectronics’s manufacturing facilities are in a politically aligned region (France) and manage their enterprise HSM in a manner that is well-regarded by its myriad government customers worldwide. To be clear, neither Blues nor any organization other than ST Microelectronics has the technical capacity to program these chips with authorized certificates. Notecard for LoRa does not include a secure element; see the following bullet for its identity model.

  • Notecard for LoRa Identity and Session Security: Notecard for LoRa contains no secure element and does not open a TLS session to Notehub of its own. Each unit carries a unique, factory-assigned DevEUI and the standard LoRaWAN join credentials (DevEUI, AppEUI/JoinEUI, and AppKey) installed at manufacture, and it authenticates to the LoRaWAN network rather than directly to Notehub. Its protection therefore comes from LoRaWAN session security — session keys derived at join time, with AES-128 encryption and a message integrity check on every uplink and downlink — combined with the secure connection between the LoRaWAN Network Server (LNS) and Notehub. Because the LNS is a trusted participant in this path rather than a pass-through, customers deploying Notecard for LoRa should evaluate the security posture of the gateway and LNS they use. You may point a Notecard for LoRa at your own LoRaWAN server by supplying your own credentials through the details argument to hub.set.

  • Private/Encrypted Communication Channels: Notecards use private or otherwise secure communication channels.

    • When configured (as it is by default) to use the bundled cellular SIM, Notecards communicate with Notehub via our cellular providers' private network and traverse a private network directly to our servers. Cellular traffic does not transit the public internet. Across all lines, every IP socket connection is initiated by the Notecard and no inbound connections are accepted, so Notecards are not exposed to internet scanning or unsolicited connection attempts. The modem has no direct path to the customer's product, which limits supply-chain attacks.
    • Starnotes and satellite-integrated Notecards use private communication channels, with packets encrypted by ChaCha20-Poly1305 authenticated encryption.
    • The Notecard for LoRa uses LoRaWAN-standard encryption on all connections, and reaches Notehub through a LoRaWAN Network Server rather than by connecting to Notehub directly.
    • If your Notecard connects via WiFi or you use a SIM other than Blues' embedded one, traffic will traverse the public internet but with full TLS encryption. The leg between a LoRaWAN Network Server and Notehub likewise crosses the public internet.
    • These controls govern who may open a connection to a Notecard; they do not validate the content of a response to a request the Notecard itself initiated. If a customer's own cloud service, or the Notehub project routing to it, were compromised, malicious content could be returned inside an otherwise legitimate response. Treat inbound Notes and environment variables as untrusted input and validate them in your host firmware before acting on them.

  • Additional Transport Encryption: In addition to the private or encrypted communication channels, you may further encrypt Notecard data end-to-end between the Notecard and your servers by using specially-configured .qos (uplink) or .qis (downlink) files. Notecard configuration information (i.e., _env.dbs file) is always encrypted no matter the communication channel. All of this traffic is encrypted with AES-256 encryption and is authenticated either with RSA or ECC P-384. This applies to cellular, satellite, and WiFi Notecards. Notecard for LoRa does not establish a TLS session of its own, so the “s”-suffixed Notefile mechanism does not apply to it; its traffic is protected by LoRaWAN session encryption as described above.

  • Payload Encryption: In addition to the communication channel and transport encryption listed above, if you prefer to encrypt the data sent to the Notecard and transport it encrypted through Notehub and to your cloud service, the Notecard can both encrypt outbound Notes added by your host and decrypt inbound Notes encrypted by your cloud application using an AES-256 symmetric algorithm based on a public key you specify, as detailed in Encrypting and Decrypting Data with the Notecard. Encrypting and decrypting Notefiles in this way is not supported on Notecard for LoRa.

  • OTA Firmware Updates: Over-the-air Notecard firmware updates are keyed to the specific Notecard SKU and operate over the same secured communication channel as other Notecard data. Likewise, this same mechanism secures over-the-air firmware updates to your host MCU. For developers that prefer manual firmware updates via a physical connection, we use secure hashes to ensure file integrity.

  • No Direct Modem Access: The Notecard’s internal MCU mediates all communication to and from the cellular or satellite modems, thus creating a “virtual air gap” between the network and your host MCU. The modem is not addressable from your product, and it is the Notecard’s MCU — not the modem — that enforces the outbound-only connection behavior described under Private/Encrypted Communication Channels above.

  • Notecard Certification: Cellular and satellite Notecard and Starnote hardware is certified by our connectivity providers. These certifications require and test against security, reliability, and RF compliance standards. A complete list of certifications can be found at Certifications by Device.

  • Notecard Data Caching: The Notecard caches all data and events. Thus, even if a Notecard encounters temporary connectivity gaps, no data will be lost. All events will be transmitted the next time the Notecard syncs with Notehub.

  • Manufacturing: To ensure consistently reliable Notecard hardware, our manufacturing partners conform to ISO9000 standards. On cellular, satellite, and WiFi Notecards, security is ensured by our use of the STSAFE secure element and its HSM manufacturing process. Notecard for LoRa’s LoRaWAN credentials are likewise installed during manufacturing.

  • Firmware Support Lifetime: While customers can update their Notecard firmware at any time, every Long-Term Support (LTS) release carries 10 years of free security updates from its release date, uniform across the firmware lines and available to every SKU. No support contract, subscription, paid tier, or Enterprise Agreement is required. Other bug fixes are made on a best-effort basis. See Firmware Release Policies for the full policy.

Notehub Security

Notehub processes data to and from Notecards and serves as your hub for all aspects of fleet management. Notehub implements comprehensive defense-in-depth customer data security throughout the stack from hardware through backend software to UI and API protections.

You have complete control and flexibility over which Notecards may connect to your Notehub project. You may implement this wherever it best fits your business, including during manufacturing, distribution, deployment or customer onboarding. From there, you control the secure, reliable routing of data from Notehub to your own cloud services.

Notehub uses industry best practices such as Virtual Private Clouds to avoid and mitigate public internet threats such as SQL injection, man-in-the-middle attacks, and denial-of-service (DoS) attacks. All connections to the Notehub UI and API are protected using an A+-rated TLS/HTTPS connection. We use Blues-specific IP ranges so that your network engineers can further limit access to and from Notehub.

Notehub offers rich, role-based access control for both individual projects and organization-wide billing accounts. Your project’s data is held in its own database separate from other customers significantly reducing the risk of data exposure. Full auditing allows you to track changes to project configurations, user access, and billing.

Details

  • UI and API Encryption: All communication with the Notehub UI and API are encrypted using TLS 1.2/1.3 (HTTPS) encryption with 2048-bit RSA keys. Our implementation receives an A+ rating from independent auditor Qualys. Notecards can validate that they are truly communicating with the Blues Notehub using these server certificates.

  • No Stored Passwords: Notecards do not require passwords to access Notehub, and there is no need for an administrator to generate and distribute keys to devices. Cellular, satellite, and WiFi Notecards achieve this with embedded Hardware Security Module-based keys and certificates; Notecard for LoRa does so with the LoRaWAN credentials installed at manufacture, which the LoRaWAN network validates on its behalf. In either case, connections between the Notecard and Notehub are secure from the very first session.

  • Unique Product UIDs: Notecards refer to a Notehub project using unique ProductUIDs. Production product UIDs prefixes normally begin with your company’s reversed domain, and must be approved by Blues following a defined policy and process that ensures your rights to the prefix.

  • Controlling Notecard Access: The Product UID is configured in the Notecard either during your manufacturing process or using your product’s own firmware. You have multiple options to ensure that only the Notecards you control connect to your Notehub project:

  • Pre-provisioning. Using the Notehub API, you can pre-provision each Notecard into a specific fleet within your Notehub project. This completely eliminates the need for manual configuration. By doing so, you can disallow other Notecards from connecting to your project even if it spoofs the Product UID.

  • Auto-provisioning. Another alternative is to let devices auto-provision into a feature-limited fleet within your project. From there, your fleet manager can review it and move it, when appropriate, to another fleet via the Notehub UI or API.

  • QR-based onboarding. A unique, anti-spoofing QR-code sticker is included with each Notecard. We give you the ability to customize its link. By attaching this sticker to your product, your customer can scan it to go through your own custom provisioning process.

  • Outgoing Encryption: You control the encryption of data sent from Notehub to your own cloud services. Connections that Notehub initiates on your behalf, such as event routing, web.post and other device proxy requests, are either fully TLS encrypted (e.g., Twilio routes) or allow you to configure encryption as you wish (e.g., via HTTPS or MQTT with TLS enabled).

  • Whitelisting IPs: All internet traffic to and from Notehub uses Blues' own defined IP range. This enables your network engineers to limit Notehub connections to just those IPs. Doing this provides another layer of protection to ensure that network traffic is only originating from or going to Blues' Notehub servers.

  • Firewall and DoS Protection: Notehub avoids most DoS attacks since data from cellular Notecards travels over our connectivity provider's private network and not the public internet. It is further protected by a highly scalable load balancer which includes DoS mitigation. The load balancer distributes requests across our application servers while protecting them from direct access. Our system stack includes additional firewall-protection techniques that prevent other attacks.

  • Authentication: We authenticate user accounts via a well-respected third-party authentication system that meets SOC2 and ISO27001 standards. User passwords are stored as one-way hashes (SHA-256) which cannot be reversed and can only be used for validation. Our Enterprise customers may work with Blues to establish single sign-on with their corporate identity system using the OAuth protocol. This requires lead time and additional fees.

  • Access Control and Data Privacy: You have complete control over who accesses your project and its data via a robust authorization system using role-based access control. Similarly, organization account managers control billing settings and who is allowed to create projects using their billing accounts. Blues' support staff are unable to access customer projects without your explicit authorization. To preserve privacy, this support authorization is temporary and automatically terminates after 7 days (or a period you select).

  • API Access Control: API access requires authentication via Personal Access Tokens. Personal Access Tokens are time-limited cryptographic keys, generated by Blues at your request, and may be revoked at any time. API access is granted to a project or billing account in the same way as regular user access. Like user passwords, PATs are stored as one-way hashes, using SHA-256 or better, and they cannot be reversed.

  • Personally Identifiable Information (PII): PII is only made available to designated Blues employees when necessary to deliver our services or to respond to your support requests. Authentication PII, such as passwords or Personal Access Tokens, are never made available to employees.

  • Billing Accounts: Billing accounts retain information on all your payments and charges. You control who has access to view these records and who can create projects and hence expenses on your account. You may associate a credit card with your billing account. Blues never stores your credit card number. Enterprise customers have the option to pay via Purchase Order.

  • Audit Logs: To ensure you can track configuration changes, Notehub maintains detailed audit logs of changes to project and billing account settings. These logs include a detailed description of the change, user information, and the date. Project owners and billing account managers can view these audit logs at any time.

  • Data Archiving: Notehub offers a data archival feature that protects against unintended or malicious data deletion. You may configure data archiving on any S3-compatible storage services.

  • No Trackers: Notecard and Notehub do not use user trackers nor ad servers.

Infrastructure Security and Reliability

Cloud services are only as secure as their weakest link. Therefore, it’s crucial that Blues ensures our vendors and providers throughout our supply chain meet the highest standards of security and reliability. We do this through ongoing certification reviews, design-for-security, automated dependency analysis, and regular monitoring and testing.

Our infrastructure contains no single points of failure. All systems are primarily implemented using active-active failover, and the remainder using N+1 redundancy. We use real-time alerting and monitoring to ensure problems are caught early and addressed before they impact customers. Our availability target is 99.95%, matching AWS EC2 and similar service SLAs.

We implement strict controls to limit production access to only the engineers required to manage those systems and respond to issues. We log such access.

Details

  • Status Page: Status of all Blues's services can be found at status.notehub.io. On this site you can see the current operational status, view historical status, and sign up to receive status alerts by email.

  • Certified Infrastructure Provider: All of Blues' production systems and cloud services are hosted by Amazon Web Services (AWS) which meets all well-known security compliance standards including SOC, ISO27001, DIACAP, FedRamp, and FISMA. Details on AWS Security and Compliance can be found here.

  • Multiple Internet Providers and Multi-pathing: Our hosting provider maintains redundant relationships with multiple Internet Service Providers, and employs robust routing using the BGP4 networking protocol to provide redundancy, automatic failover, and allows network traffic to take the best path.

  • Multiple Data Centers: Our systems are spread across multiple data centers. Real-time copies of your data are securely stored in two or more production data centers. Thereby, Blues can recover even if an entire data center were to permanently go offline.

  • Virtual Private Cloud Server Isolation: Production servers are configured within Virtual Private Clouds and are not accessible from the internet. We use security groups to strictly limit inbound ports to only those required to deliver our service. All other ports and protocols are explicitly disabled, thereby preventing worms and other network-based attacks.

  • Data Security and Isolation: Each project’s data is kept in its own database, segregated from other customers. This mitigates the risk of data exposure due to SQL injection attacks, etc. Database storage is fully encrypted at rest using industry standard AES-256 or better encryption. Encryption keys are managed by AWS, ensuring industry-leading security compliance. Blues staff does not have access to these keys. All customer data is kept solely in secured production environments. Your data may only leave the production environment through explicit customer configurations such as event routing.

  • Restricted Access to Production Systems: All maintenance access by Blues personnel to production systems is limited by access-restricted, secured bastion servers. Maintenance access to servers, databases and other systems requires unique multi-factor authentication. Production systems access is limited to select, vetted reliability engineers with a documented need according to “least privilege” principles. Access is enforced using AWS SSM, and Blues maintains a record of these accesses.

  • Isolation of Production and Back-Office Systems: Using Virtual Private Clouds, production systems are completely isolated from pre-production and back-office systems.

  • Infrastructure-as-Code: We configure our cloud systems (including networking, servers, database, and storage) using software “infrastructure-as-code” techniques. Not only does this reduce the opportunity for misconfiguration, it also provides traceability for any system configuration changes. This ensures that pre-production configurations match production configurations, thus ensuring the testing validity. Manual changes are disallowed except in exceptional cases such as addressing a critical system fault. Any manual changes are then committed to code as needed during post-incident mitigation.

  • No Single Point of Failure: Our cloud services including Notehub are implemented using active-active, N+1 redundancy, and auto-scaling techniques. Our architecture has no single point of failure. Real-time monitoring alerts us to any system failures so we can immediately correct any issues.

  • Failover Testing: At least monthly, we test Notehub’s resiliency by temporarily taking servers offline and ensuring that service continues unimpeded.

  • Data Backups: To guard against the very unlikely case of data corruption, we snapshot our databases hourly. This gives us point-in-time recovery (PITR) of one hour or less. These point-in-time snapshots are rotated according to policy and permanently deleted after 30-90 days.

  • Business Continuity: Blues operational staff operate fully remotely from multiple geographic regions. This ensures that Blues will continue to deliver our services even during regional internet outages or other such emergencies.

  • 24x7 Monitoring: We monitor our systems and services 24x7 for failures that could impact service delivery or security. As described below, we automatically notify our operational staff on all critical incidents including all Notehub issues impacting event routing, and UI/API availability. Monitoring includes system-level monitoring (e.g., CPU usage, disk full, server offline, etc.), UI availability, API availability, and end-to-end service delivery. The latter includes live testing every minute of Notecard event ingestion and routing using a wide selection of Notecards.

  • Diagnostic Logging: Internally, Blues uses diagnostic logging to monitor service health and, in the event of unexpected behavior, to quickly diagnose issues. We never log our users' PII (e.g., contact information) nor authentication credentials such as passwords. We also use these logs to improve the performance and reliability of our services. Critical issues immediately alert our 24x7 staff.

  • Incident Escalation: For security incidents and significant disruptions of service, we have a written incident escalation policy. When Blues' monitoring detects failures we automatically notify our 24x7 incident staff. Our support team will also escalate issues to this staff. The incident staff will mitigate the issue as quickly as possible while keeping all Blues' customers informed on our status page and, where needed, through direct contact. Beyond incident mitigation, the policy also includes escalation to senior management, root-cause analysis, and post-incident mitigations.

  • Maintenance: Notehub has been designed so that almost all maintenance procedures do not impact customer applications. On the rare occasion that a scheduled maintenance process will interrupt service for 1 minute or more, will post an announcement on our status page at least 48 hours prior to the maintenance.

  • No-Impact Upgrades: Our Notehub upgrade process causes no data loss. It does not impact event ingestion and delivery beyond, in some cases, minor delays.

Process and Policy Safeguards

Blues' processes and policies reduce risk and increase reliability. We use pre-production environments that mirror production for development and testing all aspects of our hardware and software. Our standardized, automated release processes ensure quality, repeatability, and auditability. Daily, we run thousands of automated tests across the breadth of our offerings, including Notecards, Starnotes, Notecarriers, and Notehub.

These processes and policies apply to all Blues employees and contractors.

Details

  • Release Processes: To ensure quality, availability, and resiliency, our Notecard firmware releases and Notehub updates use a repeatable, automated release process: All code is independently code-reviewed; code is automatically scanned for vulnerabilities; thousands of automated tests must pass; new features are reviewed and documented; and the release processes themselves are automated and retain an audit trail.

  • Automated Testing: We run thousands of automated tests every day that cover all Notecard SKUs, the Notehub UI and our APIs and SDKs. Every LTS firmware release undergoes rigorous automated testing on all Notecard SKUs. This ensures we catch bugs and regressions as soon as they are introduced. Testing includes unit testing, security testing, integration testing, UI testing on popular web browsers and devices, and end-to-end integration tests. These tests and our API/SDK tests are based on actual customer scenarios. New features receive extra scrutiny to ensure they meet customer needs. No software is deployed to Notehub and no firmware is released to customers before reviewing test results and ensuring they pass.

  • Automated Dependency and Vulnerability Checks: We perform automatic checking of known security vulnerabilities in all software dependencies before they are deployed. We immediately correct threats and risks that could impact our customers. During development and before deploying new software, we run over twenty static code checkers and runtime vulnerability tests to identify potential security risks such as omitted error checks, potential SQL injection attacks, boundary checks, buffer overflows, etc. Code must pass all checks before being deployed.

  • Patching and Software Updates: Third-party software is patched and upgraded at regular intervals. Critical security issues are patched immediately. All OSes, databases and system software are on recent versions fully supported by their vendor.

  • Design and Development Processes: Security and reliability are considered during all project phases from design, through implementation and testing, to ongoing maintenance. We follow “secure by design” and “zero trust” engineering principles. This includes encryption by default, least privilege access, and regular automated security testing and validation. We also consider scalability and reliability including failover, auto-scaling, query efficiency, diagnostic logging and testability.

  • Auditable Code Reviews: We audit all code changes, keeping a record of the engineer making each change and the engineer who reviewed the change. All code changes and additions are reviewed by an independent engineer not involved with the implementation. Our automated software deployment process ensures that only reviewed and tested code is deployed, and that we maintain an auditable record of all changes and deployments.

  • Personnel Background Checks: Background checks, as permitted by law, are mandatory for all employees and contractors. These include criminal checks, education verification, and previous employment verification.

  • Proprietary Information: All employees are required to sign a Proprietary Information Agreement as a condition of employment.

  • Employee Onboarding/Offboarding: During employee onboarding, Blues provides training and access to development and production systems following a defined process. The level of access is role-dependent and follows the “least privilege” principle of only providing access to the systems required for the performance of their duties. In addition, when an employee is terminated or leaves, we remove all access using an auditable, traceable process.

  • Office Access: Access to our offices is strictly controlled and limited to our employees and invited visitors who are supervised.

Reporting a Vulnerability

Report security vulnerabilities in Blues products to security@blues.com. This is the only reporting channel Blues offers. No support contract, Notehub account, or commercial relationship is required — reports are accepted from anyone.

Our Coordinated Vulnerability Disclosure Policy sets out what to include in a report, what Blues commits to in return, the protections offered to good-faith researchers, and how Blues coordinates disclosure. It covers the Notecard (Cellular, Cell+WiFi, WiFi, LoRa, and Skylo variants), Starnote (Skylo and Iridium satellite accessories), and Notehub.

Published advisories — including the affected versions and the release that carries each fix — are listed on the Security Advisories page.

If you believe a vulnerability is being actively exploited, say so in your report so we can prioritize it.