An apparent discovery of a bug in Apple’s iMessage system was uncovered yesterday by Gizmodo. An Apple store customer was receiving messages intended for an employee after that employee had swapped his SIM into the customer’s phone as a part of the service process. Updated below.

Now, in a statement given to Jim Dalrymple of The Loop, Apple has stated that there is, in fact, no iMessage bug and the problem was simply caused by a breach in service protocol.

“This was an extremely rare situation that occurred when a retail employee did not follow the correct service procedure and used their personal SIM to help a customer who did not have a working SIM,” Apple representative Natalie Harrison told The Loop. “This resulted in a temporary situation that has since been resolved by the employee.”

With this statement, Apple is placing the blame directly on the Apple Store employee, intimating that if he had followed procedures properly, this would not have happened.

It has been debated for some time, since a semblance of this issue was discovered by Ars Technica, that your iMessage account was tied to your SIM card. This admission from Apple seems to seal the deal on that point. It also indicates that an iMessage registration can be transferred from one phone to another by swapping SIMs, and can even remain registered to the other phone after the SIM has been removed.

Because the employee used his own personal SIM card to help aid the customer in the quickest fashion possible, the iMessage registration for that SIM was transferred to the customer’s device. Apple says that the technician should have used a SIM provided specifically for troubleshooting procedures instead of his own.

The story at The Loop appears to indicate that a recommended procedure for preventing these issues is to ‘toggle iMessage off and back on‘. Presumably you would do this once your old SIM was back in your phone and that would transfer the registration back to the one tied to your own SIM.

There is also an interesting wrinkle here in that the customer was “using the iPhone without a SIM card,” an unusual state to begin with.

It seems fairly clear that the employee did not follow proper protocol on this issue, as I doubt that any training from Apple would recommend an employee use their own SIM card to complete any kind of service. But the claim that there is no bug is a bit harder to chew.

There still seems to be an issue by which iMessage identities, whether it be a phone number or email address, can get transferred to another phone and stick. The toggling of iMessage off and back on is unlikely to be something that the public commonly knows is recommended, unless they read an article like this one.

It seems that Apple should be able to find a way to ditch the iMessage registration of a device when a new SIM is placed in the phone. This would ensure that there is no issues, even for those who do not know the trick.

And we’re also unconvinced that simply toggling iMessage services of the device off and back on will fix the problem, as earlier reports have indicated that the messages may still be received after a remote wipe of a device.

So, while the issue may not be a bug in the strictest sense, it absolutely could be made clearer that additional steps need to be taken when switching SIM cards. This would ensure that issues don’t crop up when gifting or selling an iMessage-capable device that takes a SIM card.

Update: It’s been brought to my attention that I glossed over a specific detail here. Because the individual was not using a SIM of their own, no ‘original’ SIM was re-inserted into the device. Apple says that this would have triggered a transfer of the iMessage ID back to the customer’s device. A similar transfer can also be initiated by wiping the phone or toggling iMessage off and back on.

So, at least in this case, it seems that it was the ‘perfect storm’ of events—a customer without a SIM and an overzealous employee not following protocol—that caused the issue.

There are still some answers to be had about how an iMessage ID can apparently be bound to a device even after a wipe, in some occasions. But this particular incident seems to be a clear case of technician error.