It's true - go ahead and look. Every single unlucky soul that encounters the "status code 7000", "Team ID not yet configured for notarization" just stops developing for the mac, as they are left with no other option. Based on a deep review of all posts on the subject in multiple online communities & web searches, here's what we know: This problem has existed since at least 2018 People that drew the short straw are directed to contact Apple Developer Support via email Usually after 3 weeks an automated message is sent that the issue has been added to the queue of "the relevant team" Follow-up calls always indicate that the relevant team cannot be messaged even by Apple Support and that you just have to wait for them to contact you. In the past year, Apple now uses an AI bot to email you periodically to inform you that they are "monitoring" the situation and will let you know once "the relevant team" has completed their work. Apple makes it very clear you're trading emails back and forth with an LLM. The "relevant team" never, ever solves the problem or messages anyone. To be fair, the "relevant team" likely doesn't exist. Usually after 3 months, the average would-be developer gives up, and rues the day he paid the apple developer fee as well as all of the time & effort he'd put into making software on the Apple operating systems. Nobody knows why some people get the 7000 error. It seems as if xcode just randomly assigns it to 20 or 30 people per year. But knowing that the "Team ID is not yet configured for notarization" issue is a problem that will never be solved, we need to formulate some alternatives. Some of the avenues I'm brainstorming: Notarize under a different Team ID. This one stings because I went through so much trouble to create an LLC, all for nothing. Apple binds legal entities (DUNS numbers) with Team ID's. So my cursed Team ID and my new LLC cannot be used. My wife is a casual Apple user, I could set her up with her own dev account. That's torching another $99 as well as losing the protection of an LLC (for which I'd paid about $500 for). Sell my apps un-notarized. Apple treats the "7000 lottery losers" so badly that this might be the only path forward. Apparently a brew cask install in order to circumvent the traditional gates. Fellow devs probably don't mind this, but some of my apps are intended for the general public. Still not ideal. Remove 30% of my app's functionality and sell only the mac app store. That's a lot of feature losses that I'd spent months on. Ask any of the thousands of devs that didn't get randomly stricken by the status code 7000 curse to submit the app for notarization. Brand mismatch in Gatekeeper, but at least then we in the Apple Developer's Program can once again participate in the program we paid to be in. Set up our apps as open source, and include a link for funds. That means the LLC formation was a complete waste of $500. There's not a single Apple employee reading this that can help get us out predicament. If there was, we would have had at least one post anywhere on the internet about successfully overcoming the statuscode 7000 issue. Instead its just hundreds of posts by fee-paying developers saying they waited two, three, or 6 months before finally giving up and moving on to windows & linux software development. For the rest of my life, I'm going to wonder the following: Why was I singled out to get this status code error? If this problem has existed for at least 8 years, and has hundreds of posts about it, why is every single Apple support specialist completely clueless as to the cause of it? Why doesn't Apple have resolution metrics? That's got to be hundreds of unresolved status 7000 cases that have piled up. The company doesn't do any kind of internal reviews? Do they seriously mark cases as closed once its sent to "the relevant team"? And finally....don't Apple employees also think it's weird that "the relevant team" is a nameless, unknowable group that can never be contacted by their fellow co-workers? Like, everyone at Apple Support knows a phone number to reach the head office, or some method to reach C-suite secretarial pool. But the "relevant team" has no internal phone number available that other Apple staff can contact? For 25 days, I've spent between two and six hours each day trying to resolve my status code 7000 problem. That's time I've spent away from work and family, just to keep trying to resolve this issue. Knowing now that it will never be resolved does help as I try to pick up the pieces of my failed software development plans. Quinn/mods - please don't delete this. The people who get the status error need to know this. Absolutely no one who gets the 7000 code should be given false hope that "Oh just contact Apple Developer Support to resolve." At this point there's got to be hundreds of us that know the bitter truth that 7000 is a permanent, lifelong block. These unlucky devs need to immediately face reality so they can figure out the solutions to best navigate their business.

I'm posting this here after reading Quinn's post here: https://developer.apple.com/forums/thread/799000 The above entitlement is mentioned in IOUSBHostControllerInterface.h. It isn't an entitlement one can add using the + button on the Capabilities panel in Xcode. If I try to add it by hand, Xcode complains that it isn't in my profile. Is this a managed entitlement? We'd like to create a local USB "device" to represent a real device reachable over a network.

Support Case 102905607758 — no response after 9+ days. Profile: atlas-mac-notary All stuck "In Progress", notarytool log unavailable: 2026-05-31T08:02:14Z | 6a8ba9e3-60a9-476b-a12e-d27866be0559 | atlas-mac-10.6.38-100640-signed.dmg 2026-05-31T09:57:12Z | 51af581f-3bce-4603-abd6-77a27d332bac | atlas-mac-10.6.38-100640-signed.dmg 2026-05-31T17:19:29Z | 0163ccf4-4475-4161-b9fc-c50fb1df6d75 | atlas-mac-10.6.38-100664-signed.dmg 2026-05-31T18:01:08Z | 0c40ff22-6391-45e9-bd7d-0507f1e11147 | atlas-mac-10.6.38-100665.dmg 2026-06-06T07:33:51Z | fb464637-e8a4-4222-8963-e8e2bf230243 | atlas-mac-10.6.39-100668-submit.dmg 2026-06-07T07:48:16Z | 0a3b3e5b-02a1-4ee4-8456-6071723c131a | atlas-mac-10.6.39-100669.dmg One earlier submission processed: ebb768e3-3200-4933-86c7-5e3402c85ff5 → Invalid (atlas-core signing, fixed in later builds). We stopped all new submits. Please check backend queue state and advise how to clear stale entries. Thank you.

Hi, I'm a new Apple Developer Program enrollee (1 week in) shipping a Mac app via Developer ID + notarytool. Hardened runtime enabled, properly timestamped, all embedded Mach-O signed inside-out. 10 submissions are stuck "In Progress" - the oldest from 2026-06-07 (60+ hours ago). One Invalid verdict came back on 2026-06-08 for a real signing issue (unsigned PyQt5 framework binaries) which I've since fixed; the 10 newer submissions should pass cleanly. Apple's system status page has shown Developer ID Notary Service as green ("Operational") this entire time. This appears to be a queue issue specific to my account, not a service-wide outage. xcrun notarytool history: createdDate: 2026-06-09T16:26:37Z id: 4c928b64... status: In Progress (17h) createdDate: 2026-06-09T16:25:26Z id: 74e9feed... status: In Progress (17h) createdDate: 2026-06-08T21:13:31Z id: 8b246574... status: In Progress (37h) createdDate: 2026-06-08T20:59:37Z id: 4a529617... status: In Progress (37h) createdDate: 2026-06-08T18:49:33Z id: ff43d591... status: In Progress (39h) createdDate: 2026-06-08T18:46:27Z id: 60579d8d... status: In Progress (39h) createdDate: 2026-06-08T18:36:02Z id: a82fd14b... status: In Progress (39h) createdDate: 2026-06-08T18:22:45Z id: 4514a5cb... status: In Progress (39h) createdDate: 2026-06-07T21:20:09Z id: 700c8413... status: In Progress (60h) createdDate: 2026-06-07T20:18:08Z id: 2ea83c6c... status: In Progress (60h) xcrun notarytool info on each returns "status: In Progress" with no processedDate set. I understand new submitters can get held for extended in-depth analysis on first submissions, but 60+ hours is past any documented expectation for that. Could a DTS engineer please look at the backend logs and either release the queue or tell me what's specifically blocking these submissions? Thanks!

This is the first notarisation activity on a newly enrolled Developer Program account. Every submission has been stuck "In Progress" with no terminal status and no log available. Oldest stuck request: UUID: bfb5a0e3-31a2-4dcd-a1c6-2f26ce6e62dd Created: 2026-05-29T13:43:22Z Team ID: ZH3S4VZT33 It has now been more than 7 days. I understand first-time submissions can be held for in-depth analysis, which is why I waited a full week before posting. Evidence this is account/team-level rather than specific to one app: A second submission the same day (e42fb5f4-8fc7-4eec-9eef-9764e756b444) and a separate throwaway probe app submitted 2026-06-01 (0333a989-3a9f-44b1-98e6-69f9ee4028e4) are all stuck "In Progress" too. xcrun notarytool log <id> returns "Submission log is not yet available" for all of them. No rejection email at the Apple ID address. Apple System Status shows Developer ID Notary Service as Available. Could someone from the notary service team check the queue for Team ID ZH3S4VZT33 and advise whether these are in the in-depth-analysis path? Happy to provide codesign output or additional UUIDs.

Hello Team, We are currently implementing a digital membership solution across our gym facilities, allowing members to add their access cards to Apple Wallet. In this regard, we would like to request enablement of NFC capability for Wallet passes associated with our Apple Developer account. Our setup includes NFC-enabled access control hardware integrated with our gym management system, and NFC support is required to issue and utilize digital membership cards. At present, we only have a standard Pass Type ID Certificate in our developer account. However, we understand that NFC-enabled Wallet passes require a Pass Type ID Certificate with NFC capability. We would appreciate your guidance on how we can enable or obtain a Pass Type ID Certificate with NFC support in our Apple Developer account. Looking forward to your support.

Seeing my notarizations getting stuck. This is becoming a blocker for releasing. What's strange is that earlier versions of the same app (very similar) passed notarization very quickly. Any advice or recourse?

My app includes the main program, Finder extension, and launcher helper. Which identifier should I choose when generating a provisioning profile?

Hi, I have Identifiers that's used maybe in old Xcode projects long time ago that never been uploaded for Apple to approve and yet when trying to remove I get an error message below, any suggested fixes ? " The App ID 'xyz.xyz.xyz' appears to be in use by the App Store, so it can not be removed at this time. "

On the Certificates, Identifiers and Profiles section of the Account section of developer.apple.com, if you manually configure the Capabilities of an App Identifier, there are icons with no tooltips. Does anyone know what they mean? (I'm particularly interested in the two different icons shown in my screenshot, with the same name)

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

I've tried to add the "Pass Type Identifiers" entitlement manually in .entitlements, but it will not archive and shows the error: Entitlement com.apple.developer.pass-type-identifiers not found and could not be included in profile. This likely is not a valid entitlement and should be removed from your entitlements file. It works correctly for the App (parent of ), but without it the App Clip can't see any passes. The documentation says this should be possible: Note In iOS 17 and later, App Clips can use the Wallet capability. For more information on functionality that’s available to App Clips, see Choosing the right functionality for your App Clip. It is not visible in the portal either. Is this an entitlement that I need to specifically request, and if so, how would I go about doing so? Thanks! Wes

Hi Apple Developer Support, I am writing to escalate an urgent unresolved request regarding our app BetterUs (Team ID: TK8M23SECQ, Bundle ID: com.dalesidebottom.betterus). Timeline of attempts: ~1 May 2026 — Submitted FamilyControls Distribution entitlement request via the official form at developer.apple.com/contact/request/family-controls-distribution for bundle IDs com.dalesidebottom.betterus.shield and com.dalesidebottom.betterus.report. No confirmation number received, no response. ~20 May 2026 — Raised support case 102892887667 via developer.apple.com/contact. Received acknowledgement from Eugene. ~21 May 2026 — Replied with all requested information (date of submission, business need, bundle IDs). Today — Still no approval and no further response. It has now been over 3 weeks since the original request. What I need: The FamilyControls Distribution entitlement is already approved on my account for: com.dalesidebottom.betterus ✅ com.dalesidebottom.betterus.monitor ✅ I simply need it extended to these two sub-extensions of the same app: com.dalesidebottom.betterus.shield (Shield Configuration extension) com.dalesidebottom.betterus.report (DeviceActivity Report extension) These are not new use cases — they are part of the same approved parental screen time app. Without this, BetterUs cannot be submitted to the App Store at all. I have active testers waiting and this delay is significantly impacting our launch. I would greatly appreciate urgent attention on this matter. Thank you, Dale Sidebottom

This issue keeps cropping up on the forums and so I decided to write up a single post with all the details. If you have questions or comments: If you were referred here from an existing thread, reply on that thread. If not, feel free to start a new thread. Use whatever topic and subtopic is appropriate for your question, but also add the Entitlements tag so that I see it. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = "eskimo" + "1" + "@" + "apple.com" Determining if an entitlement is real In recent months there’s been a spate of forums threads involving ‘hallucinated’ entitlements. This typically pans out as follows: The developer, or an agent working on behalf of the developer, changes their .entitlements file to claim an entitlement that’s not real. That is, the entitlement key is a value that is not, and never has been, supported in any way. Xcode’s code signing machinery tries to find or create a provisioning profile to authorise this claim. That’s impossible, because the entitlement isn’t a real entitlement. Xcode reports this as a code signing error. The developer misinterprets that error [1] in one of two ways: As a generic Xcode code signing failure, and so they start a forums thread asking about how to fix that problem. As an indication that the entitlement is managed — that is, requires authorisation from Apple to use — and so they start a forums thread asking how to request such authorisation. The fundamental problem is step 1. Once you start claiming entitlements that aren’t real, you’re on a path to confusion. Note If you’re curious about how provisioning profiles authorise entitlement claims, read TN3125 Inside Code Signing: Provisioning Profiles. There are a couple of ways to check whether an entitlement is real. My preferred option is to create a new test project and use Xcode’s Signing & Capabilities editor to add the corresponding capability to it. Then look at what Xcode did. You might find that Xcode claimed a different entitlement, or added an Info.plist key, or did nothing at all. IMPORTANT If you can’t find the correct capability in the Signing & Capabilities editor, it’s likely that this feature is available to all apps, that is, it’s not gated by an entitlement or anything else. Another thing you can do is search the documentation. The vast majority of real entitlements are documented in Bundle Resources > Entitlements. IMPORTANT When you search for documentation, focus on the Apple documentation. If, for example, you search the Apple Developer Forums, you might be mislead by other folks who are similarly confused. If you find that you’re mistakenly trying to claim a hallucinated entitlement, the fix is trivial: Remove it from your .entitlements file so that your app starts to build again. Then add the capability using Xcode’s Signing & Capabilities editor. This will do the right thing. If you continue to have problems, feel free to ask for help here on the forums. See the top of this post for advice on how to do that. [1] Xcode 26.2, currently being seeded as Release Candidate, is much better about this (r. 155327166). Give it a whirl! Commonly Hallucinated Entitlements This section lists some of the more commonly hallucinated entitlements: com.apple.developer.push-notifications — The correct entitlement is aps-environment (com.apple.developer.aps-environment on macOS), documented here. There’s also the remote-notification value in the UIBackgroundModes property. com.apple.developer.in-app-purchase — There’s no entitlement for in-app purchase. Rather, in-app purchase is available to all apps with an explicit App ID (as opposed to a wildcard App ID). com.apple.InAppPurchase — Likewise. com.apple.developer.storekit — Likewise. com.apple.developer.in-app-purchase.non-consumable — Likewise. com.apple.developer.in-app-purchase.subscription — Likewise. com.apple.developer.app-groups — The correct entitlement is com.apple.security.application-groups, documented here. And if you’re working on the Mac, see App Groups: macOS vs iOS: Working Towards Harmony. com.apple.developer.background-modes — Background modes are controlled by the UIBackgroundModes key in your Info.plist, documented here. UIBackgroundModes — See the previous point. com.apple.developer.voip-push-notification — There’s no entitlement for this. VoIP is gated by the voip value in the UIBackgroundModes property. com.apple.developer.family-controls.user-authorization — The correct entitlement is com.apple.developer.family-controls, documented here. IMPORTANT As explained in the docs, this entitlement is available to all developers during development but you must request authorisation for distribution. com.apple.developer.device-activity — The DeviceActivity framework has the same restrictions as Family Controls. com.apple.developer.managed-settings — If you’re trying to use the ManagedSettings framework, that has the same restrictions as Family Controls. If you’re trying to use the ManagedApp framework, that’s not gated by an entitlement. com.apple.developer.callkit.call-directory — There’s no entitlement for the Call Directory app extension feature. com.apple.developer.nearby-interaction — There’s no entitlement for the Nearby interaction framework. com.apple.developer.secure-enclave — On iOS and its child platforms, there’s no entitlement required to use the Secure Enclave. For macOS specifically, any program that has access to the data protection keychain also has access to the Secure Enclave [1]. See TN3137 On Mac keychain APIs and implementations for more about the data protection keychain. com.apple.developer.networking.configuration — If you’re trying to configure the Wi-Fi network on iOS, the correct entitlement is com.apple.developer.networking.HotspotConfiguration, documented here. com.apple.developer.musickit — There is no MusicKit capability. Rather, enable MusicKit via the App Services column in the App ID editor, accessible from Developer > Certificates, Identifiers, and Profiles > Identifiers. These app services are tied to your App ID on the server side, meaning that they have no presence in your code signature. com.apple.developer.shazamkit — There is no ShazamKit capability. Like MusicKit, this is an app service. com.apple.mail.extension — Creating an app extension based on the MailKit framework does not require any specific entitlement. com.apple.security.accessibility — There’s no entitlement that gates access to the Accessibility APIs on macOS. Rather, this is controlled by the user in System Settings > Privacy & Security. Note that sandboxed apps can’t use these APIs. See the Review functionality that is incompatible with App Sandbox section of Protecting user data with App Sandbox. com.apple.developer.adservices — Using the AdServices framework does not require any specific entitlement. com.apple.security.device.audio-input-monitoring — The com.apple.security.device.microphone entitlement is what restricts microphone access on macOS. [1] While technically these are different features, they are closely associated and it turns out that, if you have access to the data protection keychain, you also have access to the SE. Revision History 2026-05-28 Added com.apple.security.device.audio-input-monitoring to the common hallucinations list (Kevin) 2026-04-23 Added com.apple.developer.shazamkit to the common hallucinations list. Added a little more info about app services. 2025-12-09 Updated the Xcode footnote to mention the improvements in Xcode 26.2rc. 2025-11-03 Added com.apple.developer.adservices to the common hallucinations list. 2025-10-30 Added com.apple.security.accessibility to the common hallucinations list. 2025-10-22 Added com.apple.mail.extension to the common hallucinations list. Also added two new in-app purchase hallucinations. 2025-09-26 Added com.apple.developer.musickit to the common hallucinations list. 2025-09-22 Added com.apple.developer.storekit to the common hallucinations list. 2025-09-05 Added com.apple.developer.device-activity to the common hallucinations list. 2025-09-02 First posted.

Ive spent nearly one month to develop my first app, and now its done. but i am stuck with getting Family Controls Distribution entitlement. i`ve request that one month and half ago. but still get no response. I tried connect the apple developer support、send post on Forum、send code-level support on appstoreconnect. All completely disappeared into a black hole. I understand that you may be facing a significant backlog, waiting for nearly two months without any response or update regarding the Family Controls Distribution entitlement is extremely difficult for me to understand. I genuinely cannot understand why Apple’s review process is operating with such low efficiency.

Every notarization submission from my team is being rejected by the notary service with this message: statusCode: 7000 statusSummary: "Team is not yet configured for notarization. Please contact Developer Programs Support at developer.apple.com under the topic Development and Technical / Other Development or Technical Questions." 23 submissions in the past few days all returned this same rejection. Before submissions started returning Rejected, they would sit at "In Progress" indefinitely (sometimes for days), which I initially mistook for the in-depth-analysis slow-lane. Once Apple's queue cleared the backlog, every one of them surfaced as statusCode 7000. Ruled out on my side: Apple Developer Program membership is active License Agreement signed (days before the submissions) Code signing is valid (Developer ID Application chain), hardened runtime enabled, secure timestamp present ASC API key successfully submits and queries (the issue is in server-side processing/policy, not auth) Tested with both a minimal binary and a full app, same rejection Team ID: XSN9V8JZ75 Reference submission ID (the small isolated test): ba67edaf-c3d9-44dd-9974-5fc1811e0f72

These have been stuck in progress for a long time. Usually this process is fairly quick for this app: id: 92caae7f-1796-4928-bb35-72f5f2667786 id: 3645e93f-a8ac-4826-8a4a-690f980dde8e id: 3645e93f-a8ac-4826-8a4a-690f980dde8e What can be done, it is holding back deployments :(

I made a small 20MB .pkg installer for some Logic Pro Drum Machine Designer patches so the user doesn't have to manually place the files by hand. Tried to notarize 3 times, all attempts have been stuck "in progress" since yesterday and can't seem to get any log files that might explain where things are getting stuck. Are the duplicate submissions causing this and if so is there a way to de-duplicate? My first time doing this so when notarization was hanging on the first attempt I thought I had done something incorrectly. Not sure how to troubleshoot this and would appreciate any guidance.

Adding application ID to .pkg file seemed to work Original My modified version I created a .pkg file which installed to Applications folder and the app worked fine, but when I uploaded the app with transporter I got the message 'executables must include the "com.apple.security.app-sandbox" entitlement with a Boolean value of true'

We have been having unexplained failures with the codesign tool recently on macosx aarch64 and x64 hosts. Every once in a while when signing an app locally using the following command: /usr/bin/codesign -s - -vvvv --force /home/me/FooBarCalculator.app results in the following error: /home/me/FooBarCalculator.app: timestamps differ by 185 seconds - check your system clock The number of seconds reported in the error message keeps varying (but usually in that range). We have checked the system clock but there isn't anything wrong (from what we can see) with the host. In fact, we have been seeing this error on several hosts now, so it isn't specific to one host. While looking into this issue, we even printed the details of an already signed binary using the following command: codesign -dvvv HelloWorld.app and that prints among other things, similar warning message: ... Timestamp=12 May 2026 at 5:36:0 AM HelloWorld.app: timestamp mismatch: internal time 12 May 2026 at 5:32:59 AM (184 seconds apart) I'm looking for inputs on how we go about debugging this issue and where/how the codesign tool sources these timestamps from (any specific API?) and what value is it comparing against to notice a difference. These affected hosts have different operating system versions some 15.x and some 26.x.